On Tue, Apr 13, 2010 at 11:42 PM, Roland Scheidegger <srol...@vmware.com> wrote: > 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. >
Yeah 3 is definitely out, I've tried it its too messy, esp with 1->n and n->1 transitions, I'd be happy with 1 or 2, though I do wonder with 1 do you end up binding Color and Data0 implicitly say you bound 2 buffers but your fragprog only emits to one on purpose (maybe you have a few fragprogs). So I expect 2 is the correct answer. 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
