radeon/r200 color tiling ddx / drm questions

[Michel Dänzer]

On Tue, 2005-01-11 at 14:07 +0100, Roland Scheidegger wrote:
> 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. 

By making the initialization fail, e.g.

> 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.

> 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.


> >> 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? 

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.

> 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?


> >> 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?


> >> 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.

Are the rare cases where doublescan and interlaced modes are actually
useful really worth the hassle of switching between tiling and none
though?


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