[Intel-gfx] 2.10 and 2.9 point releases

[Dave Airlie]

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.

Dave.