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