Re: radeon-pre-2

[Linus Torvalds]

On Mon, 13 Sep 2004, Vladimir Dergachev wrote:
> 
> The overlay window is currently using part of what is being proposed by
> "multiple drivers" proponents. It has to make engine queiscent so it can 
> write data directly to the video memory. It does *not* have to save the 
> state.

It doesn't even really need to make the engine quiesce.

If two subsystems are aware of the locking rules (and the helper driver
obviously doesn't much care), they can just design their own handoff
trivially. For example, it might make sense to make the "wait for the
engine to stop" be the responsibility of the side that actually _needs_
it, namely the PIO user.

So if both users use the engine, not PIO, there's no need to ever stop the
engine. In my example of how to use the locking, it looked something like
this:

	if (get_lock(data->gfx.accelerator)) {
		/* Somebody else used the engine, need to re-load cached index */
		mydev->offset = readl(mydev->mmio + OFFSET_PORT);
	}
	OUT_RING(mydev, cmd);
	OUT_RING(mydev, arg);
	put_lock(data->gfx.accelerator);

See? You can have two clients doing accelerator things, and they _never_ 
wait for anything (well, obviously "OUT_RING()" needs to wait for the 
buffer to be empty enough ;).

They still need to know whether there was a previous user, because 
efficient command filling does require that you don't read the "where is 
the command buffer end" thing all the time, so that's why you have to 
cache that one in real RAM instead of reading it from the card every op. 
And because you cache it, you have to update your cache if somebody else 
uses the engine.

Now, a PIO writer would look different

	if (get_lock(data->gfx.accelerator)) {
		/* Somebody else used the engine, need to quiesce */
		wait_for_engine_idle(mydev);
	}
	outl(cmd, mydev->pio + OFFSET_CMD);
	...
	put_lock(data->gfx.accelerator);

and here if we switch back and forth between a client that uses 
synchronous commands (ie normally PIO) rather than the engine, then yes, 
we'd obviously halt the engine all the time. But hey, you can't avoid 
that: if you want good performance with most modern chips, you do all your 
work with the engine, not with synchronous commands.

> So, as Jon rightly points out the "multiple drivers" scheme only makes 
> sense in the current usage patter - you either use X or framebuffer, never 
> both at the same time and you consider a few seconds per switch normal.

I disagree. You can use a combination of X, framebuffer and "special 
clients", where the special client can be _exactly_ things like video 
overlays etc. 

Now, obviously we'd wish that X has support for video overlays directly, 
and thus you wouldn't even need to switch between clients at that level, 
but there are certainly cases where you may end up with an "external 
client". It might be some very card-specific thing that X or DRM just 
doesn't support yet, so you whip up a quick client for just that.

For example (and this may be a horribly _bad_ example, for all I know),  
let's say that somebody decides that they want to do a DirectX library, 
and all the DRM people just throw their hands up in horror and say "over 
my dead body".

In that case you have two choices: kill the DRM people and dance on their
graves, or just say "ok, I'll make this other client that does the DirectX
interfaces". And the thing is, it shouldn't fundamentally not work. As far
as I can tell, with some rudimentary locking support like the above (the
trivial part) and some memory management support (the _hard_ part), you
should be able to have the two clients work together quite well.

And yes, I realize that this is what DRM already does internally. I agree. 
I applaud it. I'm saying that if we moved that internal locking to be 
_external_, so that other clients can use it too, then fbcon and DRM and 
some random new subsystem could all live together in peace and harmony.

Now, let's all sit around the fire and sing Kumbaya.

		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/