On Sat, 11 Sep 2004, Jon Smirl wrote:
> On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
> <[EMAIL PROTECTED]> 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"
mentality.
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
incompatible.
Linus
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
