radeon/r200 color tiling ddx / drm questions

[Roland Scheidegger]

Alex Deucher wrote:
>>> How would you do that? I can't see a way at all how ddx would 
>>> reject a dri client.
>> 
>> By making the initialization fail, e.g.
Do you have some pointers how you'd do that? All code I see for
initialization is on the dri side, except the generic stuff in dri.c.
When it comes to initialization, there seems to be some black magic
involved :-).

>> 
>>> If I see that correctly, drm does neither reject clients based on
>>>  features/version.
>> 
>> Maybe it doesn't yet, but it could.
>> 
>> Actually, it might be possible to use the DRM two-way handshake for
>>  this purpose? I'm not sure there's a driver specific handshake yet
>>  though, but adding that would probably be worthwhile anyway.
>> 
>> 
>>> If there is some two-way handshake somewhere, I must have missed 
>>> it.
>> 
>> There's none yet in the DDX, it would have to be added (if the one 
>> in the DRM doesn't suffice). It would probably be useful for other 
>> stuff like dynamic buffer offset updates (for Composite, pbuffers, 
>> ...) as well.
Actually, I can't see a two-way handshake in drm neither, any pointers?

>> 
>>> DRI itself will refuse to load if the ddx major version doesn't 
>>> match however, which is what Ian suggested to do (bump the ddx 
>>> major version). Maybe that was indeed a good idea, even though it
>>>  means you'd have to update ddx if you got a new tiling-enabled 
>>> dri (which isn't necessary otherwise). It would probably simplify
>>>  some things slightly.
>> 
>> For us maybe, but certainly not for users. Bumping the major 
>> version should be avoided whenever possible IMHO.
That's what I thought first too, I'm interested in other approaches...

>>> Is there a good reason why tiling needs to be uniform over the 
>>> whole rectangle? Because XAA expects it to be like that?
>> 
>> Yes.
>> 
>> 
>>> (I basically think this is a design deficiency of XAA that it 
>>> treats everything as a single big framebuffer.)
>> 
>> It arguably is, but that's the way it is.
Ok. For some reason, I can't get the version with pixmap cache untiled
to work anyway correctly (clipping issues? can't change offset at any
time?), so I guess I'll go back and try everything tiled again...

>> 
>>> And also, for some reason "XaaNoOffscreenPixmaps" was needed to 
>>> make it work that way.
>> 
>> Was the whole rectangle covered by a surface compensating for the 
>> tiling as well?
Yes.

>> 
>> 
>>>>> 2) I was unable to make render work with the changed x 
>>>>> coordinates trick, needed to support coordinates beyond 2048.
>>>>>  I think it should be possible that this works?
>>>> 
>>>> 
>>>> Maybe the calculation of the colour offset has to take the 
>>>> tiling into account?
>>> 
>>> That's eactly what I tried, but it didn't work.
>> 
>> So you aligned RB3D_COLOROFFSET to a tile, i.e. 2KB?
Yes. It's possible I got that wrong though, I only quickly tried that, 
didn't work, thought there are more important issues to solve... But as
said, it's a moot point.

>>> It just seemed to be a little harsh to throw them out altogether 
>>> - some people might like to use small (doublescan) physical 
>>> resolutions for some OGL apps for speed reasons for instance, 
>>> which would mean they'd need to restart the X server with tiling 
>>> disabled just for that.
>> 
>> Are the rare cases where doublescan and interlaced modes are 
>> actually useful really worth the hassle of switching between tiling
>>  and none though?
>> 
> 
> 
> I'd vote for just throwing out doublescan and interlaced modes if 
> tiling is enabled.  Maybe put a note in the x log saying "turn off 
> tiling for doublescan/interlaced modes"
Ok, you've convinced me. I'd really wanted to make color tiling enabled 
by default in the end though, and this might just break some (existing) 
installations.

Roland