On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
<mostawesomed...@gmail.com> wrote:
> 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.
> """
Also, keep in mind that writing to multiple color buffers uses
additional memory bandwidth, so for performance, we should only do so
when required.
Alex
------------------------------------------------------------------------------
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
