On Mon, Apr 5, 2010 at 6:06 PM, Chia-I Wu <olva...@gmail.com> wrote: > On Mon, Apr 5, 2010 at 3:38 PM, Dave Airlie <airl...@gmail.com> wrote: >> 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. > The patch I sent earlier works here with i915g. I am not sure where it goes > wrong with r300g. Do you mind have a look into it?
Yeah I suspect we have an issue in r300g alright, we use a stride override when we get the texture from TFP, and this might not be propogated properly when we copy it later. 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
