Maybe it's time for a decent version tracking of drm api.
But now on a more fundamental issue:
seriously, haven't thought about multiple screens (more than 2)
problems with multiple cards
problems with multiple OpenGL contexts.
Looks like nobody tries to think first a little.
Just codes stuff he/she thinks is useful for him/her at that particular moment.
Seriously guys, do some decent planning and brainstorming on a wiki first.
Look at windows api's. Ask game developers to comment on your patches.
Ask random programmers to comment on your patches.
Look at ALSA, there are certain parallells between graphics and audio cards.
e.g. memory management
audio cards also can have dedicated memory.
Up to the most constructive attitude in the whole post:
Now this kind of view is the most constructive but still not good enough for me.
I strongly disagree with the view presented here:
There IS a common denominator, it's graphics card.
Its a category that already defines a certain feature set roughly.
And with that implicitly formulated infrastructure requirements in the kernel.
Please improve the way State Trackers are handled. There should be a kernel state tracker api.
Drivers should present their api's as state trackers to the kernel.
Not the other way around.
The differences are how the functions it does are implemented. You know how most stuff handles that? By making drivers, and putting all of the differences in the drivers.
Looks like the DRM guys tried to put too much stuff in the kernel to unify things without making those things generic enough to be useful.
Example, sound cards also have dedicated memory.
Why not think of a general way of doing memory management for and by subsystems.
A full gl stack in kernel would be kernel+drivers+userspace-api's.
What we need most in kernel is graphic cards api to let graphic cards drivers hook in.
Something like ALSA for graphics cards.
Then we need something to present api's to userspace in a unified way.
If this is done in a good way, there shouldn't be api's hardcoded in it.
All of the available stuff should be available by drivers and/or libraries.
That's it! Software OpenGL rendering with a library would be part of this.
A device is for implementing functions.
Having software libraries as fallback for that is not a bad thing of course.
Thankfully Keith Packard didn't got his way of merging the drivers with the kernel or this situation would be the same thing many times over again and worse.
If you think memory management for dedicated memory for all kinds of stuff is bloated or far fetched.
Then you just aren't capable of writing a decent GENERAL api-kernel stuff.
Then adjust your attitude, because making stuff limited as you do will cause you to make the same KIND of mistake over and over again.
But now on a more fundamental issue:
seriously, haven't thought about multiple screens (more than 2)
problems with multiple cards
problems with multiple OpenGL contexts.
Looks like nobody tries to think first a little.
Just codes stuff he/she thinks is useful for him/her at that particular moment.
Seriously guys, do some decent planning and brainstorming on a wiki first.
Look at windows api's. Ask game developers to comment on your patches.
Ask random programmers to comment on your patches.
Look at ALSA, there are certain parallells between graphics and audio cards.
e.g. memory management
audio cards also can have dedicated memory.
Up to the most constructive attitude in the whole post:
DRM have been trying to play catchup for years, GPU are likely the most complex piece of hardware you can find in a computer (from memory management, to complex modesetting with all kind of tweaks to the utterly crazy 3d engine and everythings that comes with it) Unlike others piece of hardware, when it comes to fully use a GPU acceleration, there is no common denominator that we would be able to put in the kernel (like a tcp stack or filesystem). I am sure very few people would like to see a full GL stack into the kernel.
...
Jerome
...
Jerome
I strongly disagree with the view presented here:
There IS a common denominator, it's graphics card.
Its a category that already defines a certain feature set roughly.
And with that implicitly formulated infrastructure requirements in the kernel.
Please improve the way State Trackers are handled. There should be a kernel state tracker api.
Drivers should present their api's as state trackers to the kernel.
Not the other way around.
The differences are how the functions it does are implemented. You know how most stuff handles that? By making drivers, and putting all of the differences in the drivers.
Looks like the DRM guys tried to put too much stuff in the kernel to unify things without making those things generic enough to be useful.
Example, sound cards also have dedicated memory.
Why not think of a general way of doing memory management for and by subsystems.
A full gl stack in kernel would be kernel+drivers+userspace-api's.
What we need most in kernel is graphic cards api to let graphic cards drivers hook in.
Something like ALSA for graphics cards.
Then we need something to present api's to userspace in a unified way.
If this is done in a good way, there shouldn't be api's hardcoded in it.
All of the available stuff should be available by drivers and/or libraries.
That's it! Software OpenGL rendering with a library would be part of this.
A device is for implementing functions.
Having software libraries as fallback for that is not a bad thing of course.
Thankfully Keith Packard didn't got his way of merging the drivers with the kernel or this situation would be the same thing many times over again and worse.
If you think memory management for dedicated memory for all kinds of stuff is bloated or far fetched.
Then you just aren't capable of writing a decent GENERAL api-kernel stuff.
Then adjust your attitude, because making stuff limited as you do will cause you to make the same KIND of mistake over and over again.
Comment