radeon/r200 color tiling ddx / drm questions

[Alex Deucher]

On Tue, 11 Jan 2005 16:58:12 -0500, Michel Dänzer <michel at daenzer.net> wrote:
> 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?
> 

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"

Alex

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