EGL and X spec ambiguities

[Brian Paul]

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

I think Tom mostly answered your question, but I think the crux of your 
problem is the difference in interpretation of "Display".

There's the X concept of Display which can be a collection of screens 
which is controlled by the X server.  Or you can think of the Xlib 
'Display' datatype which has a default screen field and can identify a 
particular screen.

For multi-screen EGL, I think you'd simply have to obtain an EGLDisplay 
handle for each screen.

-Brian