Re: Why run xserver on the OpenGL API?

Jon Smirl <jonsmirl-/[email protected]> wrote:

> --- Kendall Bennett <[email protected]> wrote:
> > Jon Smirl <jonsmirl-/[email protected]> wrote:
> > > 4) xserver modified to use the GL API.
> > 
> > Honestly I don't see the point of building an X server to live on top of
> > an OpenGL implementation. At the lowest level OpenGL is broken down into

Now I see what happened! I reposted the wrong message to the list! 
Hehehe. I will go back and repost my original message which was meant to 
go to the list which started this discussion.

> Think of OpenGL as being the device driver API for graphics hardware.

Sure, but OpenGL is *huge*. It is hard enough for developers to learn how 
to write 2D drivers, let alone 3D drivers. If you make OpenGL the low 
level DDI for the entire X server, it will bloat the size of the server 
significantly for just 2D support, as well as severly complicate the 
development of basic 2D driver functionality.

> Doing this has several nice effects:
> 
> 1) OEMs like NVidia/ATI have a very high level device driver API
> to do their optimizations below. 

They have that with a basic 2D API already, for 2D operations anyway. 
IMHO for 2D OpenGL is way to high level, because it exposes many, many 
different code paths that are irerlevant for basic 2D rendering. To make 
the 2D fast without wasting resources on stuff that will never be used, 
the developers need to be smart enough to know what stuff is on the fast 
path and worth optimising and what is not. As it stands right now all the 
OEM OpenGL drivers from the likes of ATI and NVIDIA are highly optimised 
for 3D, not 2D. I wouldn't be surprised if the existing X servers will 
run rings around an OpenGL based solution primarily because ATI and 
NVIDIA could care less about massive performance of 2D operations in 
OpenGL.

> 2) With OpenGL under xserver all windows will always have the
> OpenGL API available. xlib can slowly phased out. OpenGL is a well
> designed API suitable of the next 10 years. 

For 3D yes, for 2D no, I don't think so. OpenGL completely lacks any 
decent API for quickly getting bitmaps to and from the screen in a way 
that is easy to accelerate cleanly in a low level driver. By this I mean 
a decent API for getting system memory bitmaps in any color depth 
(including 1bpp) to the screen, as well as the ability to create bitmaps 
that live in offscreen memory that can be quickly drawn to the screen. 
Putting them into textures IMHO is a terrible hack, only needed because 
the core OpenGL API gives you no other choice.

> 3) OpenGL as the device driver API will allow for 10 years worth
> of hardware improvements. 2D APIs are at the end of life in term of
> chip improvements. Most 3D functions that are done in Mesa software
> today will be done in hardware is a few years. 
> 
> 4) 90% of new hardware is 3D capable today. In 10 years year 100% will be.
> The bandwidth demands of a display in 2010 with a 10K by 10k floating
> point framebuffer on a GPU will be enormous. 

Actually I would probably say 100% of all new hardware is 3D capable, 
unless you are including new PDA chipsets. But even shipping PDA chipsets 
will be 3D capable next year.

However the fact that the hardware is 3D capable is irrelevant for 2D 
functionality. The reason being that 2D is simple, and 10 years from now 
2D will be exactly the same as it is now. Still simple. This is not to 
say 3D is not useful. Rather 3D should be an additional API that can be 
used as well as 2D, but it should not be a requirement. 2D and 3D need to 
work together, but 2D should be available without any 3D requirements.

> In ten years we are going to have GPUs that execute OpenGL as
> their native instruction stream, we are halfway there already. X's
> internal architecture has to change now if we are going to benefit
> from this several years from now. 

I doubt we will ever see a GPU that will execute OpenGL as their native 
instruction stream. 3D is moving quickly into the realm of programmable 
vertex and pixel shaders and all new hardware is completely programmable. 
This trend will continue down the track, and OpenGL will change over time 
to incorporate better support for this kind of programmable hardware.

Also you forget about DirectX, which has a much larger market share than 
OpenGL. DirectX 9 for instance has a low level assembler shader language, 
but hardware does not even use that as its native language. Instead they 
use an even lower level language and compile from DX9 ASM into their 
native GPU format.

> MS Longhorn has already made the switch - GDI to DirectX. This
> ensures that the graphics hardware vendors are going to keep
> improving and making graphics hardware even cheaper. Linux and
> xserver need to ride this trend. 
> 
> Think of the future - enabling 3D support everywhere will allow new
> applications to be built that haven't even been dreamed of yet.
> Here's a simple one: why should toolkits make buttons with bitmaps
> giving a fake 3D appearance when you could just draw a 3D button?
> Think about moving the light source around on a desktop drawn with
> a true 3D toolkit. 

If that is the goal you wish to achieve, then don't just blindly assume 
OpenGL is the API you should be using for device driver development! If 
you consider that for a 3D desktop you are not likely to need many of the 
features of OpenGL, it would be a lot easier to define a simpler, 3D 
subset API for desktop development that gets rid of the complexity of 
OpenGL for the developer. 

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~