Current tinderbox regressions (video drivers)

Dave Airlie airlied at redhat.com
Wed Feb 25 16:36:02 PST 2009


On Wed, 2009-02-25 at 18:13 +0100, Michel Dänzer wrote:
> On Wed, 2009-02-25 at 17:05 +0100, Matthias Hopf wrote:
> > On Feb 24, 09 19:46:24 +0100, Michel Dänzer wrote:
> > > On Tue, 2009-02-24 at 13:18 -0500, Chris Ball wrote:
> > > >    > EXA: Handle separate alpha maps properly in Composite fallback
> > > >    http://cgit.freedesktop.org/xorg/xserver/commit/?id=170cf1270dff38d3cce7f5ba5b940d1c0d70eff5
> > > > Driver maintainers:  from this commit onwards, EXA requires you to pass
> > > > in -DEXA_DRIVER_KNOWN_MAJOR=3, else it'll fail to build.  If you use
> > > > Prepare/FinishAccess, UploadToScratch or ExaOffscreenSwap*, you'll need
> > > > to make other changes too.
> > 
> > There used to be a time where API changes were supposed to be upwards
> > and downwards compatible. I grieve for that time.
> 
> So do I, in general... Unfortunately, this isn't always possible though.
> 
> > Seriously, this change would have been easy to do in a less invasive
> > manner by not nuking the hook, but just not using it any more. And by
> > adding an additional hook for the new buffer types.
> 
> You got that backwards (did anyone actually *look* at the change causing
> this before complaining? :}: I removed the UploadToScratch hook because
> I had to bump the major version, not the other way around. I had to bump
> the major version (and add the #error) because the EXA_PREPARE_* indices
> are passed to the driver Prepare/FinishAccess hooks, and some drivers
> like radeon(hd) use them as indices into arrays. Without these measures,
> the drivers would have continued to build and appeared to work, but
> could have broken in subtle ways when overflowing the arrays.
> 
> 
> > Enough ranting, radeonhd should be fixed now.
> 
> Thanks, I hope you checked the Prepare/FinishAccess hooks for the above
> (take a look at my radeon fix).
> 

What was wrong with defining a new flag that the driver passes back into
EXA to say it supports the new bits?

we have lots of flags, I don't see why adding a new one was so hard.

Dave.

> 



More information about the xorg-devel mailing list