[POSSIBLE SPAM] Re: EGL and X spec ambiguities

[michael giovinco]

On 12/9/07, zeAtYahoo XtraADSL <zelco at xtra.co.nz> wrote:
> hi,
>
> - may i ask you how do you do it... i mean, where did you start,
> are you building up on some existing source code or writing it from scratch?
>

We are starting from scratch, but we have NVIDIA sample drivers and
documentation in addition to an OpenGL driver we wrote for an older
3Dlabs GPU from which we base our work on.

> - where does Mesa fit in your project,

Actually, it doesn't (which is why this thread is a kind of off
topic). I've worked with Mesa in the past (adapting it for a 3D
display I worked on), but this project does not use Mesa at all.

> are you using any source code derived from it?
>

Nope, all of our source is written from scratch.

> - why do you need X? in my opinion graphic driver should be lower level than
> windowing system, so X uses/depends on the graphic driver and not the other
> way around
>

You are right, X isn't really relevant to the driver development
itself, but we also need to write some kind of context management
system in order to use our driver and EGL seemed to be the logical
choice. We have an X Server we wrote in the past and it would make
sense that our EGL implementation worked with it. This is where all
the confusion regarding the interoperability of EGL and X came from.

>
>
> - are you aware of Trolltech Qt, Qtopia, Qt Embedded
> http://trolltech.com/downloads/
>
I've used Qt a bit in the past, though I hadn't heard of Qtopia or Qt
embedded before but I'll check them out.

>
> - are you aware of Scitech and MGL/SNAP drivers?
> http://scitechsoft.com/products/dev/sdk_home.html
>

This seems really interesting. Unfortunately it seems like their SNAP
drivers have been discontinued and they aren't working on them
anymore.

>
> if you developing drivers you might find this interesting -
> "An approach to solving the "device driver crisis"
> http://www.linuxdevices.com/articles/AT4396090607.html
>
>
> here is my project page:
> Linux based OpenGL development system without X
> http://www.geocities.com/ze_aks/index.html
>
>
>
>
> cheers,
> zelko
>
>
>
>
>
> michael giovinco <gio at post.harvard.edu> 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.
>
> - Mike
> _______________________________________________
> dri-egl mailing list
> dri-egl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-egl
>
>