I addressed this in the docs already, see the note in flatshade_first in
Rasterizer. In short, we should always provoke quads GL-style.
Posting from a mobile, pardon my terseness. ~ C.
On Feb 6, 2010 12:39 PM, "Marek Olšák" <mar...@gmail.com> wrote:
Hi,
I got some time to revisit the issue from December regarding quads not
following the first provoking vertex convention.
The attached patch adds PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST to gallium,
which gets propagated to the return value of
glGet*(GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, ...).
Please review/push.
Marek
On Fri, Dec 18, 2009 at 10:58 AM, José Fonseca <jfons...@vmware.com> wrote:
> On Thu, 2009-12-17 at 20:41 -0800, Marek Olšák wrote:
> > 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
> >
> > Please review/push.
> >
> > Cheers.
> >
> > Marek
>
> Hi Marek,
>
> One problem I have with this patch and many of past get_param changes
> for that matter, is that it changes default behavior and forces all pipe
> drivers to be updated. It is not the first time that a get_param changes
> broke drivers because it. I happened with
> PIPE_CAP_BLEND_EQUATION_SEPARATE.
>
> As the number of drivers is increases this is a no-no. It also
> complicates writing drivers since they have to answer a large number of
> queries, most of which are specific to one or two particular hardware
> devices.
>
> IMO, there are two ways to overcome this:
>
> a) when introducing new PIPE_CAP_xxx have its semantics such that 0 will
> yield the previous behavior
>
> b) change get_param/paramf prototype so that it is passed the default
> value as an argument.
>
> That said, reading
> http://www.opengl.org/registry/specs/EXT/provoking_vertex.txt , issue #2
> (How should quads be handled?) it seems that 0 is actually a better
> default -- provoking vertex of quads does not apply to D3D and is only
> relevant for that extension. So I don't oppose for this to go in as is.
>
> But, independent of this change, lets fix the get_param/paramf calls.
> Keith, does b) above sound good to you?
>
> Jose
>
>
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
