On Tue, 8 Jun 2010 21:54:03 +1000, Dave Airlie <[email protected]> wrote: > On Tue, Jun 8, 2010 at 7:56 PM, Eric Anholt <[email protected]> wrote: > > On Tue, 8 Jun 2010 09:16:13 +1000, Dave Airlie <[email protected]> wrote: > >> On Tue, Jun 8, 2010 at 6:55 AM, Eric Anholt <[email protected]> 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.
pgpnUrDY2YSPI.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
