Hi Paul,
In my quest to squash ddraw test failures on my hardware lab I have run into a recently added problem. Maybe you still have an active enough memory of the test code that you can help me understand the failure.
The system is a 2003-era laptop with an ATI Mobility Radeon 9000 running windows XP. The test failures are in the attached ddraw7.txt file. I ran the test with some minimal modifications, see ddraw7.diff.
My gut feeling is that this is not simply a color precision issue - the values are pretty far apart, especially for 16 bit surfaces. Yet, something is apparently going right. The blit happens and the result at least resembles the expected results.
It makes sense to me that only the sysmem->vidmem blit is affected as that's the most likely case to be accelerated by the driver. Could the driver handle the src rectangle incorrectly?
My cheap way to fix it would be to add something like broken(ddraw_is_amd() && color == 0x8019), but if we can find a way to keep the test intact on this hardware that would be better.
Cheers, Stefan
Hello Stefan,
the fail in your attached results happens only for the very specific combination of conditions:
1. The offset into destination surface is not a multiple of block size. The test fails only inside the blocks that are partially covered by blit (y 2, 3; no failures for y 4-7). 2. The destination format is DXT3 (all the combinations succeed for DXT1 as destination format). 3. It is sysmem to vidmem draw.
I have only one immediate idea what could we try to tweak. Due to failure condition 1. maybe initializing the destination surface with some different colours will change anything? It is very unlikely to fix the thing but maybe can give some idea what the failure is about.
But as I see it chances are there is just some bug in DXT3 encoding code path specific to sysmem to vidmem for the edge case of uneven destination offset (e. g., using some arbitrary values for missing 2 pixels in block can potentially alter the result in some way similar to what we see). I would suggest to add broken() but maybe instead of doing it for every test result add some 'expected_broken' to test_sizes[] structure and do something like broken(ddraw_is_amd() && test_sizes[i].expected_broken && clor == test_sizes[i].expected_broken)?
Regards, Paul.
On 1/23/20 17:58, Stefan Dösinger wrote:
Hi Paul,
In my quest to squash ddraw test failures on my hardware lab I have run into a recently added problem. Maybe you still have an active enough memory of the test code that you can help me understand the failure.
The system is a 2003-era laptop with an ATI Mobility Radeon 9000 running windows XP. The test failures are in the attached ddraw7.txt file. I ran the test with some minimal modifications, see ddraw7.diff.
My gut feeling is that this is not simply a color precision issue - the values are pretty far apart, especially for 16 bit surfaces. Yet, something is apparently going right. The blit happens and the result at least resembles the expected results.
It makes sense to me that only the sysmem->vidmem blit is affected as that's the most likely case to be accelerated by the driver. Could the driver handle the src rectangle incorrectly?
My cheap way to fix it would be to add something like broken(ddraw_is_amd() && color == 0x8019), but if we can find a way to keep the test intact on this hardware that would be better.
Cheers, Stefan
Am 23.01.20 um 16:46 schrieb Paul Gofman:
I have only one immediate idea what could we try to tweak. Due to failure condition 1. maybe initializing the destination surface with some different colours will change anything? It is very unlikely to fix the thing but maybe can give some idea what the failure is about.
Zeroing the destination surface right after creating it seems to fix the problem. I guess the driver's bug is that it doesn't do that for DXT3 surfaces. I have to use lock + memset to init the surface, DDBLT_COLORFILL returns E_NOTIMPL on compressed surfaces. I vaguely remember writing a test for that once.
I'll send a patch that manually zeroes the destination surface. If you feel like extending the blit test to blit onto a non-zero destination (I guess that's expecially fun for the driver when you do sub-block blits) just tell Henri to ignore it.
An unrelated problem I've spotted is that lock.dwSize is never initialized. In my testing we luckily get away with that because a large value gets left behind on the stack, and larger sizes happen to be OK for the specific combination of ddraw7 sysmem texture. I'll send a patch for that too.
-
Paul Gofman -
Stefan Dösinger