Michel DÃnzer wrote:
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?
Maybe, but I couldn't figure out a semi-sane way. The problem is those
values get set in the generic _DRIAdjustFrame in dri.c, which knows
nothing about mergedfb. It seems rather difficult to fix these values up
there without extending dri so it knows that there can be two viewports
looking into the same buffer (i.e. make it mergedfb-aware).
This solution also automatically gets rid of the need to recalculate the
offset in the case of color tiling (which isn't really a problem, but
why does drm have to redo it in the first place?).
Reports though unfortunately indicate that new sarea field solution
doesn't work neither for some reason (it works for color tiling, though)
:-(.
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...
Stephane told me it doesn't work yet. I thought about it briefly if it
would be a problem to introduce it later, and I don't think it is. For
all shared buffers, it seems to be ok that ddx would allocate the
surfaces. So it would just use the allocator instead of doing it
directly (in case of direct rendering, otherwise still needs to set it
up manually for the front buffer).
In an ideal world, surface allocation should probably be directly tied
to memory allocation.
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.
Will do.
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...
That explains it... so FLIP_CNTL needs to stay (only triple buffering
could avoid that otherwise?).
+ 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?
That sounds right (didn't know there was such a handler, but there it
is...). I can't see how to do that though. Looks complicated :-(.
Roland
-------------------------------------------------------
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
