I have put up an updated version of the color tiling patch here:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri5.diff
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm5.diff
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx5.diff

(if you're wondering why it has already reached patch version 5, that's because the other versions Stephane and me were working on were never really announced somewhere...)

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). All other combinations should however work if I didn't forget something.

However, 2d doesn't quite work very well, and I have no idea how to fix some issues.
1) the biggest problem is XAA's handling of graphic memory. It treats everything as a single big chunk of linear framebuffer. But we're setting things up so that only the front buffer is tiled (and back buffer / depth buffer (always tiled) in case of 3d). Big problem here, since the XAA functions are the same whether the target is the front buffer or pixmap store. I tried to solve that with explicit src/dst_pitch_offsets, set in the Subsequentxxx functions according to the target (and source) address. However, I still get 2d rendering errors for some reasons. I think I'm missing something here. It is actually not completely bogus, so it can't be that wrong neither. At least the errors are the same with ACCEL_MMIO and ACCEL_CP (and the changed XAA functions still work when tiling is disabled). Any ideas what could be wrong?
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?
3) When switching from/to a resolution without tiling support, everything on screen will be really wrong and needs to be redrawn. I guess it's somehow possible to mark everything as dirty or something like that? Just externally calling "xrender" doesn't sound like a good solution...
4) surface setup is a mess. Not restored when switching from/to X, not working for regular dual-head, not changed when switching from/to tiled resolutions, and so on. So don't tell me it's broken, I know, it will get fixed, it isn't really a problem. This will eventually use Stephane's new surface ioctl. (The setup should be correct if you just start X and don't switch to a non-tiled resolution - yet the 2d rendering problems remain :-(.)
5) I'm not sure how exactly fbdev (the UseFBDev option) works, but I'm pretty confident it won't work at all with color tiling, and I've no idea how you'd fix that, though I don't think it's really an important issue (a regular fb console should get fixed when the surface regs are properly restored when leaving/entering X).


Unfortunately I think I might not figure out the XAA issues, so I could need some help there...

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

Reply via email to