OpenGL as a driver.

Just a question about the use of OpenGL in windowing systems. I’ve written applications using OpenGL before, and noticed that the graphic operations available cover practically all of what I’d see necessary for a video card driver.

I’m wondering why OpenGL is normally seen as an extension to a window systems. With newer hardware available (and a software implementation of the entire pipeline available via Mesa), why not implement a windowing system using a fullscreen OpenGL rendering context, and then map X function calls to OpenGL counterparts?

The obvious gains from this are:

  • Faster OpenGL (App->OpenGL rather than App->GLX->X->OpenGL)
  • Antialiasing
  • The ability to specify on a pixel basis the exact output from any X program (especially the output from font rendering)
  • Subpixel positioning
  • Something almost as good as Aqua if not better

Also, if the X function calls are mapped correctly to OpenGL calls, existing X applications can run as per usual (similar to how you can run X applications under MS Windows using a third-party server).

Has this already been considered? Is it feasible? What would need to be added to OpenGL to make this happen?

Looking through some of the new extensions to OpenGL like GLS and GLC, I honestly believe that all that is required is there (use GLS in a TCP/IP stream to connect to server, use GLC for fast rendering of characters and as a font server, etc.)

Window management may be a problem, but could you use GLUT for this? Would we need a new GLRCM protocol (GL Rendering Context Management), or just make applications direct their output to a viewport?

Harves
pah06@uow.edu.au

This will break entire client/server stuff.
GLX was designed to allow communication with remote X server, which is not a very uncommon case. In modern computing ( especially home and business uses ) remote X server is very rare, though there still are a lot of places where it is. Also, GLX works fast enough to not complain on it. X eats more resources ( it suffers from client/server architecture ).

Originally posted by onyXMaster:
This will break entire client/server stuff.
GLX was designed to allow communication with remote X server, which is not a very uncommon case. In modern computing ( especially home and business uses ) remote X server is very rare, though there still are a lot of places where it is. Also, GLX works fast enough to not complain on it. X eats more resources ( it suffers from client/server architecture ).

Why would this break the client/server relationship? Using GLS (GL Streams Extension) proposed by SGI lets you package GL commands. Creating a server which receives these requests and executes them (the same idea as an X server) is what I was proposing?
I know GLX is fast enough, but I see the idea of it being an extension to allow OpenGL clients work over an aging protocol as kind of silly. Why run OpenGL over X, when OpenGL is the one designed for high-quality graphics? Why not run X on top of an OpenGL server?

Because no one wish to do it.
Also, writing accelerated X server relying on hardware is really better than writing X server relying on accelerated OpenGL interface. Also, X bitmap management, windowing functions, etc. will eat more resources when implemented on top of OpenGL - it lacks direct memory addressing. Imagine font and bitmap caching in off-screen VRAM ( common feature of accelerated X servers ), implemented in OpenGL ? What about 2D graphics ? A lot of small textures for bitmaps, or using Read/DrawPixels, which are really slow on most common drivers ? Texture thrashing along with insane amount of memory used texture contexts, with power of 2 limitation, or direct updating with TexSubImage consuming precious bandwidth is the first case problem. Second case seems obvious but 2d performance still sucks on most cards/drivers, also you lose most of hardware acceleration in this way. This will raise more problems that the gain will be.

I agree with the first comment “Because no one wished to do it”. I mean, the idea sounds a little crazy.

But consider what most graphics drawn on your display now are: vectors. Select colour -> draw line for X1,Y1 to X2,Y2, etc.
The number of times you’d use glDrawPixels would be limited to the number of times you needed to draw a real bitmap image. The idea would be that you can get all your nice, antialiased fonts, shaded buttons, cool looking icons w/o using bitmaps, but by using OpenGL calls instead.

Also, you could modify your OpenGL implementation (prob. Mesa) to be really optimised whenever the current matrix doesn’t included perspective calculations, thus regaining your 2D acceleration. The way I see it, X’s functionality is a subset of OpenGL’s functionality, and so whatever X can do, OpenGL can do.

Except for, of course, the direct memory access (only recently implemented in XFree86 via what amounts to a hack by passing information through shared memory). Assuming that all 2D drawing operations would go through X function calls anyway (ie. no DMA), I don’t see any difference between an OpenGL Server which tightly combines it’s OGL implementation with it’s client-side handling.

Yes, window management would be another thing to consider. Would probably put it actually inside the server as a loadable module, retaining user-choice but letting the window manager do funky things with the rendering contexts (read windows) that it manages. This is a bit that would require a seperate protocol to GLS.

Remember that the idea in the end is to drop X altogether, but in the mean time keep it as a compatability layer. Converting from X requests to OGS streams is a penalty you would have to pay.

Dropping X ?
Yes, X technology sucks … and sucks a lot.
But it is too late - too much software relies on it. You can try to start a small revolution but you’ll probably ( if not surely ) fail.
I like the idea itself. I like OpenGL - and really think that any gui can be implemented using it. Using vector graphics with antialiasing ( though even a lot of modern lacks hardware support ) is good ( we have an example - shockwave flash ), especailly for fonts. Also, the bitmap cache in grouped textures is a solution too.
But who will work on it ?
There are a lot of promising projects on sourceforge - but a lot of them are idle - because ones who were blessed with enthusiasm lost it now.
Money drive the world

Originally posted by onyXMaster:
Dropping X ?
But who will work on it ?
There are a lot of promising projects on sourceforge - but a lot of them are idle - because ones who were blessed with enthusiasm lost it now.
Money drive the world

Sadly, very true. And for myself, while I might try writing an OpenGL Server over the next few months (which also means implementing GLS and GLC, a non-trivial task), getting the X compatability in there looks a bit of a headache.
Oh well, can still dream.

I have this sense too.
Now I am working on he project of my own - OpenXL ( it has nothing to deal with graphics and especially GL at all ).
No one even wants to comment it - and I am not even speaking of assistance.
But … I think that I am on the right track.
At least I always was doing not what I should do - being a hardcore system programmer, still remembering times I wrote in octal codes for dual-processr PDP-11, and some custom microprocessors - now I work as internet programmer, network, system and database administrator for a small web design/hosting company.
I have a passion for game development - but … to make it through only programmer is not enough - but here in our city mostly no one is interested and/or capable of this.
So - I returned to library and tool development as hobby.
Hope my efforts will be rewarded at least by favor if not money

You are not crazy. I was thinking about something like this. My idea was to make a windowing system with openGL as the rendering system. Here is the key:
Forget X

Trying to maintain legacy with X would be nightmare. The simple fact is all relevant apps on X use a toolkit. Simply port the toolkit to our new windowing system, and boom lots quality apps.
What toolkit would this be? ever here of QT? KDE is based off of it, and it already cross platform (renders to X and win32 and embedded systems).
I believe that a windowing system should have 1 toolkit anyway.

If you or anybody is interested in this, email me… it would be pretty fun…

-Jess

onyX: I think this is how most of free software gets developed - people have their day jobs but do what they really like to at night. Hope you score something like the Linux IPOs, or get employed by a company interested in what you do.

jesseAd: My idea was to create something similar to X in that it has:

  • windows
  • fonts (via GLC)
  • some bitmap management
  • remotely accessible (via GLS)
  • architecture independent
  • widget-toolkit independent

That way, we tie ourselves to OpenGL only, rather than a combination of toolkit and OpenGL. What you should be able to do is rewrite the Qt code which is dependent on X to use this OpenGL Server instead. If you abstract things well enough (by making widget-makers call the OpenGL api), you should be able to make local clients access the server more directly, speeding up gfx, and effectively making QT render using OpenGL. I’d like to port GTK+ myself.

Also, X compatability shouldn’t be TOO hard (it is for me, but shouldn’t be for someone else) if we decided on only supporting the funadmental X protocol with practically no extensions. Supporting just the X protocol cuts down on the size of things a lot, as you don’t have to worry about all the fancy X/Motif stuff which I believe is all client-side anyway.

Finally, I think the server-side stuff should include audio capabilities, with my own preference being OpenAL (though this isn’t really suitable for discussion on an OpenGL bulleting board).

Anyways, Motif sucks.
It is too slow for capabilities it provide.

wow!, Imagine, If OpenGL was a driver, 100+ FPS in Windows 2001!

This might make the desktop more featureful and faster for some types of advanced things but it wouldn’t speed up existing 3D applications.

What you need is a whole new interface paradigm to drive this kind of thing, this is the reason this hasn’t happened. Infact it could obviously be done today on existing hardware. Just open a full screen window and get hacking on an OpenGL desktop, window manager etc. in a window (except the window is full screen). You’d get native direct rendering high speen interface without getting rid of the GLX protocol, nobody seems to have done this yet, funny that.

X is great, it’s an old philosophy, but it still is great. I can’t imagine working without it, I run simulations on other machines all the time from my slower PC.

With new gigabit LANs, remote OpenGL applications are very possible. And don’t forget about the DRI, it solves many of the issues with rendering OpenGL in X.

/skw|d