On Tue, 11 Jan 2005 16:58:12 -0500, Michel Dänzer <[EMAIL PROTECTED]> 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 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel