Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
On Sat, 2009-03-21 at 18:02 -0700, Dave Airlie wrote: > Hi all, > > So I had to drop texture tiling when I did the radeon-rewrite but I'd like > to bring them back. > > Now with traditional drivers, we have the mesa copy of the texture and the > card copy, and we usually texture from VRAM only, so we can upload to VRAM > and tile on the way, and if we hit a sw fallback we just use the textures > from the mesa fallback. > > In the bufmgr world in theory we don't keep two copies of textures around, > and on radeons we can at least enable texture tiling on GART textures. So > if I store the texture tiled for hw use, we don't have anything like span > access to textures from what I can see for sw use. If the texture was in > VRAM, in theory for sw use we could use a surface, however it leave tiled > in GART busted. > > I'm just wondering if anyone has already tackled this in any driver, and > how this could work best. Does Gallium provide surface accessors for > textures like spans? Jose did a pretty good job of describing what's available for creating various views into texture data. What I'll add though is that Gallium has pretty much eliminated the requirement for software rasterization fallbacks in the first place. It's almost always possible to work around any hardware shortcoming with a combination of software vertex processing and fragment shader manipulation - which works out to be much faster than software rasterization. In a sweeping generalization, all hardware out there is capable of implementing one or another of the DX varients without resorting to fallbacks. Our task is just to implement the GL oddities above that fairly universal level of support. It turns out that there are very few places where this isn't possible, and the hardware designers know all about those cases and make sure to support them correctly in their designs. It would be pretty surprising to find out that a closed source GL driver was resorting to software fallbacks for any rasterization operation, I feel that we should be setting a similar standard for the open drivers. Keith -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
On Sat, 2009-03-21 at 18:02 -0700, Dave Airlie wrote: > Hi all, > > So I had to drop texture tiling when I did the radeon-rewrite but I'd like > to bring them back. > > Now with traditional drivers, we have the mesa copy of the texture and the > card copy, and we usually texture from VRAM only, so we can upload to VRAM > and tile on the way, and if we hit a sw fallback we just use the textures > from the mesa fallback. > > In the bufmgr world in theory we don't keep two copies of textures around, > and on radeons we can at least enable texture tiling on GART textures. So > if I store the texture tiled for hw use, we don't have anything like span > access to textures from what I can see for sw use. If the texture was in > VRAM, in theory for sw use we could use a surface, however it leave tiled > in GART busted. > > I'm just wondering if anyone has already tackled this in any driver, and > how this could work best. Does Gallium provide surface accessors for > textures like spans? > > I'm sort of thinking I keep two buffers objects, one sw only and one for > hw to use and use the GPU to blit between them when updates are needed. This is the kind of scenario that pipe_transfer was created for (from p_screen.h): /** Get a transfer object for transferring data to/from a texture */ struct pipe_transfer *(*get_tex_transfer)(struct pipe_screen *, struct pipe_texture *texture, unsigned face, unsigned level, unsigned zslice, enum pipe_transfer_usage usage, unsigned x, unsigned y, unsigned w, unsigned h); void (*tex_transfer_destroy)(struct pipe_transfer *); void *(*transfer_map)( struct pipe_screen *, struct pipe_transfer *transfer ); void (*transfer_unmap)( struct pipe_screen *, struct pipe_transfer *transfer ); It provides the necessary hooks and context for the pipe driver to untile/retile the texture. For example, you could keep a linear copy (temporary or not) in cached memory, and the tiled gpu copy. In get_tex_transfer or transfer_map you would untile from the gpu copy if the cpu copy was dirty. On transfer_unmap/tex_transfer_destroy you would re-tile, or even better, delay the tiling until the texture is bound to a context and a draw emmited. When rendering to a texture you'll mark the cpu copy dirty. When mapping the texture for write you'll mark the gpu copy dirty. etc. It is not as fine grained as span accessors but it is known to work very well. Jose -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
On Sat, Mar 21, 2009 at 9:02 PM, Dave Airlie wrote: > I'm just wondering if anyone has already tackled this in any driver, and > how this could work best. Does Gallium provide surface accessors for > textures like spans? > > I'm sort of thinking I keep two buffers objects, one sw only and one for > hw to use and use the GPU to blit between them when updates are needed. That's roughly what I did for the http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
> > textures like spans? > > The intel driver de-tiles in the software span accessing functions. Or > is there something I'm missing here? Do textures go through some other > path? It detiles buffer access via spans, textures don't go via spans from what I can see, the texstore code seems to operate direct on the buffers. Intel doesn't do texture tiling from what I know yet. Dave. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
On Sun, 2009-03-22 at 01:02 +, Dave Airlie wrote: > I'm just wondering if anyone has already tackled this in any driver, and > how this could work best. Does Gallium provide surface accessors for > textures like spans? The intel driver de-tiles in the software span accessing functions. Or is there something I'm missing here? Do textures go through some other path? -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
On 3/21/09, Dave Airlie wrote: > > Hi all, > > So I had to drop texture tiling when I did the radeon-rewrite but I'd like > to bring them back. > > Now with traditional drivers, we have the mesa copy of the texture and the > card copy, and we usually texture from VRAM only, so we can upload to VRAM > and tile on the way, and if we hit a sw fallback we just use the textures > from the mesa fallback. > > In the bufmgr world in theory we don't keep two copies of textures around, > and on radeons we can at least enable texture tiling on GART textures. So > if I store the texture tiled for hw use, we don't have anything like span > access to textures from what I can see for sw use. If the texture was in > VRAM, in theory for sw use we could use a surface, however it leave tiled > in GART busted. > > I'm just wondering if anyone has already tackled this in any driver, and > how this could work best. Does Gallium provide surface accessors for > textures like spans? > > I'm sort of thinking I keep two buffers objects, one sw only and one for > hw to use and use the GPU to blit between them when updates are needed. Something similar could also be used for non-CPU-accessible vram. In the linear texture or accessible vram cases the copy would be a nop. Alex -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
