Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

View Poll Results: Should NVIDIA support the development of a fast Linux kernel graphics interface?
Yes, take leading role together with other graphics vendors 26 57.78%
Yes, but only if hardware-specific drivers are GPL 11 24.44%
Yes, but only under the dictate of an independent OpenSorce project 4 8.89%
I don't think another Linux graphics layer is needed 5 11.11%
Multiple Choice Poll. Voters: 45. You may not vote on this poll

Reply
 
Thread Tools
Old 02-16-05, 07:45 AM   #1
mklemm
Registered User
 
Join Date: Apr 2003
Posts: 27
Lightbulb NVIDIA generic high-performance kernel interface wanted!

As many posts in this forum show, it seems like the Linux graphics architecture is still a source of trouble for most users.

An important issue specific to Linux is the co-existence of different, hardware-dependent graphics driver architectures at the same time on the same hardware.
The most important of them are the X Window System (X.org) and the various framebuffer console drivers (fbdev). There are, however, many more solutions to get Linux to display graphics, like KGI/GGI (seems dead now), libSVGA, commercial X-servers, ...

A unified, generic, UI-independent, but maximum-performance graphics architecture would eliminate a lot of problems currently discussed in this thread.

We request and encourage that NVIDIA take an active, leading role in the specification and implementation of such a graphics interface, because NVIDIA have already shown that they take Linux as a graphics platform seriously.

Joint efforts in the Open Source Communitiy and with commercial hardware ad software vendors can make this vision come true.

Vote for this petition right here!

Attached is a diagram showing a proposal for a graphics architecture that is both generic and performant while maintaining backwards compatibility with fbdev/fbcon from the applications perspective. It also tries to limit kernel-space implementations to a minimum.

To be a bit more specific about why and how I think it is necessary to rework the Linux graphics architecture:
  • Currently, graphics on Linux is hard to maintain, configure, and develop applications against. Different hardware-dependent graphics layers inherently have interoperability issues which must be dealt with by hack solutions that limit stability and bind development resources better spent elsewhere. To switch from X11 to a framebuffer console now, for example, involves a complete change of state of the graphics hardware. This state has to be maintained, and many things just don't work reliably in this areas, resulting in screen lockups, X Server crashes, and declared incompatibility between fbdev drivers and X11.
  • Compared to many other operating systems, Linux's graphics hardware driver architecture is not state-of-the-art. Now we have the opportunity to go past what others have at the moment and put Linux into a technological leader position in that area, too.
  • The only fully-supported graphics system on Linux is X11 at the moment. High-performance-graphics are limited to that architecture. The X11 architecture, however, mixes hardware dependent drivers with user interface aspects. Users who do not need or want the UI stuff are still forced to maintain, configure, and install it in order to get good graphics performance.
  • Alternative and generic graphics layers that exist either lack vendor support or are architecturally unsuitable as a high performance graphics interface. The KGI/GGI, for example, is pretty much dead today, and fbdev/fbcon is just a least-common-denominator solution originally developed as a text console driver for systems don't have a VGA text mode. No high-performance X11 server exists for use on top of any of the alternative graphics layers. We need an architecture backed by leading industry partners at a layer below X11.
  • Applications like e.g. mplayer include their own drivers for a great number of graphics layers, because there is no guarantee that a specific graphics layer is available and working flawlessly on the target machine. We need a standardized solution that developers with linux as a target platform can depend on.
  • The same goes for input devices, because the are also managed by e.g. an X server and maybe at the same time by GPM or some other application-specific driver.
  • If you want to use more than one graphics layer at the same time, you must check the compatibility between them and configure both of them redundantly.
  • While the Freedom of Choice between different graphics systems is definitely a Good Thing, we must keep in mind that application developers are having a hard time supporting all of those interfaces grown over time. Sometimes, in fact, less might be more. The past few years were a great experience for the linux community in the graphics area to see what graphics system would do best. This evolution is not finished yet, however, and a unified generic graphics driver with industry support is just a consequent step in the development of Linux.
  • Every effort that isn't backed by leading graphics hardware players is doomed.
Attached Thumbnails
Click image for larger version

Name:	GraphicsArchitecture.png
Views:	429
Size:	23.7 KB
ID:	10309  
mklemm is offline   Reply With Quote
Old 02-20-05, 09:08 PM   #2
clash rocker
Registered User
 
Join Date: Apr 2003
Location: Blue Mtns. Australia
Posts: 12
Default Re: NVIDIA generic high-performance kernel interface wanted!

This is a great idea. But what makes you think KGI or LibGGI are dead? The GGI Project is still active today. I suggest you check out the LibGGI Home Page. Also KGI is still going, although somewhat slowly on Linux side, and antrik is working on a Hurd port. Both projects remain active on the FreeNode IRC network check 'em out :-)
KGI4BSD has slowed in the new year, but made some major progress last year. I was running LibGGI demos under KGI on FreeBSD-5.3 with a Ti4800 using VESA. Results were awesome.

I would love it if NVIDIA took an interest in KGI. I think a unified high performance graphics architecture is an awesome idea, and KGI is the way...if more people get involved. KGI supports Linux and FreeBSD already with interchangable drivers.
clash rocker is offline   Reply With Quote
Old 02-21-05, 02:47 AM   #3
PrakashP
gentoo ~x86_64 user
 
PrakashP's Avatar
 
Join Date: Jul 2004
Location: Germania
Posts: 213
Default Re: NVIDIA generic high-performance kernel interface wanted!

Uhm, why do you want an unaccel. fb driver? An accel. would be better, isn't it?
PrakashP is offline   Reply With Quote
Old 02-21-05, 05:24 AM   #4
Lithorus
Registered User
 
Lithorus's Avatar
 
Join Date: Sep 2004
Posts: 783
Default Re: NVIDIA generic high-performance kernel interface wanted!

Quote:
Originally Posted by PrakashKC
Uhm, why do you want an unaccel. fb driver? An accel. would be better, isn't it?
What functions in the fb really requires it to be accelrated, that's what you have X for... Not to mention it messes up accelration in X.
Lithorus is offline   Reply With Quote
Old 02-21-05, 05:28 AM   #5
PrakashP
gentoo ~x86_64 user
 
PrakashP's Avatar
 
Join Date: Jul 2004
Location: Germania
Posts: 213
Default Re: NVIDIA generic high-performance kernel interface wanted!

No, I think it makes more sense to accelearte the fb driver and just make X to use this. I heard Solaris or some other *nix does it this way for some cards.
PrakashP is offline   Reply With Quote
Old 02-21-05, 06:49 AM   #6
AlxMAX
Registered User
 
Join Date: Sep 2004
Posts: 104
Default Re: NVIDIA generic high-performance kernel interface wanted!

I think this change (depicted in the mklemm's diagram) should make the things easier for the driver developpers. This should make the thinegs easier for the X server developpers too: they don't have to focus on the drivers anymore! So, I agree!
__________________
Hardware: Dell Inspiron 2650, P4M @ 1.8 GHz, chipset i845, 512 MB RAM, nVidia Geforce 2 Go with 16 MB RAM, 20 GB HDD.
Software: BIOS A10 (3.11.01.52.AB video BIOS), Fedora Core 4, Kernel 2.6.12-1.1398_FC4, Xorg 6.8.2, NVIDIA 7667 drivers.
AlxMAX is offline   Reply With Quote
Old 02-21-05, 11:26 AM   #7
Lithorus
Registered User
 
Lithorus's Avatar
 
Join Date: Sep 2004
Posts: 783
Default Re: NVIDIA generic high-performance kernel interface wanted!

Quote:
Originally Posted by PrakashKC
No, I think it makes more sense to accelearte the fb driver and just make X to use this. I heard Solaris or some other *nix does it this way for some cards.
The accelrated fb doesn't have the slightest 3d support, not to mention things like RENDER and Composite. It's just what it sounds like a "frame buffer" driver, eg. support for faster and larger 2d screens.
Lithorus is offline   Reply With Quote
Old 02-21-05, 01:19 PM   #8
PrakashP
gentoo ~x86_64 user
 
PrakashP's Avatar
 
Join Date: Jul 2004
Location: Germania
Posts: 213
Default Re: NVIDIA generic high-performance kernel interface wanted!

Well, put the lacking functions into the X11 layer, where is the problem? This is the correcty way of modularization.
PrakashP is offline   Reply With Quote

Old 02-21-05, 04:34 PM   #9
silentplummet
Registered User
 
Join Date: Jun 2004
Posts: 94
Default Re: NVIDIA generic high-performance kernel interface wanted!

never happen.
silentplummet is offline   Reply With Quote
Old 02-23-05, 04:02 AM   #10
mklemm
Registered User
 
Join Date: Apr 2003
Posts: 27
Default Re: NVIDIA generic high-performance kernel interface wanted!

Quote:
Originally Posted by PrakashKC
No, I think it makes more sense to accelearte the fb driver and just make X to use this. I heard Solaris or some other *nix does it this way for some cards.
That's true: On Solaris SPARC, it's just that way. You have a framebuffer driver and a hardware-independent X Server (Xsun). Everything hardware-related is done on the framebuffer layer.

What I wanted to show in the diagram is, that we need a minimally accelerated fbdev driver for the sake of system stability and ease of implementation, but additionally need another kernel-based interface (like DRI ord the "nvidia" module today), that can INTERACT with the fbdev and can implement all the nice features we want today, like RENDER acceleration, OpenGL direct rendering, ACPI, Multihead ...
These two modules (fbdev and the new DRI-replacement) should form a unity, so the hardware state (like video modes etc.) can be managed by the fbdev driver alone, without anything bypassing it and messing around with the hardware on its own.
Applications then could either use functionality provided by both modules or only basic fbdev functionality. Server administrators, for example, could just build the basic fbdev driver into their kernels and prevent the DRI-replacement module from loading on their machines, because they don't need anything accelerated. It has turned out that basic fbdev support is relatively easy to implement, but when it comes to acceleration features, drivers stay in an EXPERIMENTAL or unstable state for many development cycles. This is true for X drivers, too. By seperating the two aspects, development will be easier, and by seperating the X layer from the hardware driver layer, X Server developers won't have to worry about hardware specific things anymore.
mklemm is offline   Reply With Quote
Old 02-23-05, 04:06 AM   #11
mklemm
Registered User
 
Join Date: Apr 2003
Posts: 27
Default Re: NVIDIA generic high-performance kernel interface wanted!

Quote:
Originally Posted by clash rocker
I would love it if NVIDIA took an interest in KGI. I think a unified high performance graphics architecture is an awesome idea, and KGI is the way...if more people get involved. KGI supports Linux and FreeBSD already with interchangable drivers.
I agree that KGI is a conceptually superior approach, but I think fbdev has won the race for inclusion in the standard kernel because it already was there for non-x86 platforms, where it was needed to display just a text console.
The kernel developers are always concerned about simplicity and stability of the standard kernel, and fbdev is just simpler than KGI.
Now, I think we have to get along with this decision, and so the proposal is based on the current fbdev concept.
Sorry for declaring the KGI/GGI project as dead . I see that at least GGI is still active today, but it seems that GGI has changed its targets from being a common low-level graphics library to a platform-independent, higher-level solution that itself makes use of other low-level driver systems, as well as running on top an an X server, while IMHO it just should be the other way round! Also, I miss direct support for technologies like OpenGL in the KGI/GGI approach, although concepts like the KGI "display list" interface are somewhat similar.

Last edited by mklemm; 02-23-05 at 05:10 AM.
mklemm is offline   Reply With Quote
Old 02-23-05, 04:11 AM   #12
mklemm
Registered User
 
Join Date: Apr 2003
Posts: 27
Default Re: NVIDIA generic high-performance kernel interface wanted!

Quote:
Originally Posted by PrakashKC
Well, put the lacking functions into the X11 layer, where is the problem? This is the correcty way of modularization.
Yes, if the generic layer was e.g. based on OpenGL, you could even use OpenGL to implement advanced features of an X server, without knowing anything about the underlying hardware.

Last edited by mklemm; 02-23-05 at 04:33 AM.
mklemm is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
Corrupted display - 302.17 - Dell Precision T3500 (G98 [Quadro NVS 295]) gbailey NVIDIA Linux 1 06-27-12 10:24 AM
UEFI+Nvidia - NVRM: Your system is not currently configured to drive a VGA console... interzoneuk NVIDIA Linux 0 06-26-12 04:51 AM
xorg locks-up with newest nvidia drivers w/ vdpau. theroot NVIDIA Linux 1 06-24-12 11:04 AM
Lucid rt kernel can't load latest nvidia driver module, but generic does. marcod NVIDIA Linux 0 05-02-12 06:23 AM

All times are GMT -5. The time now is 10:36 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.