Forgive me, maybe I'm a tad too harsh indeed. It's just that I'm pretty tired about the fact that almost every time I want to use a W3D or Compositing functionality it turns out that it's broken, at least on some systems. I suppose you know about all the bugs I reported so far (more to come btw.)? AFAIK not one was solved (I was told that the MiniGL bugs were solved at least). Probably you can imagine that I'm a bit prickly when I have the feeling that no real measures are taken to really solve those issues. And when somebody wants to tell me something about "complex calculations" when it comes to math that's less complicated than what a sixth grade kid learns in school I start to feel to be taken for a ride, sorry...I'm not sure I appreciate your tone.
That's probably part of the problem Such a crucial part of the system deserves more attention I'd say, don't you think?We are talking about code that, according to SVN I have not looked at since 2013-06-20
No thanks I'm just the customer complaining about things not working. Things that should work. I mean, it's not as if I was asking for miracle-stuff here. There's a big bug (and not just this one) inside, one that makes simple texturing a problem and it would be great if at least this one was actually fixed. I'm really tired of adding workarounds for all those driver bugs to my AOS4-specific abstraction layer.If you want more commitment, feel free to hire me. My contracting rates are quite reasonable. I'd even give you a discount. Call it 450 UKP/day ?
Well, since it looks like I'm the first one tapping into this issue... Yes, it may have been very possible indeed that nobody tried it before. Apparently you are not 100% sure yourself what happens under certain circumstances, so yes, I'd say this is a very valid constructive question indeed.Wrong. Your requested 32-bit BitMap almost always ends up in FAST ram ready to be paged in only when RTG decides it's necessary to do so. You might get lucky sometimes, most of the time you won't. What are you going to do now? Your graphics card will at best render a load of garbage, or it will simply hang your entire system. You think this approach was never attempted before?
Because from the information you delivered so far the height > 4096, this 4100, seems to be the problem. At least you answered "yes" when I asked if there was such a limit. So naturally the first guess to work around it would be to increase the width and lower the height instead, so that both values end up below 4096, even if that means using a not-so-nice-POT-width.Why do you think increasing the width past 2048 will help?
Trying this out is certainly more reasonable than asking for a 2048 x 4100 bitmap of which you apparently knew that it would fail beforehand. Or you could try different variants internally. If variant X fails, then try again with modified values.
Yes, probably. Or probably not. How about trying it out? It would certainly be an improvement if it turns out that it works on R200. If it fails on others, bad luck for those.That already won't work on most of the supported hardware and probably won't work on R200 either.
Not my job. I already helped to a great deal by providing test-programs for LOTS of W3D bugs I found, testing your debug lib and by talking to you here. I guess it's time that you make something out of it.If you want to help, why not write a test program yourself to ascertain the maximum hardware...
Unfortunately there was no sarcasm in that sentences. But anyway, if you are an allocator-master, then why not put your experience into writing one for this case here? That would be the solution I'd expect from a driver's author.Sarcasm much? I have probably written more allocators than you would think, using many different strategies.
If you have access to the code and digged into it then I don't get why you cannot fix this issue. With your experience regarding allocators this should be a piece of cake for you!I didn't write this one, however. I have fixed many bugs and inefficiencies within it, but this one remains
Give me access to all the sources and info you got and I'll probably give it a shot. I'm not as cheap as you are thoughFeel free to develop it and I'll reimplement the W3D_Picasso96.library to use it.
Why do you need yet another test program for this? If you can solve the problem, then how about doing it? I'll be happy to test a fresh library. I'd say that's way more than you can expect from an usual customerI can write some special case handling for when we will exceed 2048x2048 on that basis
Who knows (remeber those 2048 x 1024 / 1024 x 2048 failures I sometimes got?) I only know what you decide to let me know. And I don't even know how valid that info is. So far the only thing I know for sure is, that you had a wrong calculation inside your code and that this got fixed, so that 2048x2048 textures work for 32bit contexts now (which is an improvement I appreciate, of course).After all, there clearly isn't a problem when we are allocating lower sizes
Sorry, you simply didn't get me right. Of course I expect you to deliver useful values depending on the context. Of course I don't want you to return from W3D_Q_MAXTEXWIDTH with 1024 always. You should return 1024 if you can determine that 2048 won't work (and apparently you can do that if we got a R200 and a 16bit context, since you know that your p96Alloc-call will fail - at least that's what we agreed on above). From what you told me so far (and as my tests underline) on R200 such an alloc will always fail. So it would be a smart (and simple) "solution" for now to adjust the max-texture-size info accordingly.Earlier you were berating me (wrongly) for apparently restricting the allocator to only care about the non Radeon untermensch and suddenly you want to reduce everybody's functionality that aren't affected by your specific use case?
Okay. Then we all know where we are.Since the underlying problem is unlikely to be fixed any time soon
Pardon? The first parameter to W3D_Query is the context (and the NULL pointer variant is long "discouraged"). So it should be no problem for you to return a more correct value than 2048 x 2048 based on the context's depth / GPU type at least. I mean, that information should be possible to obtain, right? At least you definitely know the context's depth at this point - because you use that info during texture allocation. And if somebody calls W3D_Query with a NULL context, fine, then just do as you do now.and the W3D_Q_MAXTEXWIDTH/HEIGHT functions aren't context aware beyond what is potentially possible on 8-bit (deprecated) or RGB render targets
That's at least a tad better than the current variant of returning "okay" and failing later with the first draw command.1) Cause W3D_AllocTexObject() to fail when attempting to reserve storage for a texture that is likely to exceed the limitations implied by the render target (ie, 2Kx2Kx32-bit texture on a 16-bit render target) in the Radeon drivers.