On Wed, 2010-01-27 at 10:05 -0800, Brian Paul wrote: > José Fonseca wrote: > > On Wed, 2010-01-27 at 09:24 -0800, Brian Paul wrote: > >> Keith Whitwell wrote: > >>> On Wed, 2010-01-27 at 09:09 -0800, José Fonseca wrote: > >>>> On Wed, 2010-01-27 at 08:49 -0800, Brian Paul wrote: > >>>>> Luca Barbieri wrote: > >>>>>> Changes in v2: > >>>>>> - Caps are added in a separate, subsequent patch > >>>>>> > >>>>>> This adds two TGSI fragment program properties that indicate the > >>>>>> fragment coord conventions. > >>>>>> > >>>>>> The properties behave as described in the extension spec for > >>>>>> GL_ARB_fragment_coord_conventions, but the default origin in > >>>>>> upper left instead of lower left as in OpenGL. > >>>>>> > >>>>>> The syntax is: > >>>>>> PROPERTY FS_COORD_ORIGIN [UPPER_LEFT|LOWER_LEFT] > >>>>>> PROPERTY FS_COORD_PIXEL_CENTER [HALF_INTEGER|INTEGER] > >>>>>> > >>>>>> The names have been chosen for consistency with the GS properties > >>>>>> and the OpenGL extension spec. > >>>>>> > >>>>>> The defaults are of course the previously assumed conventions: > >>>>>> UPPER_LEFT and HALF_INTEGER. > >>>>> Sorry for the slow reply on this. > >>>>> > >>>>> It looks like you've solved the fragcoord problems in a clean/logical > >>>>> way. I haven't seen any objections, so I think we can move forward > >>>>> with this. > >>>> Didn't Keith had objections on this, on another thread? Luca re-sent the > >>>> patch but I don't see the remark being addressed. > >>> I don't think my concerns are fatal to this approach, I just need to > >>> understand the issues a bit better before signing off on it. > >> I meant I didn't see objections to Luca's latest patch series. > >> > >> After studying the issues for a while I think Luca's on the right > >> track. I'll try to summarize. > >> > >> > >> Re: coord origin upper/lower-left: > >> > >> A GPU may natively implement lower-left origin or upper-left origin > >> (or both). With GL_ARB_fragment_coord_conventions, the user may want > >> to use either of those origins. By asking the driver what it supports > >> we can avoid extra Y-inversion code in the shader. Drivers don't have > >> to do anything special other than tell the state tracker (via new cap > >> bits) what it can do. > >> > >> > >> Re: pixel center integer: > >> > >> Again, depending on what the GPU implements we may need to > >> add/subtract a 0.5 bias to the fragment coord register in a fragment > >> shader. This is orthogonal to pipe_rasterizer_state:: > >> gl_rasterization_rules. > >> > >> With Luca's patch we query what the GPU can support and submit TGSI > >> shaders which either tell the driver which convention to use, or > >> submit shaders that implement the bias themselves. > >> > >> The new TGSI shader properties are needed because the origin/center > >> state can change per-shader (it's not per-context) and for the sake of > >> drivers that can support both conventions. > >> > >> > >> I too was concerned whether this was all really needed but I think it is. > > > > It appears everybody was in agreement after all. > > > > I really don't have an opinion on this, as I don't understand the > > different rules. From what I could gather it seems that even in the most > > limited hardware it is always possible to expose this new functionality > > either by tweaking shaders or flushing contexts before switching > > hardware global device settings. > > Right. We ask the driver what it can do and the state tracker emits > extra instructions to invert/bias the fragcoord as needed. > > > > I'm a bit confused what will > > pipe_rasterizer_state::gl_rasterization_rules mean at the end of the > > day. Is it still necessary? > > Yes, it's still needed. gl_rasterization_rules controls which pixels > are hits/written when rasterizing a triangle regardless of the shader. > > The pixel_center_integer controls what value the fragment shader gets > when it reads gl_FragCoord (either x.0 or x.5).
Ah OK. Thanks for the explanation! 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
