http://bugs.freedesktop.org/show_bug.cgi?id=15881
--- Comment #4 from Gordon Jin [EMAIL PROTECTED] 2008-05-18 23:10:38 PST ---
Brian, any comments?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
I had a whole bunch of other stuff written, but I deleted it. I started
~ having Jon Smirl deja vu. Life is hard for us because King Solomon cut
our drivers in half. He gave half to usermode and half to the kernel.
~ Wah!
On Mon, 2008-05-19 at 00:14 -0700, Ian Romanick wrote:
- - I'm pretty sure that the read_domain = GPU, write_domain = CPU case
needs to be handled. I know of at least one piece of hardware with a
kooky command buffer that wants to be used that way.
Oh, so mapping the same command buffer for
Stephane Marchesin wrote:
On 5/18/08, Thomas Hellström [EMAIL PROTECTED] wrote:
Yes, that was really my point. If the memory manager we use (whatever
it is) does not allow this kind of behaviour, that'll force all cards
to use a kernel-validated command submission model, which might
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
| I've read the GEM documentation several times, and I think I have a good
| grasp of it. I don't have any non-trivial complaints about GEM, but I
| do have a couple comments / observations:
|
| - I'm pretty sure that the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 00:14 -0700, Ian Romanick wrote:
|
| - - I'm pretty sure that the read_domain = GPU, write_domain = CPU case
| needs to be handled. I know of at least one piece of hardware with a
| kooky command buffer
- Original Message
From: Ian Romanick [EMAIL PROTECTED]
To: DRI dri-devel@lists.sourceforge.net
Sent: Monday, May 19, 2008 10:04:09 AM
Subject: Re: TTM vs GEM discussion questions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
| I've read the GEM
- Original Message
From: Thomas Hellström [EMAIL PROTECTED]
To: Stephane Marchesin [EMAIL PROTECTED]
Cc: DRI dri-devel@lists.sourceforge.net
Sent: Monday, May 19, 2008 9:49:21 AM
Subject: Re: TTM vs GEM discussion questions
Stephane Marchesin wrote:
On 5/18/08, Thomas
On Mon, 19 May 2008 02:22:00 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
There is also a bunch of up-and-coming GL functionality that you may not
be aware of that changes this picture a *LOT*.
- - GL_EXT_texture_buffer_object allows a portion of a buffer object to be
used to back a
On Mon, 19 May 2008 03:49:04 -0700 (PDT)
Keith Whitwell [EMAIL PROTECTED] wrote:
I don't actually think the problem is solvable for buffer-based memory
managers -- the best we can do is spot the failure and recover, either early
as the commands are submitted by the API, or some point
For radeon the plan was to return error from superioctl as during
superioctl and validation i do know if there is enough gart/vram to do
the things. Then i think it's up to upper level to properly handle such
failure from superioctl
You really want to work this out in advance, at
- Original Message
From: Dave Airlie [EMAIL PROTECTED]
To: Ian Romanick [EMAIL PROTECTED]
Cc: DRI dri-devel@lists.sourceforge.net
Sent: Monday, May 19, 2008 4:38:02 AM
Subject: Re: TTM vs GEM discussion questions
All the good that's done us and our users. After more than
- Original Message
From: Dave Airlie [EMAIL PROTECTED]
To: Jerome Glisse [EMAIL PROTECTED]
Cc: Keith Whitwell [EMAIL PROTECTED]; Ian Romanick [EMAIL PROTECTED]; DRI
dri-devel@lists.sourceforge.net
Sent: Monday, May 19, 2008 12:16:57 PM
Subject: Re: TTM vs GEM discussion questions
It's not clear to me which of the above the r300 nv people are aiming at,
but in my opinion the latter is such a significant departure from what we
have
been thinking about that I have always believed it should be addressed by a
new
set of interfaces.
My understanding of future
Just reposting this with a new subject line and less preamble.
- Original Message
Well the thing is I can't believe we don't know enough to do this in some
way generically, but maybe the TTM vs GEM thing proves its not possible.
I don't think there's anything particularly
Hi!
Parallell to the memory manager discussion, I think we need to revisit
the case of what happens when a
VRAM driver is suspending to memory.
1) The ideal thing would be for the card contents to be quickly copied
to backing-store and suspend is done.
However, this requires pinning as much
On Mon, 19 May 2008 12:16:57 +0100 (IST)
Dave Airlie [EMAIL PROTECTED] wrote:
For radeon the plan was to return error from superioctl as during
superioctl and validation i do know if there is enough gart/vram to do
the things. Then i think it's up to upper level to properly handle such
On Mon, 19 May 2008 15:03:50 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Hi!
Parallell to the memory manager discussion, I think we need to revisit
the case of what happens when a
VRAM driver is suspending to memory.
1) The ideal thing would be for the card contents to be quickly
On Mon, May 19, 2008 at 2:06 PM, Jerome Glisse [EMAIL PROTECTED] wrote:
On Mon, 19 May 2008 12:16:57 +0100 (IST)
Dave Airlie [EMAIL PROTECTED] wrote:
For radeon the plan was to return error from superioctl as during
superioctl and validation i do know if there is enough gart/vram to do
http://bugzilla.kernel.org/show_bug.cgi?id=10709
--- Comment #2 from [EMAIL PROTECTED] 2008-05-19 07:09 ---
I confirm that for proper operation I still need the drm-revert patch mentioned
above under patch. Fortunately the other one mentioned in Comment #1 has been
included.
--
Keith Whitwell wrote:
Texdown
1327MB/s (i915tex)
551MB/s (master, ttm)
572MB/s (master, no-ttm)
Texdown, subimage
1014MB/s (i915tex)
134MB/s (master, ttm)
148MB/s (master, no-ttm)
Gem on this machine (kernel 2.6.24) is hitting
Texdown 342MB/s
Texdown, subimage
On Mon, May 19, 2008 at 3:13 PM, Jerome Glisse [EMAIL PROTECTED] wrote:
On Mon, 19 May 2008 15:03:50 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Hi!
Parallell to the memory manager discussion, I think we need to revisit
the case of what happens when a
VRAM driver is suspending to
On Mon, 19 May 2008 16:25:13 +0200
Jakob Bornecrantz [EMAIL PROTECTED] wrote:
On Mon, May 19, 2008 at 3:13 PM, Jerome Glisse [EMAIL PROTECTED] wrote:
On Mon, 19 May 2008 15:03:50 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Hi!
Parallell to the memory manager discussion, I think
http://bugs.freedesktop.org/show_bug.cgi?id=15881
--- Comment #5 from Brian Paul [EMAIL PROTECTED] 2008-05-19 07:46:51 PST ---
Fix committed to git. Please re-test and update.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
On Mon, May 19, 2008 at 4:35 PM, Keith Whitwell
[EMAIL PROTECTED] wrote:
The biggest question is where we can write or read pages to swap at
suspend to RAM and resume from RAM under all occasions.
If not we have no other option then to have pages as backing store if
we want to support suspend
On Mon, May 19, 2008 at 5:03 PM, Jakob Bornecrantz [EMAIL PROTECTED] wrote:
On Mon, May 19, 2008 at 4:35 PM, Keith Whitwell
[EMAIL PROTECTED] wrote:
The biggest question is where we can write or read pages to swap at
suspend to RAM and resume from RAM under all occasions.
If not we have no
Jerome Glisse wrote:
On Mon, 19 May 2008 16:25:13 +0200
Jakob Bornecrantz [EMAIL PROTECTED] wrote:
On Mon, May 19, 2008 at 3:13 PM, Jerome Glisse [EMAIL PROTECTED] wrote:
On Mon, 19 May 2008 15:03:50 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Hi!
Parallell to the
On Mon, 19 May 2008 18:55:46 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Yes this is a way to do the actual implementation.
But we will always have situations where writing to swap may fail.
Systems without swap, systems low on swap, and systems without enough
physical memory to manage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| Thanks Ian to stress current and future usage, i was really hopping that
| with GL3 buffer object mapping would have vanish but i guess as you said
| that the fire-and-forget path never get optimized.
I think various drivers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
| Ian Romanick wrote:
|
| | I've read the GEM documentation several times, and I think I have a
good
| | grasp of it. I don't have any non-trivial complaints about GEM, but I
| | do have a couple comments / observations:
| |
| |
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
| Nothing can solve Ians
| problems where the app gives you a single working set that is too
large at
| least with current GL.
Eh? It's called fallback to software. It's the only thing the GL spec
allows you to do. We've been
On Mon, 19 May 2008 10:25:16 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
| Does in GL3 object must be unmapped before being use ? IIRC this what is
| required in current GL 1.x and GL 2.x. If so i think i can still use VRAM
| as cache ie i put their object which are barely never mapped (like
On Friday, May 16, 2008 2:26 pm Stephen Hemminger wrote:
After the screensaver does it's idle shut off of the monitor, it never
comes back. This is a new problem and only shows up post 2.6.25.
Console log messages:
Note: this message should be WARN_ON_ONCE() since it fills the disk!
May 16
On Mon, 2008-05-19 at 05:09 -0700, Keith Whitwell wrote:
I
think the latter is the significant result -- none of these experiments
in memory management significantly change the command stream the
hardware has to operate on, so what we're varying essentially is the
CPU behaviour to acheive
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
| Ian Romanick wrote:
|
| | I've read the GEM documentation several times, and I think I have a
good
| | grasp of it. I don't have any non-trivial complaints about GEM, but I
| | do have a couple
On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
glBindBuffer(GL_ARRAY_BUFFER, my_buf);
GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
if (data == NULL) {
/* fail */
}
/* Fill in buffer data */
Keith Packard wrote:
On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
glBindBuffer(GL_ARRAY_BUFFER, my_buf);
GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
if (data == NULL) {
/* fail */
}
/* Fill in buffer data */
Keith Packard wrote:
On Mon, 2008-05-19 at 05:09 -0700, Keith Whitwell wrote:
I
think the latter is the significant result -- none of these experiments
in memory management significantly change the command stream the
hardware has to operate on, so what we're varying essentially is the
On Mon, 2008-05-19 at 20:32 +0200, Thomas Hellström wrote:
Keith Packard wrote:
On Mon, 2008-05-19 at 05:09 -0700, Keith Whitwell wrote:
I
think the latter is the significant result -- none of these experiments
in memory management significantly change the command stream the
On Mon, 2008-05-19 at 20:22 +0200, Thomas Hellström wrote:
I think the point here is when the buffer in 1) is mapped write-combined
which IMHO is the obvious approach,
the caches aren't affected at all.
write-combining only wins if you manage to get writes to the same cache
line to line up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| On Mon, 19 May 2008 10:25:16 -0700
| Ian Romanick [EMAIL PROTECTED] wrote:
|
| | Does in GL3 object must be unmapped before being use ? IIRC this
what is
| | required in current GL 1.x and GL 2.x. If so i think i can still
use
glxgears uses 40% of the CPU in both classic and gem. Note that the gem
version takes about 20 seconds to reach a steady state -- the gem driver
isn't clearing the gtt actively and so glxgears gets far ahead of the
gpu.
My theory is that this shows that using cache-aware copies from a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 10:25 -0700, Ian Romanick wrote:
|
| glBindBuffer(GL_ARRAY_BUFFER, my_buf);
| GLfloat *data = glMapBufferData(GL_ARRAY_BUFFER, GL_READ_WRITE);
| if (data == NULL) {
| /* fail */
1) The ideal thing would be for the card contents to be quickly copied
to backing-store and suspend is done.
However, this requires pinning as much physical pages as there is VRAM.
2) The other approach is to have a backing object of some sort, either a
list of swap-entries or perhaps a
Spliting the cmd before they get submited is the way to go, likely we can
ask the kernel for estimate of available memory and so userspace can stop
building cmd stream but this isn't easy. Well anyway this would be a
userspace problem. Anyway we still will have to fail in superioctl if
for
On Mon, 2008-05-19 at 20:11 +0100, Keith Whitwell wrote:
I'm still confused by your test setup... Stepping back from cache
metaphysics, why doesn't classic pin the hardware, if it's still got
60% cpu to burn?
glxgears under classic is definitely not pinning the hardware -- the
'intel_idle'
On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote:
It depends on the hardware. In the second approach the driver has no
opportunity to do something smart if the copy path isn't the fast
path. Applications are being tuned more for the hardware where the copy
path isn't the fast path.
It
Dave Airlie wrote:
1) The ideal thing would be for the card contents to be quickly copied
to backing-store and suspend is done.
However, this requires pinning as much physical pages as there is VRAM.
2) The other approach is to have a backing object of some sort, either a
list of
On Mon, May 19, 2008 at 08:52:49PM +0100, Dave Airlie wrote:
Now I would be willing to provide a drm tuneable sorta like memory
overcommit that could be used on embedded systems and basically says I've
designed my system so I never need suspend/resume and I really udnerstand
what I'm doing,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote:
|
| It depends on the hardware. In the second approach the driver has no
| opportunity to do something smart if the copy path isn't the fast
| path. Applications are being
On Mon, 2008-05-19 at 17:27 -0700, Ian Romanick wrote:
Apps are using and will increasingly use the glMapBuffer path. With the
information currently at hand, doing the alloc/copy/upload/free in the
driver might be the win. Great. It's way too soon to box ourselves
into that route. If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
| On Mon, 2008-05-19 at 17:27 -0700, Ian Romanick wrote:
|
| Apps are using and will increasingly use the glMapBuffer path. With the
| information currently at hand, doing the alloc/copy/upload/free in the
| driver might be the
52 matches
Mail list logo
