On Mon, 2005-01-17 at 21:34 +0100, Roland Scheidegger wrote: > Michel DÃnzer wrote: > > On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote: > > > > The location of the framebuffer as seen by the > > GPU needs is defined by MC_FB_LOCATION. All current components have > > fields named along the lines of ...->fbLocation for that. > I've done some tests, and this doesn't seem to be true for the surface > regs. Maybe the addresses there are already relative to MC_FB_LOCATION.
Yeah, that makes sense, as the surfaces only apply to CPU access, and the GPU can only affect that for the framebuffer. > I've uploaded a new version here: > http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx8.diff > http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri8.diff > http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm8.diff > > This one should have mergedfb + mixed interlaced/non-interlaced > resolutions fixed (untested), fixed some errors with pageflip in some > resolutions (backbuffer alignment problem), Speaking of mergedfb and page flipping: Is it really necessary to add a new private SAREA field and a corresponding setparam? Isn't it possible to set the generic SAREA fields as the DRM expects them, to make this work with older DRMs as well? > fixed a copy & paste error in the non-core drm version, and it actually > auto-refreshes the screen when switching between a tiled and untiled > resolution... Nice. What happened to Stephane's surface allocator, BTW? If you just whack the surface registers directly from the X server, it becomes hard if not impossible to introduce such an allocator, at least for the surfaces touched directly by the X server... > If noone has objections, I'm going to commit this (minus some printfs) > soon (consider yourself warned ;-)). Though I don't quite know if the > drm/dri changes should also be applied to xorg cvs. If you do, please check with Eric or Adam or whoever knows about it how to do it without messing up the vendor branches. Also, I noticed the following comment: > + /* note we cannot really simply use the info->ModeReg.crtc_offset_cntl > value. > + if we do that we'll get rid of the flip_cntl bit the kernel has set for > pageflipping. > + This seems to cause some visual disturbance with some apps (glxgears) > for some reason, Well, if you switch the roles of the front and back buffer several times while one of them is being scanned out, you can see the clears and rendering... > + however disabling flip_cntl also gets rid of the flickering we get when > hw scrolling > + in a virtual screen (since the crtc will pick up the new offset after > each scanline, > + but it will only pick up the new offset_cntl value after a vsync). > + We'd probably need to wait for vsync somehow if we've scrolled before > changing the > + offset to fix that flickering - unfixable ?*/ The DRM could update the register in the vblank interrupt handler? -- 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