Re: front/back buffer offsets in DRM
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
Re: front/back buffer offsets in DRM
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. Roland --- 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://ads.osdn.com/?ad_idv37&alloc_id865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
Am Samstag, den 26.11.2005, 10:47 -0700 schrieb Brian Paul: > Aapo Tahkola wrote: > > On Fri, 25 Nov 2005 16:16:48 -0700 > > Brian Paul <[EMAIL PROTECTED]> wrote: > > > > > >>I've been playing around with the EGL r200 driver. Digging through > >>the framebuffer allocation code I've found a few problems. > >> > >>In order to support pbuffers and framebuffer objects we need to be > >>able to work with color/depth/stencil buffers are various locations in > >>video memory. > >> > >>The current code sets the front/back/depth buffer offsets and pitches > >>once in the radeon_do_init_cp() function and there's no way to change > >>them thereafter. > >> > >>It looks like the only code that uses this information is the glClear > >>and SwapBuffers-related code in radeon_cp_dispatch_clear(), > >>radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code > >>that enables/disables color tiling. > >> > >>Could someone more familiar with the code comment on what it would > >>take to fix the code so that color/depth buffers at arbitrary > >>locations can be used? > >> > >>I'd probably do away with the front/back_offset/pitch fields entirely > >>and pass the offset/pitch values as parameters to the ioctls. I'd > >>also write the code so there's no distinction between front/back color > >>buffers. > > > > > > 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. > > -Brian > Regards, Felix -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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://ads.osdn.com/?ad_idv37&alloc_id865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
Aapo Tahkola wrote: On Fri, 25 Nov 2005 16:16:48 -0700 Brian Paul <[EMAIL PROTECTED]> wrote: I've been playing around with the EGL r200 driver. Digging through the framebuffer allocation code I've found a few problems. In order to support pbuffers and framebuffer objects we need to be able to work with color/depth/stencil buffers are various locations in video memory. The current code sets the front/back/depth buffer offsets and pitches once in the radeon_do_init_cp() function and there's no way to change them thereafter. It looks like the only code that uses this information is the glClear and SwapBuffers-related code in radeon_cp_dispatch_clear(), radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code that enables/disables color tiling. Could someone more familiar with the code comment on what it would take to fix the code so that color/depth buffers at arbitrary locations can be used? I'd probably do away with the front/back_offset/pitch fields entirely and pass the offset/pitch values as parameters to the ioctls. I'd also write the code so there's no distinction between front/back color buffers. 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. -Brian --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
On Fri, 25 Nov 2005 16:16:48 -0700 Brian Paul <[EMAIL PROTECTED]> wrote: > > I've been playing around with the EGL r200 driver. Digging through > the framebuffer allocation code I've found a few problems. > > In order to support pbuffers and framebuffer objects we need to be > able to work with color/depth/stencil buffers are various locations in > video memory. > > The current code sets the front/back/depth buffer offsets and pitches > once in the radeon_do_init_cp() function and there's no way to change > them thereafter. > > It looks like the only code that uses this information is the glClear > and SwapBuffers-related code in radeon_cp_dispatch_clear(), > radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code > that enables/disables color tiling. > > Could someone more familiar with the code comment on what it would > take to fix the code so that color/depth buffers at arbitrary > locations can be used? > > I'd probably do away with the front/back_offset/pitch fields entirely > and pass the offset/pitch values as parameters to the ioctls. I'd > also write the code so there's no distinction between front/back color > buffers. Whats the point of doing these operations in DRM anyway? Personally I would just pull out as much code from there as possible. -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
front/back buffer offsets in DRM
I've been playing around with the EGL r200 driver. Digging through the framebuffer allocation code I've found a few problems. In order to support pbuffers and framebuffer objects we need to be able to work with color/depth/stencil buffers are various locations in video memory. The current code sets the front/back/depth buffer offsets and pitches once in the radeon_do_init_cp() function and there's no way to change them thereafter. It looks like the only code that uses this information is the glClear and SwapBuffers-related code in radeon_cp_dispatch_clear(), radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code that enables/disables color tiling. Could someone more familiar with the code comment on what it would take to fix the code so that color/depth buffers at arbitrary locations can be used? I'd probably do away with the front/back_offset/pitch fields entirely and pass the offset/pitch values as parameters to the ioctls. I'd also write the code so there's no distinction between front/back color buffers. With OpenGL framebuffer objects there's no notion of front/back. Furthermore, a framebuffer object can have more than two color buffers. -Brian --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
