On 12/19/2009 04:11 AM, Corbin Simpson wrote: > 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. How about we kick out quads altogether ? Having to flip the first/last bit depending on *what's being drawn* is quirky. I realize < nv50 don't follow the convention for quads (at least that's what the spec says), so I'm outnumbered, but I don't see the harm in following what OpenGL does here, i.e. just have the query. > > 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 >> > > >
------------------------------------------------------------------------------ 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
