On Mon, 28 Nov 2005 02:59:05 +0100 Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote: > >>>Whats the point of doing these operations in DRM anyway? > >>>Personally I would just pull out as much code from there as possible. > >> > >>I was wondering about that too. There may be some reason for doing > >>those things in the kernel, but I don't know of any. > > > > > > At least on some hardware buffer clearing and swapping is done by the 2D > > engine. Instead of exposing the necessary functionality through some > > generic blit or fill ioctls, specific clear and swap operations were > > implemented. The fact that the Xserver provides the offsets and pitches > > adds some sense of security by preventing untrusted clients from > > overwriting random memory. > > > > I believe it should be possible to replace clear and swap ioctls with > > generic blit and fill ioctls that do some range checking on their > > arguments. > You can't do that for "special" clears like the hyperz fast z clear on > radeons. It could probably still be moved to userspace though, but I'm > not too sure it makes a lot of sense. I think better long term plan would be to simulate 2d operations via standard opengl operations. That way we would get CopyTexSubImage* and similar operations accelerated with far less effort than by writing driver specific routines to do it. I agree on keeping the 2d routines around but you have to see that they are very limited in sense of what you can do with them. Another thing that bothers me is the amount of duplicate code around. radeon_cp_texture(), texrects uploads, and buffer swaps are just same operations done differently. -- Aapo Tahkola ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
