On 6/16/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > > Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the > > mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will > > likely provide OpenGL/EGL's that don't use fbdev. > > One thing that bothers me about this whole discussion is the mounting > level of interface complexity. > > It is not just bad as far as debugging is concerned but will also present > a barrier to easy experimentation with the code. Will we have new > developers in 5 or 10 years if the interface is so complex that it took > several years just to create it ?
We started off with dumb framebuffers. Next we added bitblt and things were still simple. But along came the GPU and that was the end of simple. The level of the driver API has to exceed the level of hardware capability or the hardware is useless. What good is a hardware convolution filter if the only driver interface is fbdev? OpenGL and DirectX are the drivers of GPU capability. So in order to make use of the all the hardware capability we need to pick an API that exceeds the hardware's capability. It's better if the API significantly exceeds the hardware capability because next gen hw is going to automate some of the things done in software today. We have several choices: 1) XAA, hardware integration already far exceeds it 2) DirectX, MS patent problems 3) OpenGL, open well documented 4) write our own, we do all the work I picked #3 since I think it is the best fit for Linux since we already had DRI/mesa. Other groups are making other choices. Writing drivers for the #3 model isn't that bad considering what you get for the effort. No matter which model you pick you have to write all of the functions to expose your hardware. But we have large pre-existing common libraries. I took the existing code in fbdev, mesa, Xegl and had a framebuffer EGL driver going in a couple of days. That's the general background. Now things get messy. Linux has VT swap. With VT swap you hit a magic key and another device driver gets to take over the hardware. This driver is free to reset the hardware and wipe it's VRAM. Hit another key and control is returned to you, now you have to recover. Linux also has three major device drivers all trying to control the same piece of hardware: fbdev, DRM, XAA. There are another twenty minor ones. Development between the groups writing these drivers is often uncoordinated. Now throw in things like suspend/resume on laptops. Plus 512MB of VRAM that can go poof on VT swap And don't left me forget that GPUs have hundreds of commands and run as asynchronous processors fed by DMA queues. All of this makes the environment for writing graphics drivers on Linux extremely complex. A lot of this is historical complexity. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
