Bug 21867

Summary:	Feature request: Configurable pixel origin
Product:	Mesa	Reporter:	Stefan Dösinger <stefandoesinger>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Stefan Dösinger 2009-05-22 03:25:15 UTC

In OpenGL and Direct3D 10 a pixel coordinate specifies the center of a pixel on the screen. In Direct3D9 and earlier however, the origin is the top left corner of a pixel.

This causes problems for Wine, because we have to move the geometry by half a pixel to correct this difference. This is relatively painless with fixed function vertex processing, but in vertex shaders we have to insert extra instructions and occupy a shader constant / uniform to load these private constants. This causes problems with apps using all 256 constants on dx9 cards, and / or hitting the instruction limitation.

I have been told that most 3D hardware has a switch to switch between D3D and OpenGL mode. An OpenGL extension that allows Wine to switch between these modes would be very helpful. This switch could work as a glEnable / glDisable flag, or if the hardware needs it, a pixel format flag or flag at context creation would work too.

Comment 1 Zack Rusin 2009-05-22 05:26:49 UTC

Transgaming already proposed an extension to deal with that: fragment_coord_conventions which does it differently (via pragma's for glsl and program OPTION for fragment_program) so it's very unlikely that the way you propose will be implemented. You could of course sketch an extension that competes with what Transgaming proposed but you might as well simply ask that we implement fragment_coord once it's officially out.

Comment 2 Stefan Dösinger 2009-05-22 07:24:17 UTC

Do you have a link to the proposal? A GLSL pragma or ARB option would be fine with me, since fixed function correction is easy anyway.

I know of one convention that does something similar, but in the reverse way: If the pixel shader reads the current pixel position the coordianate system can be changed(upside down, half pixel stuff). That extension doesn't, as I understand it, not change the output pixel boundaries.

Comment 3 Henri Verbeet 2009-06-04 02:03:43 UTC

(In reply to comment #2)
> Do you have a link to the proposal? A GLSL pragma or ARB option would be fine
> with me, since fixed function correction is easy anyway.
> 
I haven't seen the spec, but they did mention it in their GDC presentation.

Comment 4 Adam Jackson 2009-08-24 12:32:17 UTC

Mass version move, cvs -> git

Comment 5 Ian Romanick 2010-08-25 17:07:10 UTC

I just want to be clear that what you're asking for is *not* GL_ARB_fragment_coord_conventions?

http://www.opengl.org/registry/specs/ARB/fragment_coord_conventions.txt

Comment 6 Eric Anholt 2010-08-25 17:35:23 UTC

There's this little knob in all hardware I've seen for the pixel center, for example brw_sf_unit_state.sf6.dest_org_[hv]bias on 965, DSTORG_HORT_BIAS() and DSTORG_VERT_BIAS() on 915 ("HORT" bias?  wtf.).  My guess was that that was what was meant.

Comment 7 GitLab Migration User 2019-09-18 20:22:03 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/959.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.