Am 20.10.2011 18:59, schrieb Dave Airlie: > On Thu, Oct 20, 2011 at 5:59 PM, Roland Scheidegger <srol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev