On Tue, Apr 13, 2010 at 6:42 AM, 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.
Whatever's easiest, just document it. I'd be cool with:
DECL IN[0], COLOR, PERSPECTIVE
DECL OUT[0], COLOR
MOV OUT[0], IN[0]
END
Effectively being a write to all color buffers, however, this one from
progs/tests/drawbuffers:
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR
DCL OUT[1], COLOR[1]
IMM FLT32 { 1.0000, 0.0000, 0.0000, 0.0000 }
0: MOV OUT[0], IN[0]
1: SUB OUT[1], IMM[0].xxxx, IN[0]
2: END
Would then double-write the second color buffer. Unpleasant. Language
like this would work, I suppose?
"""
If only one color output is declared, writes to the color output shall
be redirected to all bound color buffers. Otherwise, color outputs
shall be bound to their specific color buffer.
"""
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
<mostawesomed...@gmail.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
