[Mesa-dev] Radeon DRI1 removal

[Roland Scheidegger]

Am 20.10.2011 18:59, schrieb Dave Airlie:
> On Thu, Oct 20, 2011 at 5:59 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 20.10.2011 18:10, schrieb Dave Airlie:
>>>>>
>>>>> So, Radeon maintainers, what do you think?  And, does anyone else want
>>>>> to test it on the other drivers?  I caught two bugs in my r300 testing
>>>>> (one too many lines cut in one r300 commit, and I had also removed the
>>>>> texsubimage code in an unrelated-to-the-series commit, but it regressed
>>>>> s3tc-texsubimage so I backed it out).
>>>>
>>>> I don't see AMD doing any more work on DRI1.  The cleanup would be
>>>> nice, but it would also mean dropping support for *BSD.  OTOH, these
>>>> drivers aren't likely to see any more changes feature-wise so sticking
>>>> with mesa 7.11 would work.  Also, are there are any Linux distros that
>>>> care about DRI1 anymore?  If so, speak now.  Also, as Michel said, if
>>>> we drop DRI1 support, we might as well drop r300c and r600c altogether
>>>> in favor of the gallium variants.
>>>
>>> Hell yes, drop r300c and r600c as well.
>>>
>>> We can get DRI2 tiling working on r100/r200 again then with texture
>>> mapping as previously they relied on us knowing the tiling formats
>>> which are totally undocumented and I never figured out in sw.
>>
>> Ahh brings back fond memories of hacking around to make texture
>> macro/micro tiling work for all (mip) sizes (and figuring out when it
>> won't if texture had "bad" width/height proportions). I think I actually
>> figured out the tiling pattern for both r100 and r200 at some point, it
>> was not that complicated. In any case the micro tiling pattern can still
>> be seen in the kernel code since hacks were necessary to make it work
>> with blitter if the texture width was too small (though I always thought
>> this to be quite fishy, maybe it would have been possible to make it
>> work with less hacks by programming the blitter more appropriately). A
>> lot of trial and error was needed though for that but the performance
>> gain is definitely worth it (as is hyperz - IIRC you get about half the
>> performance if you have neither hyperz nor color tiling for typical
>> fillrate-bound situations on r2xx).
>>
> 
> I think the last one I couldn't figure out was depth tiling one r200,
> it didn't match the others,
>  the radeon span code contains sw detiling but it was a pain to figure out.

Yes the bit pattern looks so complicated. Easier though than
decompressing z buffers, I don't think we ever had code for that...

Roland