From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Olivier Galibert <galibert@pobox.com>
Cc: Dave Airlie <airlied@gmail.com>, Jan Dittmer <jdi@l4x.org>,
Diego Calleja <diegocg@gmail.com>,
linux-kernel@vger.kernel.org, eric.anholt@iintel.com,
airlied@linux.ie
Subject: Re: intel kms "Failed to allocate space for kernel memory manager"
Date: Mon, 12 Jan 2009 09:53:49 -0800 [thread overview]
Message-ID: <200901120953.50167.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <20090112130343.GA89729@dspnet.fr.eu.org>
On Monday, January 12, 2009 5:03 am Olivier Galibert wrote:
> On Mon, Jan 12, 2009 at 06:04:19PM +1000, Dave Airlie wrote:
> > explicit VideoRAM is most likely ignored by xorg as well for Intel
> > chipsets with the latest driver,
>
> I'm going on a tangeant, but it would be nice if video drivers, intel
> first among them, would stop ignoring user-provided configurations in
> favour of firmwares, bioses, in-display roms and other things like
> that that can be incorrect and not user-modifiable. VideoRAM is one,
> but there's also modeline, DPI...
On the contrary, I think we have way too many options and configuration
possibilities. The more we have, the more likely some combination of them
will be broken.
That said, modes are generally pretty easy to handle, so users can provide
them through xrandr and xorg.conf; I don't see that changing. VideoRAM OTOH
was broken by design. A user really has no way of knowing how much memory is
available to the GPU, so providing a configurable value was causing way more
problems than it solved.
But I suspect what you want it something else entirely, like a limit on the
amount of RAM that will be used by the GPU. I think that's a valid concern
and something like that could probably be added to GEM w/o too much trouble,
maybe through a new ulimit or system wide tunable.
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2009-01-12 17:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <621d098f0901110546p2b99a525k5de54e37fa181197@mail.gmail.com>
2009-01-11 13:51 ` intel kms "Failed to allocate space for kernel memory manager" Jan Dittmer
2009-01-11 21:21 ` Diego Calleja
2009-01-11 21:39 ` Dave Airlie
2009-01-11 22:04 ` Diego Calleja
2009-01-12 7:42 ` Jan Dittmer
2009-01-12 8:04 ` Dave Airlie
2009-01-12 8:37 ` Jan Dittmer
2009-01-12 17:56 ` Jesse Barnes
2009-01-12 18:30 ` Diego Calleja
2009-01-12 21:19 ` Jan Dittmer
2009-01-12 21:33 ` Jan Dittmer
2009-01-12 21:53 ` Jesse Barnes
2009-01-12 22:08 ` Jan Dittmer
2009-01-12 22:29 ` Jan Dittmer
2009-01-12 23:19 ` Jesse Barnes
2009-01-12 13:03 ` Olivier Galibert
2009-01-12 17:53 ` Jesse Barnes [this message]
2009-01-12 21:32 ` Olivier Galibert
2009-01-12 21:59 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200901120953.50167.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=diegocg@gmail.com \
--cc=eric.anholt@iintel.com \
--cc=galibert@pobox.com \
--cc=jdi@l4x.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox