Re: radeon-pre-2

[Hamie]

Alan Cox wrote:

> On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
>  
>
> > User 1's game queues up 20ms of 3D drawing commands.
> > Process swap to user 2.  ->quiesce() is going to take 20ms. 
> > User 2's timeslice expires and we go back to user 1.
> > User 1 queues up another 20ms.
> >
> > User 2's editor is never going to function.
> >    
>
> If you implement it wrongly sure. If you implemented it right then
> this occurs.
>
> User 1 queues 20 ms of 3D commands
> User 1 is pre-empted
> User 2 wants the 2D engine
> User 2 beings wait for 2D
> User 2 sleeps
> User 1 wakes
> User 1 beings wait for 3D but discovers a claim is in progress
> User 1 sleeps
> User 2 wakes, runs commands
>
> If you have DRI loaded then as you rightly say the obvious desired
> outcome is that the fb engine either turns acceleration off or switches
> to using the DRI layer. 
>
> But this is a pretty obscure case, and one we can't even begin to
> support yet anyway.
>
>  

What about if you want to use fb when in text mode (Because you get 
200x75 on a 1600x1200 screen) AND run DRI because the rest of the time 
you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7 
back & forth between X & fb... (i.e. how I currently use it but with 
unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).

Currently this fails to work... Presumably because the fb & DRI code 
(fglrx here BTW) don't talk to each other & so the display gets garbled 
if you're lucky... Lockup if you're not.

Although I didn't like (Understand?) Jon's suggestion at first, I have 
to admit, that his scheme would let this work... because the low level 
driver would know what mode was in place, and you'd call the low-level 
driver to change between 3D & fb mode... 

Although Linus' suggestion works for memory allocation... I don't 
believe it addresses two competing drivers wanting to play with the same 
screen... Even when it's serialised like that. And unfortunately 
although Alan's probably works for DRI & fb on separate heads, how does 
it guarantee that the chipset is all setup the same way for each process 
on different heads... (When they have to share some of the hardware). Or 
is that necessary?

-
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/