As I recall, I wanted to fix the piglits when doing GS or ARB_viewport_array for nv50. I believe Ian shot it down. This was ~1-2 years ago, so I don't remember the specifics.
-ilia On Tue, Dec 1, 2015 at 2:37 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Thinking about this, are there really apps out there which get it wrong? > piglits can be fixed easily. > If some app did that seemingly wrong, it might have been due to the > bogus query. That is, if it switched to first provoking vertex > convention, then asked for the provoking vertex layer, it would have > gotten first vertex convention. Theoretically it might then have used > shaders which took that into account (and even regardless if it later > switched back to last vertex convention or not). But assuming > unitialized outputs have to be copied over from other vertices really > seems a bit strange... > > Roland > > > Am 01.12.2015 um 19:41 schrieb Roland Scheidegger: >> I don't think that will work with draw (can't see why it would), and >> don't plan on fixing it (at least not now). >> In d3d10, this of course would work (at least if you emit the layer per >> prim), because it requires the layer info to be taken from the provoking >> (first) vertex. But that doesn't seem to be very sane for GL... >> >> Roland >> >> >> >> Am 01.12.2015 um 19:25 schrieb Ilia Mirkin: >>> Irrespective of any spec lawyering you might do, we have some piglit >>> tests which basically assume that things like >>> >>> gl_Layer = foo; >>> gl_Position = ... >>> EmitVertex(); >>> gl_Position = ... >>> EmitVertex(); >>> >>> will always work. I believe this was based on the theory that some >>> applications actually do this, although tbh I don't remember the >>> details. We ended up adding a "latch" in nouveau/codegen to just >>> always re-emit the previously-computed layer at EmitVertex() time. >>> >>> -ilia >>> >>> >>> >>> On Tue, Dec 1, 2015 at 12:43 PM, Roland Scheidegger <srol...@vmware.com> >>> wrote: >>>> Trying to fix some draw bugs with layer/vp outputs (and clipping), I was >>>> wondering if GL actually guarantees sane results if the layer/vp index >>>> isn't the same on all vertices. And sure it seems it does, albeit it's >>>> implementation-dependent. Specifically (from gl 4.4 core, page 388) >>>> >>>> "viewport index is implementation-dependent and thus portable >>>> applications will assign the same layer and viewport index for all >>>> vertices in a primitive. The vertex conventions followed for gl_Layer >>>> and gl_ViewportIndex may be determined by calling GetIntegerv with the >>>> symbolic constants LAYER_PROVOKING_VERTEX and >>>> VIEWPORT_INDEX_PROVOKING_VERTEX, respectively. For either query, if the >>>> value returned is PROVOKING_VERTEX, then vertex selection follows the >>>> convention specified by ProvokingVertex (see section 13.4). If the value >>>> returned is FIRST_VERTEX_CONVENTION, selection is always taken from the >>>> first vertex of a primitive. If the value returned is >>>> LAST_VERTEX_CONVENTION, the selection is always taken from the last >>>> vertex of a primitive. If the value returned is UNDEFINED_VERTEX, the >>>> selection is not guaranteed to be taken from any specific vertex in the >>>> primitive." >>>> >>>> However, what mesa does is just return Light.ProvokingVertex. This means >>>> that if you switch the provoking vertex, the result will be different, >>>> which seems quite inappropriate for this implementation-dependent query. >>>> Albeit I'm not sure what the result really should be, that is if all >>>> drivers will do the same - I guess though UNDEFINED_VERTEX would always >>>> be correct. >>>> >>>> >>>> Roland >>>> _______________________________________________ >>>> mesa-dev mailing list >>>> mesa-dev@lists.freedesktop.org >>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=IChBdIDeVZLxc6pAX_ISVsm1apkVwcteaBV8hJWm02U&s=Iu2Nb_m2ioE0OGuK-t0WJzRve4z6PddDe_OPIswS9-w&e= >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
