R300 idling (new subject)

[Vladimir Dergachev]

>> 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.
>
> Right now, those people will need an experimental or at least bleeding
> edge DRM anyway, won't they?

Yes, but the way it is now they won't have to recompile X server. And it 
is not that bleeding edge - R300 support requires only a small and well 
tested patch. With any luck this will make it into kernel before 
X.org is frozen.


>
>>>> 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 ?
>
> Because it hurts my sense of aesthetics, for one. ;) Seriously though,

Aesthetics is hard to argue about..

> considering all of the above and that you yourself say the real solution
> should be in the DRM, I don't understand why you put such an experiment
> in the X code.

Because, it is likely the "real solution" will be long after a working 3d 
driver exists. It makes sense to get something working first, even though 
we don't understand all the details of programming R300 hardware.

>
> But again, what really struck me as bad is that you did it without any
> prior discussion. If you're not sure what the best way to do something
> is, please ask for other opinions first.
>

What do you mean without discussion ? I asked about experimental options
and enabling R300 DRM and initially I wanted to isolate all of that code
and require people to expressly enable it if they care. It was reasonably 
suggested that this was not necessary and the code should work anyway - 
and it does.

[snip]


Michel, let's end this with something constructive.

Here is what I know:
--------------------------------------------------------------
There is a register like this:

// Set to 0A before 3D operations, set to 02 afterwards. */
#define R300_RB3D_DSTCACHE_CTLSTAT          0x4E4C
#       define R300_RB3D_DSTCACHE_02             0x00000002
#       define R300_RB3D_DSTCACHE_0A             0x0000000A

Also, sometimes one needs to follow any 3d packet with
writing 0x1 to 0x46B4 (we have not even named it yet).

And, often, one needs to write 0x0 to 0x2284 that appears to have
something to do with VAP, so Nicolai named it VAP_PVS_WAITIDLE.
--------------------------------------------------------------
Alternatively one can put a simple CP_IDLE call.

Now what would you do ?

My solution was to put code with a CP_IDLE call and long comment 
specifying when it should be removed.

                      thank you

                        Vladimir Dergachev