Xorg 7.0-rc1 and EXA (radeon 9200)

[Stephane Marchesin]

On Wed, Oct 26, 2005 at 04:10:11PM +0200, Michel D?nzer wrote:
> On Wed, 2005-10-26 at 16:00 +0200, Stephane Marchesin wrote:
> > 
> > Well, you see, about half of the issues with X are due to lack o
> > arbitration. Think for example the radeon ddx using half the video ram
> > for pixmaps, or the vt switch issues...
> > 
> > So using arbitration is actually the way to go, and drm is probably the
> > right place to do that when it's available.
> > 
> > Now, for your surface, I suggest you just do tiled pixel acess, the
> > tiling functions are in the radeon_span* files in the radeon dri driver.
> 
> It's not that simple because it's not the driver itself that touches the
> framebuffer, so this approach would mean that fb would have to deal with
> all kinds of tiling, endianness, ... Doesn't seem feasible.
> 

Surfaces are limited resources. You'll run out of them sooner or later,
so you have to have fallbacks anyway.

> > > I think the solution is to add something to the DRM for the server to
> > > "reserve" some surfaces...
> > >
> > This is definitely not future-proof, just like when the ddx allocates
> > half of the video memory for pixmaps even when it doesn't need them.
> 
> I'm afraid you're overreacting a little here. I agree with Ben that a
> way for the X server to reserve a couple of physical surface registers
> (as opposed to virtual surfaces, which can be merged by the DRM) would
> be a good solution for this problem.
> 

Well, look at the memory allocation policy between ddx and dri : it's
ilt upon the same "reservation" kind of thinking, and the dri
performance suffers a lot from that.

But doing the same with surfaces, you'fre just reproducing the same
error...

Stephane