> > (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. > > From what I can see i965 + r300-r500 and at least nv40 from talking to Ben > would need fragment program changes to emit to each buffer instead.
Okay I'm failing to get this to work, I'll run down the ideas I had so far that failed. 1. Have the mesa state tracker add the extra output instructions to the fragment program at compile time. Failed: no where to actually invalidate the current fragment program. 2. Add a flag to mesa context and have mesa add the extra output instructions at compile time (prog parser + texenvprogram). Failed: no where to tell that the FP needs updating has changed so needs to be recompiled. this works for texenvprog but fails for user programs. Now the other place to do this is like i965 does, in the driver but from a gallium pov it seems like something the state tracker should deal with at TGSI doesn't seem to care about the nuance between FRAG_OUTPUT_COLOR and FRAG_OUTPUT_DATAx http://people.freedesktop.org/~airlied/fp-convert-color-data-fail-one.patch Has the fail for case 2, the programopt.c changes are most likely correct, and I guess I can do option 1 with some sort of state tracker program invalidation (i.e. freeing the TGSI tokens and letting it get recompiled.) Ideas? 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
