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). -Brian ------------------------------------------------------------------------------ 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
