Re: radeon-pre-2

[Linus Torvalds]

On Sat, 11 Sep 2004, Jon Smirl wrote:

> On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
> <torvalds@xxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/