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 ------------------------------------------------------------------------------ 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
