On Sun, Apr 4, 2010 at 8:31 PM, Dave Airlie <airl...@gmail.com> wrote: > Hey, > > So I was trying to fix tfp test on r300g, and ran into an issue with > dri st I think. > > So the way TFP works we get dri2_set_tex_buffer, which then validates the > attachment, but ignores the format passed in. So r300g picks up the kernel > buffer from the handle and sets up the texture + texture state without > the format > information. > > Once we've validated, we call ctx->st->teximage and can give it a different > format however at no point does r300g get any place to change the texture > format > and update its internal state. > > I'm not sure if either r300g should delay setting up its internal > state for emission > until later or whether we need to enhance the st interface. > > The main issue with we get a TFP with a B8G8R8X8 but the visual is B8G8R8A8 > which triggers this. >
Here's a hacky patch to demonstrate the issue, though it doesn't fix the problem I'm seeing with the test, just one less thing wrong. Dave.
0001-dri-st-add-hacky-tfp-format-override.patch
Description: Binary data
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
