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?
-- o...@lunarg.com ------------------------------------------------------------------------------ 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
