test_compressed_surface_stretch fails on r200 GPUs

[Paul Gofman]

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