radeon/r200 color tiling ddx / drm questions

[Roland Scheidegger]

Michel Dänzer wrote:
> On Fri, 2005-01-07 at 04:10 +0100, Roland Scheidegger wrote:
> 
>> The dri and drm seem fairly straightforward, though I'm not sure 
>> the way I handled communication between especially drm and ddx is 
>> how it's meant to be. dri got a bit unlucky, as ddx can't know at 
>> startup if it will be able to handle color tiling, so old dri 
>> together with new drm and new ddx will not work (correctly) (if you
>>  have enabled color tiling).
> 
> 
> You might be able to solve this with a two-way handshake between the
>  3D driver and the DDX, similar to how it's done with the DRM
> already. With that, the DDX could recognize clients that can deal
> with tiling and prevent others from using direct rendering.
How would you do that? I can't see a way at all how ddx would reject a
dri client. If I see that correctly, drm does neither reject clients
based on features/version. If there is some two-way handshake somewhere,
I must have missed it. 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.

>> 1) the biggest problem is XAA's handling of graphic memory. It 
>> treats everything as a single big chunk of linear framebuffer.
> 
> Actually, it treats it as a rectangle of the same width as the 
> virtual width of the screen. The tiling should really be uniform over
>  that whole rectangle. A problem with that is that the hardware 
> cursor does and the back and depth buffers and textures may overlap 
> with it.
Is there a good reason why tiling needs to be uniform over the whole
rectangle? Because XAA expects it to be like that? (I basically think
this is a design deficiency of XAA that it treats everything as a single
big framebuffer.)
hw cursor can likely be solved easily (by reserving some space around
it), and back/depth buffers should be fixable the same I think (and add
overlays to the mix too). However, it makes it even harder to switch
between tiling-enabled and disabled resolutions. And also, for some
reason "XaaNoOffscreenPixmaps" was needed to make it work that way.

>> 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. Maybe I could try
harder, but I'm now pretty confident tiling won't work with virtual x
resolutions larger than 2048 anyway, so it doesn't matter.

>> 3) When switching from/to a resolution without tiling support,
> 
> 
> If tiling doesn't work with all resolutions, shouldn't those 
> resolutions be discarded in the first place if tiling is enabled?
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.
There's also some problem with that (mode validation happens before
options parsing, not sure how easy that would be to fix).

> 
>> everything on screen will be really wrong and needs to be redrawn.
>>  I guess it's somehow possible to mark everything as dirty or 
>> something like that? Just externally calling "xrender" doesn't 
>> sound like a good solution...
> 
> 
> Maybe you could walk the window tree and generate expose events or 
> something like that, but that would be rather ugly.
That's what I feared, no easy way to tell the X server to redraw stuff :-(.

> 
>> 5) I'm not sure how exactly fbdev (the UseFBDev option) works, but
>>  I'm pretty confident it won't work at all with color tiling, and 
>> I've no idea how you'd fix that, [...]
> 
> 
> It's true that radeonfb doesn't enable tiling when it sets a mode, 
> and there's no way that I know of to tell it to do it even if it 
> could. The only (hackish) way I can see would be to make sure the 
> relevant registers are correct after calling into fbdevHW for setting
>  the mode, but for now I'd just disable tiling if fbdev is enabled.
Sounds like a good idea. It's the same what mergedfb does, after all.

Roland

btw I was unable to fix the XAA corruption issues so far :-(.