R300 idling (new subject)

Vladimir Dergachev volodya at mindspring.com
Sat Dec 18 11:42:26 PST 2004



On Sat, 18 Dec 2004, Michel [ISO-8859-1] Dänzer wrote:

> On Sat, 2004-12-18 at 02:05 -0500, Vladimir Dergachev wrote:
>>
>> On Sat, 18 Dec 2004, Michel [ISO-8859-1] Dnzer wrote:
>>
>>> On Fri, 2004-12-17 at 11:21 -0500, Vladimir Dergachev wrote:
>>>>
>>>> Calling DO_CP_IDLE is a hack no matter where you put it - the right way to
>>>> do things is to do a proper cache flush (plus whatever magic is required)
>>>> each time 3d activity is followed by 2d one.
>>>
>>> So is emitting the cache flush(es) in EnterServer() not enough?
>>
>> No.
>
> Not even instead of the current sledgehammer hack?

The reason for it that simply instructing R300 to flash all caches is not 
enough. One gets a lockup. The command streams that we have that are known 
to work perform some "magic" sequence of writes to registers to get it to 
a sane state.

I wanted to have a driver that would be compatible with developing code so 
that people can test things without the need to recompile X.

More testers and developers -> earlier release of Mesa driver.

>
>> A user-space client is perfectly entitled to  mix 2d and 3d code
>
> Only privileged clients like the X server are able to mix them freely.

What I meant is that that a user space client could issue a 2d operation
after a 3d one. Certainly they would go through separate ioctls to DRM 
driver, but the latter would still need to do the proper sequence.

>
>> and a proper DRM driver must be able to prevent lockups in case user-space
>> client screws up.
>>
>> So either the packet validation code or ioctls will have to deal with
>> 3d->2d transition.
>
> Maybe you're right, and considering the above, it may even be relatively
> simple to do. But then I still don't understand why you put such a hack
> into the X tree, before even asking for other ideas?

Thing is I don't understand why you are so opposed to this ?

Just to reiterate this "hack" *only* affects operation of the driver for
R300 or later cards and only in ACCEL_CP mode - which was not present in 
X a week ago.

It is clearly marked, it does not reduce performance by a large amount,
it makes development of 3d driver easier and is possibly improves 
stability of X as we do not know R300 3d engine well after all.

So from my point of view this was a clear "in" - we get something working 
that did not work before, we speed up 2d acceleration and we make further 
development easier.

Lastly, it is CVS head after all - what is wrong with committing working 
code that facilitates further development ? (For example, I am trying to 
get render acceleration working on R300 cards - this would involve actual
use of 3d engine).

                         best

                           Vladimir Dergachev


>
>
> -- 
> Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
> Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer
>


More information about the xorg mailing list