EGL and X spec ambiguities

[Tomas Carnecky]

michael giovinco wrote:
> I hope this is not too much off topic but I'm working on developing
> OpenGL ES drivers for NVIDIA chipsets. I'm currently working on
> implementing EGL for use under X and I've run into some issue that
> really confuse me. From reading the archives of this list, I've seen
> that similar issues have come up before and maybe it's not just me who
> has these concerns.
> 
> My main confusion is the over what EGL calls a "display". According to
> the EGL 1.3 spec: "In most environments a display corresponds to a
> physical screen." Notice is says "most", but not all. Later, when it
> talks about how to use the function eglGetDisplay to get a display, it
> uses X as an example: "... an EGL implementation under X windows would
> require display_id to be an X Display...". This implies that an EGL
> display is equivalent to an X display.
> 
> In X, a Display can consist of multiple X screens (a X screen being a
> single head on a single device in most cases). These various screens
> can refer to different heads on a single device or could even be
> different heads on different devices. This means that an EGL display,
> if it is truly equivalent to an X display, might actually refer to
> different heads and maybe even different devices. Fortunately, when
> creating a window surface in EGL we specify a window as a paramter. In
> X, a window is confined to a single screen so this removes the
> ambiguity as to which head and device that surface belongs to. The
> problem exists when creating contexts though, since we only specify an
> "EGLDisplay" when creating a context; we don't get to specify a screen
> or head/device parameter.  Thus we don't know what screen the context

And neither do you in GLX. There you pass glXCreateContext() only a
'Display' as well. But to which physical screen the 'Display' points to
was specified when you opened it (using XOpenDisplay(":0.1") for
example). So eglCreateContext() knows on which screen to create the
context by looking at EGLDisplay that was passed to it which points to
an X 'Display' which has a physical screen encoded in it.

> refers to until we bind it to a surface (in eglMakeCurrent). Later on
> we could rebind that context to another surface with another call to
> eglMakeCurrent and that surface might lie on a different device. You
> can see the obvious issues that arise when this context refers to
> texture or vertex buffer objects that live in the video memory of one
> device but not the other.
> 
> I'm not sure what is the correct way to view this. In my opinion, it
> seems to me that the EGL spec is just... wrong. GLX doesn't have this
> problem because it requires you to specify the screen you are dealing
> with when you are creating contexts and drawables. The GLX

Where did you get that idea from? Neither XCreateContext() nor
XCreateWindow() take a screen parameter.

> specification also says that contexts and drawables must refer to the
> same screen in order to be bound together. No such requirement exists
> in the EGL spec, and in fact, it can't since EGL doesn't know this
> information. So either the EGL display is NOT equivalent to an X

EGL does know this information, just as GLX knows it. So I would say
that that requirement was forgotten when the spec was written, but that
it is indeed there.

> display or it is in which EGL actually allows contexts that could bind
> to different devices. In the event that an EGL display shouldn't be
> passed an X Display as the display_id parameter to eglGetDisplay,
> well, then what is an appropriate parameter that should be used
> instead? On the other hand, if an EGLDisplay is really meant to refer
> to a X display then we are back to the issue of "screen-less contexts"
> that I mentioned earlier. In addition, since creating pbuffers and
> pixmaps doesn't require a window parameter those kinds of surfaces
> would be without a screen too. How then would EGL determine on what
> device they should live? Another solution is too perhaps simple use

But they require an EGLDisplay parameter, which, again, supplies the
needed information (which screen to create them on) to the implementation.

> the "default screen" as specified in the X Display structure. But this
> isn't adequate either since it precludes the application from creating
> a context on another screen in an X Display.
> 
> I'm sorry for the length of this post but I hope you can see my
> confusion here, and I'd greatly appreciate if someone could clarify
> this for me. Thanks.
> 
> - Mike

tom