Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 44

Thread: The Issues With The Linux Kernel DRM, Continued

  1. #11
    Join Date
    Sep 2010
    Posts
    467

    Default

    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.

  2. #12
    Join Date
    Mar 2009
    Posts
    141

    Default

    Quote Originally Posted by 89c51 View Post
    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.

  3. #13
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote Originally Posted by plonoma View Post
    Look at windows api's.
    Not if you value your sanity.
    I looked at the Windows API once. Never again.

  4. #14
    Join Date
    Sep 2010
    Posts
    467

    Default

    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.

  5. #15
    Join Date
    Sep 2010
    Posts
    467

    Default

    Quote Originally Posted by pvtcupcakes View Post
    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.

  6. #16
    Join Date
    May 2007
    Posts
    231

    Default

    Quote Originally Posted by plonoma View Post
    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, ...).

  7. #17
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote Originally Posted by hubick View Post
    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?

  8. #18
    Join Date
    Sep 2006
    Posts
    714

    Default

    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.

  9. #19
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by drag View Post
    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.

  10. #20
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    Quote Originally Posted by drag View Post
    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.

    Quote Originally Posted by drag View Post
    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.

    Quote Originally Posted by drag View Post
    Also note that he did accept the patches.
    Quote Originally Posted by drag View Post
    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 ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •