Re: [Mesa3d-dev] Mesa (master): Fix DRI2 accelerated EXT_texture_from_pixmap with GL_RGB format.
On Fre, 2009-03-20 at 11:58 -0700, Eric Anholt wrote:
> On Fri, 2009-03-20 at 19:23 +0100, Michel Dänzer wrote:
> > On Fre, 2009-03-20 at 10:45 -0700, Eric Anholt wrote:
> > > Module: Mesa
> > > Branch: master
> > > Commit: 66175aac7609ad314f25fbdff0d3958af310dc24
> > > URL:
> > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=66175aac7609ad314f25fbdff0d3958af310dc24
> > >
> > > Author: Eric Anholt
> > > Date: Wed Mar 18 12:07:09 2009 -0700
> > >
> > > Fix DRI2 accelerated EXT_texture_from_pixmap with GL_RGB format.
> > >
> > > This requires upgrading the interface so that the argument to
> > > glXBindTexImageEXT isn't just dropped on the floor. Note that this only
> > > fixes the accelerated path on Intel, as Mesa's texture format support is
> > > missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as
> > > a8r8gb8,
> > > but in this case we're not doing the upload so we can't really work
> > > around it
> > > that way).
> > >
> > > Fixes bugs with compositors trying to use shaders that use alpha
> > > channels, on
> > > windows without a valid alpha channel. Bug #19910 and likely others as
> > > well.
> > >
> > > Reviewed-by: Ian Romanick
> >
> > [...]
> >
> > > @@ -239,11 +239,23 @@ struct __DRItexBufferExtensionRec {
> > > * Method to override base texture image with the contents of a
> > > * __DRIdrawable.
> > > *
> > > - * For GLX_EXT_texture_from_pixmap with AIGLX.
> > > + * For GLX_EXT_texture_from_pixmap with AIGLX. Deprecated in favor
> > > of
> > > + * setTexBuffer2 in version 2 of this interface
> > > */
> > > void (*setTexBuffer)(__DRIcontext *pDRICtx,
> > >GLint target,
> > >__DRIdrawable *pDraw);
> > > +
> > > +/**
> > > + * Method to override base texture image with the contents of a
> > > + * __DRIdrawable, including the required texture format attribute.
> > > + *
> > > + * For GLX_EXT_texture_from_pixmap with AIGLX.
> > > + */
> > > +void (*setTexBuffer2)(__DRIcontext *pDRICtx,
> > > + GLint target,
> > > + GLint format,
> > > + __DRIdrawable *pDraw);
> > > };
> >
> > Why did you bother sending out the change for public review if you were
> > only going to take notice of your colleague's ack and ignore suggestions
> > from others?
>
> I didn't think you were NAKing the patch. I'm not interested in
> complicating API so that at some point old API can be removed, when
> the overhead of implementing both is so low:
I don't see the point in carrying around a broken API when we actually
have a mechanism for replacing it with a better one. Did you discuss
this with Kristian Høgsberg?
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
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
[Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
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. 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 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
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
