Archived

This topic is now archived and is closed to further replies.

CoffeeMug

Linux graphics handling is idiotic

Recommended Posts

CoffeeMug    852
Can someone give me one good reason why hardware dependent OpenGL drivers also depend on the X server? What is the reason DRI chose to be XFree86 specific? An obvious solution would be making a hardware dependent driver part of the kernel and simply write a Mesa binding that would run on the framebuffer. The next reasonable step would be making the X server compatible with that system. Who on earth got the idea of making DRI specific to XFree? [edited by - CoffeeMug on September 1, 2003 12:09:55 AM]

Share this post


Link to post
Share on other sites
CoffeeMug    852
quote:
Original post by owl
Why are hardware dependent OpenGL windows drivers also dependant on MSWindows?

Same reason hardware dependent OpenGL linux drivers are dependent on linux. But why would they be dependent on a third party software package (XFree)?

Share this post


Link to post
Share on other sites
owl    376
quote:
Original post by CoffeeMug
Same reason hardware dependent OpenGL linux drivers are dependent on linux. But why would they be dependent on a third party software package (XFree)?


Maybe they are drivers for the XFree windows system which happens to be a package in the linux distributions..

Share this post


Link to post
Share on other sites
Flarelocke    410
quote:
Can someone give me one good reason why hardware dependent OpenGL drivers also depend on the X server?
Yes. OpenGL is simply a graphics API standard and can be implemented over the X protocol, as well as simply the graphics card. This basically means OpenGL programs are also network transparent. This is a boon for universities like mine where a tinderbox is supplied and CS students need to verify their programs compile and run on the tinderbox (so that the teacher can verify that they work correctly in a way that the student can predict the results of the teacher''s verification).

quote:
What is the reason DRI chose to be XFree86 specific?
AFAIK, it''s not. DRI drivers in the linux kernel provide features that XFree86 uses. It''s currently XFree86 specific, but that''s in large part because no stable kernel currently has the drivers provided by XFree86 in it.

quote:
An obvious solution would be making a hardware dependent driver part of the kernel and simply write a Mesa binding that would run on the framebuffer.
It''s just a matter of doing it; there''s nothing really stopping anyone from using the provided drivers (and C&P''ing part of the X drivers, if necessary) into a framebuffer library.

Share this post


Link to post
Share on other sites
CoffeeMug    852
quote:
Original post by Flarelocke
Yes. OpenGL is simply a graphics API standard and can be implemented over the X protocol, as well as simply the graphics card.

Well, ok. I won''t argue about superiority of RPC and the stupidity of adopting "computer is a network" approach for stuff like graphics because it''s a whole different discussion. What I meant to say was "Can someone give me one good reason why hardware dependent OpenGL drivers also depend on the XFree86 server?" Which brings us to the next point...
quote:
Original post by Flarelocke
AFAIK, it''s not [...] It''s just a matter of doing it; there''s nothing really stopping anyone from using the provided drivers (and C&P''ing part of the X drivers, if necessary) into a framebuffer library.

I just love those projects that have "platform independent design." Of course there''s implementation for only one platform but "there''s potential to port to anything". DRI claims it''s not specific to XFree86, but right now there is only one XFree specific implementation. I understand they''re reluctant to spend time on doing something they don''t consider useful (DRI on the framebuffer) but at least they could provide sufficient documentation for doing so. For instance, I was interested in getting OpenGL to run on the framebuffer. Try visiting DRI''s website and get some information on how to do that. I''ll give you a hint: there is none. And I''m fairly confident that contacting the developers will get me a typical linuxoid response. "Use the source, Luke." This is the main reason we''re locked into XFree monopoly and DirectFBGL is moving so slow. Oh well, I guess we won''t see X free (pun intended) accellerated desktop in a long time.

Share this post


Link to post
Share on other sites
Prefect    373
quote:

Can someone give me one good reason why hardware dependent OpenGL drivers also depend on the X server? What is the reason DRI chose to be XFree86 specific?



Probably because at the time the DRI was started, X Free had the best initial hardware support and the 2D drivers were (mostly) already written.
The GL-code itself probably isn''t very XFree86 specific, but the GLX setup code obviously is. If DirectFB is so important to you, you might look into ways you can combine DirectFB GLContext initialization and XFree86 GLContext initialization into a single libGL.so. I don''t think anybody in the DRI project will try to make this any harder for you, it''s just that except for embedded developers, almost nobody has a reason to help you, either.


quote:

Oh well, I guess we won''t see X free (pun intended) accellerated desktop in a long time.


This leaves the obvious question: Why would you want a Linux desktop without X?
Whenever there''s a discussion about "the Linux desktop", people are always bitching about lack of standards and so on. And sure enough, the very same people then demand that XFree be replaced by something else.

Hello? Newsflash: XFree is _the_ standard as far as the Linux desktop is concerned. Abandoning XFree would throw development back by at least 10 years. It would immediatly _kill_ the Linux desktop.

Obviously, this doesn''t mean that the current state of affairs is perfect. But if you think something has to improve, there are better ways to go about it. If, for example, you have issues with the X itself, you should check out XOuvert.
If there are issues with desktop functionality (which is more likely; most people who are complaining about X are simply complaining because they have no clue), you could go to Freedesktop and convince yourself that things are looking up.

cu,
Prefect

Share this post


Link to post
Share on other sites
Flarelocke    410
quote:
This is the main reason we''re locked into XFree monopoly and DirectFBGL is moving so slow.
XFree monopoly? Yeah, how dare they release a project for free with such technical perfection that it''s only significant competition is a fork of itself, and two or three radically different substitutes. DirectFBGL is moving slow because a) it''s based on something few people use, and b) it''s something that''s not essential even to those people who already use DirectFB.

quote:
And I''m fairly confident that contacting the developers will get me a typical linuxoid response. "Use the source, Luke."
Considering you''ll end up reading the source anyway, for such a project, and that the project isn''t absolutely massive, like Mozilla, this isn''t too unreasonable anyway. Perhaps if you did this, you could then provide the documentation you feel is missing. Unless, of course, you just wanted to work on your little project, in which case (what a coincidence!), you''ve done the same thing the developers did.

quote:
Abandoning XFree would throw development back by at least 10 years. It would immediatly _kill_ the Linux desktop.
Nope, there''s already a usable version of gnome for DirectFB. It might be necessary to fix some applications that don''t use gdk, but it''s hardly 10 years of work.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Hardware OpenGL drivers is not really dependent on X. The drivers is dependent on that the kernel allows them to have low level access to certain stuff.This discussion is mostly about OpenGL and Windows but look at the post from evanGLizr.
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/010226.html

OpenGL on linux is done after the original from SGI and with help from SGI. GLX is an extension to X with the purpose of having very fast 3D graphics with X.

The reason why you dont have OpenGL in console mode also is prpbably lack of interest.

Share this post


Link to post
Share on other sites
Hitchhiker90    130
Just a question about Xfree. If people are saying its slow and bloated because of extra things like network transparency and the such, why hasn''t anyone made a less bloated version? Something along the lines of a single user version, take out the network stuff and other things that a home user wouldn''t need. Is this even possible or is it just a matter of not enough man power or lack of interest to do it?

Share this post


Link to post
Share on other sites
Strife    374
Would that even really be truly possible? Well, I''m sure it would be, but the extra work involved in getting it to work transparently with current X apps would probably sacrifice any extra speed you''d gain.

The Artist Formerly Known as CmndrM

http://chaos.webhop.org

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
How about this reason: OpenGL graphics will sometimes be displayed inside a window in X.

Share this post


Link to post
Share on other sites
Prefect    373
There is a very simple reason why eliminating network transparency in X just doesn''t make sense.

Any multi-application graphics system must have a controlling entity that assigns resources to applications, determines which input events go where, etc.

There are only two possible ways one can implement this controlling entity:
- as a kernel module; this is usually frowned upon because of system stability issues, among others
- as a user space process; this is the case with X windows

In the latter case, the graphics system must have a form of IPC.
XFree can use both TCP/IP and Unix domain sockets (+ shared memory) for IPC. When you''re running it locally, it uses the latter, which is the fastest form of IPC available - at least on Linux, I''m sure there are some micro kernels that can do faster IPC.
Since having TCP/IP support as well doesn''t hurt the local case in any way, there''s simply no reason to drop TCP/IP.

There is one part in the design of X that has timing/lag problems (not necessarily performance problems though), and unfortunately, this part is one of its greatest features. I''m talking about the window manager.
There are many cases where communication in X works like this or similar: Client -> X -> WM -> X -> Client
When more than one client is involved, this leads to a whole lot of problems, which is why the Inter-Client Communications Conventions Manual (ICCCM) exists.

It would be interesting to see an in-server window manager as a loadable module. This would still allow diversity while minimizing or even eliminating a lot of the ICCCM headaches. This is quite a major change, but if you feel like revolutionizing anything in this area, it''s probably the most productive thing you could try.

cu,
Prefect

Share this post


Link to post
Share on other sites
C-Junkie    1099
Problems with X that people notice.

1) Lag because of the bouncing of the protocol and serial nature of most events. You can''t really get around "X -> client -> X" for things like clicking a button having that cause a new window to pop up. but as the previous poster noted, the WM type stuff IS unecessary, and needs to be redesigned, unfortunately, that mean X12, which nobody really wants to do.

2) Drivers. This is the huge, vast, cover-all-complaints problem with XFree86. "Nobody" notices the above problem since on local machines its blindingly fast. (and "nobody" uses the network stuff, right?) What they do notice is that quake 4 runs with 1 fps. The problem is that card manufacturers don''t like to write open source drivers for their cards.

3) Conventions. Ever wonder why your whole window needs to be redisplayed every time it moves? Yes, its possible to make the server take whats rendered now and just move it when the window moves, but the event for a window expose is still sent to the application. (and come to think of it, I''m not sure if you can distiguish between "it jsut got moved" and "it really does need to be redrawn")

4) I had something but I forgot it just now.

--

Anyway, has the OP''s question (and the intended topic of this thread) been answered yet?

Share this post


Link to post
Share on other sites
Doc    586
quote:
Original post by CoffeeMug
And I''m fairly confident that contacting the developers will get me a typical linuxoid response. "Use the source, Luke."


Would you prefer to not have the source, and reverse engineer it yourself with no help?

At least the source is there and the developers are available to answer (reasonable) questions. What do you want, it handed to you on a plate?

Image loads when I''m online!The following statement is true. The previous statement is false.
Shameless promotion:
FreePop: The GPL Populous II clone.

Share this post


Link to post
Share on other sites
CoffeeMug    852
quote:
Original post by Doc
What do you want, it handed to you on a plate?

Because I intend to introduce improvements to their project without asking for anything in return?

Share this post


Link to post
Share on other sites
Fruny    1658
quote:
Original post by C-Junkie
"Nobody" notices the above problem since on local machines its blindingly fast. (and "nobody" uses the network stuff, right?)



err... I am, right now, while I am typing this.




[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

Share this post


Link to post
Share on other sites
CoffeeMug    852
quote:
Original post by C-Junkie
"Nobody" notices the above problem since on local machines its blindingly fast. (and "nobody" uses the network stuff, right?)


A technologically superior mechanism is already in place and it's called RPC. Whenever you wish to use a networked model you replace all functions by stubs that do appropriate initialization and marshalling. This way you don't have to pay for networking if you don't want to and you will have it if you do. Modern programming frameworks do this for you automatically. I don't understand why the linux scene is stuck behind the times still using C and a twenty year old networking model.

Note, I am not flaming the linux people. I use linux myself and want to see it improved.

[edited by - CoffeeMug on September 4, 2003 11:58:53 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:
Original post by CoffeeMug
A technologically superior mechanism is already in place and it''s called RPC. <snip>



Linux has RPC.

quote:

I don''t understand why the linux scene is stuck behind the times still using C and a twenty year old networking model.



Using C? You are free to use what bloody language you want! If your complaint is that parts of the operating system and its components are written in C, then guess what - that is the case in most other operating systems as well, including windows.

As for ''networking model'', X wasn''t actually designed to be used over a network, but it turned out that the X protocol was so well designed that it would work. So they added that.

quote:

Note, I am not flaming the linux people. I use linux myself and want to see it improved.



Well you''re right about not flaming, this is more like trolling.

Share this post


Link to post
Share on other sites
Doc    586
quote:
Original post by CoffeeMug
quote:
Original post by Doc
What do you want, it handed to you on a plate?

Because I intend to introduce improvements to their project without asking for anything in return?

Don''t forget that much of their work is also volunteered.

Image loads when I''m online!The following statement is true. The previous statement is false.
Shameless promotion:
FreePop: The GPL Populous II clone.

Share this post


Link to post
Share on other sites
noVum    170
quote:
2) Drivers. This is the huge, vast, cover-all-complaints problem with XFree86. "Nobody" notices the above problem since on local machines its blindingly fast. (and "nobody" uses the network stuff, right?) What they do notice is that quake 4 runs with 1 fps. The problem is that card manufacturers don''t like to write open source drivers for their cards.


nVidia has good Linux drivers since years and ATi just finished a reasonable one. They are not open source, but I don''t see a problem with that.

Share this post


Link to post
Share on other sites