The Issues With The Linux Kernel DRM, Continued

[plonoma]

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:

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

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.

[Smorg]

i hope that this discussion will lead the devs to a solution for the development model. The manpower issue will probably remain.

I hope this discussion doesn't lead to a "solution" that involves making technical compromises for the sake of an artificial mandate to accommodate an unrealistic development model. Sure Linus -- pound the round peg hard enough and it'll fit the square hole one way or another.

[pvtcupcakes]

Look at windows api's.

Not if you value your sanity.
I looked at the Windows API once. Never again.

[plonoma]

Multiple cards that can be hotswitched without the software restarting is a basic requirement for an kernel that wants to be able to be generally usable everywhere.


As a programmer I want to be able to use all the computing power together.
Want to be able to use multiple graphics cards to calculate different parts with OpenCL.
Of course the Operating System must make it possible that multiple processes can use the graphics card. Having some process manager for the user needs to be done too of course.
And it must be possible for programmers to set optimal GPU affinity for multiple GPU's.

[plonoma]

Not if you value your sanity.
I looked at the Windows API once. Never again.

I know.

I'm talking about looking at different views.

Because it's something else, the problems with it are better noticeable.
I meant using them as a reference, starting point for improvement brainstorming of some sort.

[glisse]

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.

You are missing my point, common denominator for audio device is easy things like ALSA, it's not too hard to design and audio API for sound card because all the soundcard have a common feature set and works the same way.

Same goes with filesystem, kernel expose high level operation (create node, delete node, node list ...) Or network with things like TCP stack.

But when it cames to GPU the common denominator is somethings like OpenGL or VAAPI if you consider video. Those are very _high level_ API (take a look at mesa source size). There is absolutely no middle ground in GPU, each GPU have different way to execute command, different command, different memory layout, different restrictions, different ways to tile things, different way to manage memory ...

So solutions are either GPU specific API and no way to foresee how good each API will be before having full userspace stack and starting to optimize performances. Or find some middle ground in the GL API (things like GLES API which represent the most used and most reasonable GL features) and move such things to kernel, again no garanty that this API would be any good until you build a full userspace stack.

But middle ground in GL API means moving a lot of code to the kernel and there again it's might not be trivial. For instance state book keeping needs a lot of structure and memory, but at the same time you want that memory you allocate on a behalf of a process to be accounted against this process and you also don't want the process to be able to mess with it while still allowing the kernel to work it (i don't think this is trivial in linux kernel but i have gap in my linux kernel memory code knowledge).

And when it comes to memory management, in GPU side things are way more dynamic the for audio device or network device, and also with way more subtilities (memory tiling, unmappable memory, GART, ...).

[bug77]

So what if you merge fresh code into mainline, I don't think it's intended to be stable in the same sense as something RedHat would push to RHEL customers anyhow.

Seriously, the linux kernel is not intended to be stable? What is this, some Ubuntu PPA?

[drag]

Yes.

It's idiotic that untested code is being pushed into a kernel that is suppose to be only accepting tested code.

If you want to run untested code and be a guinea pig for DRM developers then that is why we have GIT and Drm-next.

Also note that Linus here is also wants to see stable APIs for the kernel userspace interfaces. Compared to what other developers are allowed to do the DRM folks are getting away with murder. Nobody else would be allowed to do what they are already getting away with.

Also note that he did accept the patches.

This is just Linus's way to keep them under control and keep them from trying to sneak in more stuff then they are already doing.

[airlied]

Yes.

It's idiotic that untested code is being pushed into a kernel that is suppose to be only accepting tested code.

If you want to run untested code and be a guinea pig for DRM developers then that is why we have GIT and Drm-next.

Also note that Linus here is also wants to see stable APIs for the kernel userspace interfaces. Compared to what other developers are allowed to do the DRM folks are getting away with murder. Nobody else would be allowed to do what they are already getting away with.

Also note that he did accept the patches.

This is just Linus's way to keep them under control and keep them from trying to sneak in more stuff then they are already doing.

fuck your an idiot, none of what you said is any way correct, what did you fucking do read some tea leaves to dig up this bullshit?

Dave.

[bridgman]

It's idiotic that untested code is being pushed into a kernel that is suppose to be only accepting tested code. If you want to run untested code and be a guinea pig for DRM developers then that is why we have GIT and Drm-next.

You might be talking about a different issue. AFAICS the issue here was that the patches had been reviewed and tested, then just as the push was happening Michel raised an issue related to future-proofing.

Also note that Linus here is also wants to see stable APIs for the kernel userspace interfaces. Compared to what other developers are allowed to do the DRM folks are getting away with murder. Nobody else would be allowed to do what they are already getting away with.

My impression was that the DRM developers were following the same rules as everyone else, even though those rules result in a bigger drag on GPU development than on other devices because the hardware evolves so quickly.

Also note that he did accept the patches.

This is just Linus's way to keep them under control and keep them from trying to sneak in more stuff then they are already doing.

What stuff do you think they are already doing ?