On Wed, 2009-09-16 at 08:10 +1000, Dave Airlie wrote:
> 2009/9/16 Michel Dänzer <mic...@daenzer.net>:
> > From: Michel Dänzer <daen...@vmware.com>
> >
> > diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> > index 2ba61e1..341c21a 100644
> > --- a/include/drm/radeon_drm.h
> > +++ b/include/drm/radeon_drm.h
> > @@ -802,11 +802,12 @@ struct drm_radeon_gem_create {
> > uint32_t flags;
> > };
> >
> > -#define RADEON_TILING_MACRO 0x1
> > -#define RADEON_TILING_MICRO 0x2
> > -#define RADEON_TILING_SWAP 0x4
> > -#define RADEON_TILING_SURFACE 0x8 /* this object requires a surface
> > - * when mapped - i.e. front buffer */
> > +#define RADEON_TILING_MACRO 0x1
> > +#define RADEON_TILING_MICRO 0x2
> > +#define RADEON_TILING_SWAP_16BIT 0x4
> > +#define RADEON_TILING_SWAP_32BIT 0x8
> > +#define RADEON_TILING_SURFACE 0x10 /* this object requires a surface
> > + * when mapped - i.e. front buffer */
> >
>
> I know we haven't frozen API yet but this seems a bit unnecessary
> to reorder,
Actually, I'm not sure what the problem is, AFAICT userspace doesn't use
the RADEON_TILING_SURFACE flag at all yet. (I know that's a bug, I have
a pending corresponding X driver patch that will fix it)
> do we really need swap 16 and 32 bit? does it not depend on other info
> about the buffer?
A similar argument could be made against the separate macro / micro
tiling flags?
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
