On Mon, Apr 5, 2010 at 2:37 PM, Chia-I Wu <olva...@gmail.com> wrote: > On Mon, Apr 5, 2010 at 12:00 PM, Dave Airlie <airl...@gmail.com> wrote: >>> The attached patch fixes tfp test for me (with i915g). Could you see if >>> r300g >>> passes the test with the patch? >>> The teximage callback has an internal_format parameter that specifies how >>> the >>> pipe texture should be treated. It can differ from the format of the >>> texture. >>> It seems to suffice for TFP. I was lazy enough not to use it :( >> That was my first attempt also, however it fails as the texture is >> already created, and >> in r300g we already have worked out the hw state assuming the texture >> format won't >> change. This seems to be what gallium expects. So in this case you end >> up recreating >> a new texture at finalise because the formats don't match and you lose >> the pixmap. > r300g does not see the texture before st_finalize_texture, right? It seems to > me that the patch should give the correct behavior but a (really bad) > unnecessary texture copy in st_finalize_texture. Could we avoid the copy by > solely changing the sampler view?
It sees the texture via dri_st_framebuffer_validate_att(drawable->stfb, ST_ATTACHMENT_FRONT_LEFT) which causes the texture to be creates from the dri2 buffer handle, The thing is we need the exact buffer object we get from the X server, we can't copy it to another texture later, as it destroys the shared texture and just seems to create another private one. Dave. ------------------------------------------------------------------------------ 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
