[Intel-gfx] 2.10 and 2.9 point releases

[Eric Anholt]

On Tue, 8 Jun 2010 21:54:03 +1000, Dave Airlie <airlied at gmail.com> wrote:
> On Tue, Jun 8, 2010 at 7:56 PM, Eric Anholt <eric at anholt.net> wrote:
> > On Tue, 8 Jun 2010 09:16:13 +1000, Dave Airlie <airlied at gmail.com> wrote:
> >> On Tue, Jun 8, 2010 at 6:55 AM, Eric Anholt <eric at anholt.net> wrote:
> >> > For whatever libdrm knock-it-off-with-the-overallocation patch we settle
> >> > on, it's going to trigger the bug with the 2D driver underallocating
> >> > framebuffer memory on my 1440x900 laptop.  I've pushed tested patches to
> >> > both branches, and my plan is to roll point releases of those, and
> >> > mention in the libdrm release notes whenever that happens that you'll
> >> > want either 2.9.2, 2.10.1, 2.11, or
> >> > d08782e1a17279092fa4027d98d25ef36a9f80e5 in your 2D driver.  The
> >> > alternative would be for libdrm to avoid good behavior unless the driver
> >> > said it was ready to cope, but that seems messy when the fix is so
> >> > trivial.
> >>
> >> Uggh, you've heard of ABIs? I'd rather we maintained them if we could.
> >
> > It was certainly never my intention that "your BOs are all power of two
> > sized" was part of the ABI.  I figured with a 1-line patch to the buggy
> > software and a mention in the release notes we'd be fine.e
> 
> But that is what you actually did when you made the ABI do that and
> then used it wrong in the drivers.
> 
> Sometimes you have to live with what you did rather than what you
> intended on doing.
> 
> It shouldn't be a major problem to either add a new API call that does
> the right thing and leave the old one alone, or add some init call
> that lets libdrm_intel know the caller is safe.
> 
> Otherwise this is going to break bisection in what is meant to be a
> stable driver, and that is bad, and I remember statements being waved
> around when libdrm_intel was created about it not going into the
> libdrm repo unless the ABI was maintained.

If so, we'd have to remove BO caching entirely, since that broke bad
drivers at the time, too.  And I've got someone with a broken 2D driver
right now bisecting down to a libdrm aperture checking fix that made it
so that people on pre-gen4 didn't get their rendering rejected by the
kernel.

I do try really hard to maintain ABI.  But sometimes when you're dealing
with enough revisions of buggy software, there's no good option, and you
just have to weigh costs -- in this case, is everyone's systems wasting
25% more memory for graphics worth people with 1440x900 screens having
to take a 1-line bugfix to their 2D driver.

Luckily, though, in the end the patch that just adds more buckets and
wasting probably 5% of memory won out on performance tests, which will
avoid tickling the 2D driver failure.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100608/b64d771e/attachment.sig>