On Mon, Apr 5, 2010 at 5:24 PM, Chia-I Wu <olva...@gmail.com> wrote: > On Mon, Apr 5, 2010 at 1:41 PM, Dave Airlie <airl...@gmail.com> wrote: >> 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. > Suppose a PIPE_FORMAT_B8G8R8A8_UNORM GLXPixmap is created both for rendering, > and t-f-p texturing with GLX_TEXTURE_FORMAT_RGB_EXT. The front left buffer of > the pixmap should be a single PIPE_FORMAT_B8G8R8A8_UNORM pipe_texture. When > glXBindTexImageEXT is called, st/mesa should "view" the pipe_texture as if > there is no alpha channel. It is hacky for st/dri to create another > pipe_texture from the same dri2 buffer handle with a different format and pass > the new pipe_texture to st/mesa. > > To achieve the "viewing" thing efficiently, st/mesa should create a > PIPE_FORMAT_B8G8R8X8_UNORM sampler view for the pipe_texture (I suppose this > is > what a sampler view for? No?). This is contrary to performing an implicit > copy on the pipe_texture only to ignore the alpha channel, which is what > st_finalize_texture does. IIRC, tfp allows an implementation to perform an > implicit copy upon binding. Both behaviors are correct in this sense, but the > latter is obviously undesirable. >
Yes a sampler view seems the sanest. The latter behaviour might be correct but doesn't work here, at least with the equiv patch I tried originally the test still failed, so it would be correct if it worked though slower. 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
