[lkml]   [2004]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: radeon-pre-2

    On Sat, 11 Sep 2004, Jon Smirl wrote:

    > On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
    > <> wrote:
    > > Jon, you want to get to that "Final step is to integrate the chip specific
    > > code from DRM and fbdev". Alan doesn't even want to get there. I think
    > > Alan just wants some simple infrastructure to let everybody play together.
    > This is the core problem. I want to get to a point where there is a
    > single, integrated piece of code controlling the complex functions of
    > the 3D hardware.

    I think you can get there without having to merge the two.

    How about just accepting the fact that there might be other people
    accessing your hardware, and then trying to make it _rare_?

    > I want to get away from the model of "I just got control of the chip,
    > who knows what the state of it is, I better reset everything". I also
    > want to get away from "now I want to use this register, i need to
    > inspect every over driver and piece of user space code to make sure
    > they don't stomp it". Or "I didn't even know your code existed, sorry
    > about stomping that critical register and causing 100 bug reports". Or
    > "why don't we just split the VRAM in half so we don't have to share
    > memory management". Or suspend code that restores 2D mode and ignores
    > 3D.

    Well, what _I_ want to get away from is a "I'm the only game in town"

    I want people to be able to play with other things, without having one
    driver that has to know about it all. I also want to avoid flag-days, ie
    I'd like to be able to have a gradual transition.

    And I don't think your model really has the option for a gradual
    transition, and other people doing their thing.

    So I'd much rather see the "hey, somebody else might have stolen my
    hardware, and now I need to re-initialize" as the _basic_ model. That just
    allows others to do their own thing, and play well together. More
    importantly, it allows the existing status quo, which means that if we
    take that as the basic approach, we _never_ have to make a complete flag
    day when we switch over to "_this_ driver does everything". See?

    HOWEVER, I do realize that that is horribly inefficient as a common thing
    to happen, which is why I have the cunning plan (always steal good ideas
    from others and call them "your" cunning plans) to have the locking that
    allows for caching over locks. That means that _if_ you get to the point
    where your driver does everything, you'll never really have to worry about
    performance, because you'll never see the bad cases.

    Or maybe you'll only see the bad cases when the kernel oopses, and decides
    that it _has_ to write to the screen and screw your model. See what I'm
    saying? Having a model that allows for that is a _good_ thing.

    And you can do it. Basically, if you build on top of the "silly driver"
    locks, your DRM layer would have _one_ cookie (per hw device, of course)
    that it ever uses, and it would point to your basic device descriptor.
    You'd then do the X cookies within that decide descriptor, ie they'd never
    change the "silly driver" cookie, and thus you'd never see a "conflict".
    You'd take care of the existing DRM locking methods yourself, you wouldn't
    try to shoe-horn them into the silly driver locks.

    So what I'm saying is that you _can_ get to your ideal world, without
    taking the option away from others to decide that they prefer having two
    (or three, or fifteen) drivers all accessing the same hardware. For
    example, the single-driver approach might be good for some hadrware. It
    might not be so good for others (think vendor drivers etc).

    > A good example of this is switching the GPU between 2D and 3D mode on
    > every process swap.
    > In general the current X design only has a single 3D client. With a
    > composited display and pbuffer background drawing we are going to have
    > one 3D client for every top level window.

    But if you make your DRM thing be the "master" of these different 3D
    client contexts, then you _can_ handle that without ever having to lose
    your "hardware lock". See what I'm saying? You do two-level locking:

    - the "hardware level" is the silly driver one. It's the one that allows
    multiple kinds of subsystems to play together, be it DRM of fbcon. When
    you get a "release event" for this one, you basically have to serialize
    _everything_, because this level of release means that you literally
    don't know what happened (with the exception of mode switching, I
    really think that one has to be a totally separate class of events).

    - you have your _own_ "DRM level" context lock, which is the one the 3D
    clients from X actually interface to. That one also has to reset _some_
    client state, of course, when you switch between clients, but now it's
    only state that _you_ know about.

    You can have your cake and eat it too. I don't think these things are

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.025 / U:4.000 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site