This is such a corner case I just want the easiest behaviour for everybody.  
The point of the GL provoking vertex extension is to allow people to port DX9 
games etc to GL more easily.  DX9 has no quad primitive, so the primary user of 
this extension has no real interest in this flag.  I would prefer just to say 
we don't care about this for quads, but if we're being forced to care, I'd like 
feedback from the driver maintainers (first time I've used that phrase for 
gallium!) on which way to jump.  So far it sounds like nv can work either way, 
svga has to decompose quads anyway so doesn't care, i965g likewise.  Does r300 
have a preference?

In terms of a spec - yes, we need one, and we need to keep it up-to-date.

My plan on keeping it up-to-date (once we've built the initial spec) is just to 
nak interface changes that don't include spec updates.  

Ideally that would mean being able to produce a single patch or patch series 
that contains the changes to the headers *and* the changes to the spec, so that 
all is being considered together.  That means in turn having the spec in the 
git tree.  Ideally we'd have an online version as well, in a wiki style.  I'm 
interested in suggestions for how to make this happen.  Ideally we *wouldn't* 
pollute the header files with so much text and markup that they become 
unreadable - ie. I don't really like the idea of doing the spec with doxygen - 
I'd prefer the headers to be human-readable.  Thoughts?

Keith




________________________________________
From: Corbin Simpson [mostawesomed...@gmail.com]
Sent: Friday, December 18, 2009 7:11 PM
To: Christoph Bumiller
Cc: mesa3d-dev@lists.sourceforge.net
Subject: Re: [Mesa3d-dev] [PATCH] gallium: add  
PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION

NAK to this series. Keith hasn't responded, although I expect that he
would also NAK this. I would much rather have quads just never respect
flatshade_first as part of the spec, than jump through these weird
param hoops.

Should somebody be documenting the API? I keep on having these kinds
of stupid edge questions come up; r300 apparently is the quirkiest
hardware of that generation.

~ C.

On Fri, Dec 18, 2009 at 2:15 AM, Christoph Bumiller
<e0425...@student.tuwien.ac.at> wrote:
> Marek Olšák schrieb:
>> Hi,
>>
>> GL_ARB_provoking_vertex states that quads are not required to abide
>> the provoking vertex convention, and the actual hardware and/or driver
>> behavior can be queried with
>> GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION.
>>
>> I'd like to add a new PIPE_CAP_* to query for this capability in
>> Gallium, as it appears R3xx-R5xx hardware doesn't support the first
>> vertex convention for quads and I'd like the driver to behave
>> correctly. Fortunately, other primitive types are supported.
>>
>> I decided to use the name "quads follow flatshade_first convention"
>> instead of "provoking vertex convention" because the actual state
>> variable in pipe_rasterizer_state is called flatshade_first.
>>
>> The attached patch:
>> - adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
>> - adds the query in the Mesa state tracker
>> - and updates softpipe and llvmpipe to return 1 when this cap is
>> queried, and r300g to explicitly return 0
>>
> You can add a "return 1" for nv50, too, in case you do push this patch.
> I just tested and for quads I can also make them use either the first or
> the last vertex's colour, i.e. flatshade convention is respected.
>
> Thanks, Christoph.
>> Please review/push.
>>
>> Cheers.
>>
>> Marek
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mesa3d-dev mailing list
>> Mesa3d-dev@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>



--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<mostawesomed...@gmail.com>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to