[Mesa-dev] Radeon DRI1 removal

[Alex Deucher]

On Thu, Oct 20, 2011 at 12:59 PM, Dave Airlie <airlied at gmail.com> wrote:
> 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.

At the time I managed to dig up some info on the tiling patterns for
r3xx+, but r1xx/r2xx was so old pretty much all of the docs had been
moved to tape and no one would remember exactly what the pattern was.
The 2D engine could only deal with macro tiling, but the 3D engine can
deal with both micro and macro and the mesa blit codes uses the 3D
engine so it should be trivial support it with the rb map buffer
changes.

Alex