On 13.04.2010 02:52, Dave Airlie wrote: > On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul <bri...@vmware.com> wrote: >> Dave Airlie wrote: >>> Just going down the r300g piglit failures and noticed fbo-drawbuffers >>> failed, I've no idea >>> if this passes on Intel hw, but it appears the texenvprogram really >>> needs to understand the >>> draw buffers. The attached patch fixes it here for me on r300g anyone >>> want to test this on Intel >>> with the piglit test before/after? >> The piglit test passes as-is with Mesa/swrast and NVIDIA. >> >> It fails with gallium/softpipe both with and w/out your patch. >> >> I think that your patch is on the right track. But multiple render targets >> are still a bit of an untested area in the st/mesa code. >> >> One thing: the patch introduces a dependency on buffer state in the >> texenvprogram code so in state.c we should check for the _NEW_BUFFERS flag. >> >> Otherwise, I'd like to debug the softpipe failure a bit further to see >> what's going on. Perhaps you could hold off on committing this for a bit... > > Well Eric pointed out to me the fun line in the spec > > (3) Should gl_FragColor be aliased to gl_FragData[0]? > > RESOLUTION: No. A shader should write either gl_FragColor, or > gl_FragData[n], but not both. > > Writing to gl_FragColor will write to all draw buffers specified > with DrawBuffersARB. > > So I was really just masking the issue with this. From what I can see > softpipe messes up and I'm not sure where we should be fixing this. > swrast does okay, its just whether we should be doing something in gallium > or in the drivers is open.
Hmm yes looks like that's not really well defined. I guess there are several options here: 1) don't do anything at the state tracker level, and assume that if a fragment shader only writes to color 0 but has several color buffers bound the color is meant to go to all outputs. Looks like that's what nv50 is doing today. If a shader writes to FragData[0] but not others, in gallium that would mean that output still gets replicated to all outputs, but since the spec says unwritten outputs are undefined that would be just fine (for OpenGL - not sure about other APIs). 2) Use some explicit means to distinguish FragData[] from FragColor in gallium. For instance, could use different semantic name (like TGSI_SEMANTIC_COLOR and TGSI_SEMANTIC_GENERIC for the respective outputs). Or could have a flag somewhere (not quite sure where) saying if color output is to be replicated to all buffers. 3) Translate away the single color output in state tracker to multiple outputs. I don't like option 3) though. Means we need to recompile if the attached buffers change. Moreover, it seems both new nvidia and AMD chips (r600 has MULTIWRITE_ENABLE bit) handle this just fine in hw. I don't like option 1) neither, that kind of implicit behavior might be ok but this kind of guesswork isn't very nice imho. Opinions? Roland ------------------------------------------------------------------------------ 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
