On May 21, 08 11:35:43 -0700, Ian Romanick wrote:
| We haven't touched the texsubimage path, having not found it in a
| profile yet. It'll probably be doing map/write/unmap, which (as noted
| elsewhere in the thread) is pretty much the worst thing you can do. If
| you have a relevant
I hope this is a sensible question, but here goes...
PXA270 CPUs have integrated graphics hardware which is basically a dumb
framebuffer, but it has 256KiB of SRAM which in theory can be used as a
graphics buffer. The current pxafb driver just uses the (slow) system
RAM and takes a lot of the
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Hellström wrote:
| Ian Romanick wrote:
| Jerome Glisse wrote:
| | On Mon, 19 May 2008 12:04:16 -0700
| | Ian Romanick [EMAIL PROTECTED] wrote:
| |
| | The GLX spec says, basically, that the results of changes to a
On Mon, 19 May 2008 12:04:16 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
The GLX spec says, basically, that the results of changes to a shared
object in context A are guaranteed to be visible to context B when
context B binds the object. It leaves a lot of slack for changes to
show up
On Sun, 2008-05-18 at 17:55 +0200, Thomas Hellström wrote:
Stephane Marchesin wrote:
On 5/16/08, Pekka Paalanen [EMAIL PROTECTED] wrote:
On Fri, 16 May 2008 10:05:18 +0200
Jerome Glisse [EMAIL PROTECTED] wrote:
My current understanding is that on newer GPU each client got its
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| On Mon, 19 May 2008 12:04:16 -0700
| Ian Romanick [EMAIL PROTECTED] wrote:
|
| The GLX spec says, basically, that the results of changes to a shared
| object in context A are guaranteed to be visible to context B when
| context
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerome Glisse wrote:
| On Mon, 19 May 2008 12:04:16 -0700
| Ian Romanick [EMAIL PROTECTED] wrote:
|
| The GLX spec says, basically, that the results of changes to a shared
| object in context A are guaranteed to be visible
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
| We haven't touched the texsubimage path, having not found it in a
| profile yet. It'll probably be doing map/write/unmap, which (as noted
| elsewhere in the thread) is pretty much the worst thing you can do. If
| you have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Hellström wrote:
| Ian Romanick wrote:
| Jerome Glisse wrote:
| | On Mon, 19 May 2008 12:04:16 -0700
| | Ian Romanick [EMAIL PROTECTED] wrote:
| |
| | The GLX spec says, basically, that the results of changes to a shared
| | object in context A
Keith Packard wrote:
On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote:
The obvious overhead I was referring to is the extra malloc / free.
That's why I went on to say So, now I have to go back and spend time
caching the buffer allocations and doing other things to make it fast.
~ In
On Tue, May 20, 2008 at 1:29 PM, Thomas Hellström
[EMAIL PROTECTED] wrote:
Keith Packard wrote:
On Mon, 2008-05-19 at 12:13 -0700, Ian Romanick wrote:
The obvious overhead I was referring to is the extra malloc / free.
That's why I went on to say So, now I have to go back and spend time
-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
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, 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
-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
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 */
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
-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 */
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 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
-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
On 5/16/08, Pekka Paalanen [EMAIL PROTECTED] wrote:
On Fri, 16 May 2008 10:05:18 +0200
Jerome Glisse [EMAIL PROTECTED] wrote:
My current understanding is that on newer GPU each client got its
own memory address space on the GPU. I can manage this space
transparently based on hint from
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 not be
too fast, and more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin 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 not be
| too
I honestly don't see a problem with having multiple memory managers. We
have different hardware with different functionality and different
performance characteristics. The probability of one memory manager
fitting everywhere is nil. Quite frankly, the fact that it has take
this long to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
| I honestly don't see a problem with having multiple memory managers. We
| have different hardware with different functionality and different
| performance characteristics. The probability of one memory manager
| fitting
All the good that's done us and our users. After more than *5 years* of
various memory manager efforts we can't support basic OpenGL 1.0 (yes,
1.0) functionality in a performant manner (i.e., glCopyTexImage and
friends). We have to get over this it has to be perfect or it will
never get
Hi.
I have a couple of question w r t the TTM vs GEM discussion:
1) How does pwrite() avoid clflush()es or wbinvd()s in the i915 gem case?
2) Some people have stated that GPU page faults could not be implemented
with TTM.
We've certainly dealt with that type of hardware, but found no obvious
On Fri, 16 May 2008 09:28:31 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Hi.
I have a couple of question w r t the TTM vs GEM discussion:
1) How does pwrite() avoid clflush()es or wbinvd()s in the i915 gem case?
2) Some people have stated that GPU page faults could not be
Keith Packard wrote:
On Fri, 2008-05-16 at 09:28 +0200, Thomas Hellström wrote:
Hi.
I have a couple of question w r t the TTM vs GEM discussion:
2) Some people have stated that GPU page faults could not be implemented
with TTM.
We've certainly dealt with that type of hardware,
Jerome Glisse wrote:
On Fri, 16 May 2008 09:28:31 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Hi.
I have a couple of question w r t the TTM vs GEM discussion:
1) How does pwrite() avoid clflush()es or wbinvd()s in the i915 gem case?
2) Some people have stated that GPU page faults
On Fri, 16 May 2008 10:41:39 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Packard wrote:
Certainly moving from object management to page management would
simplify handling of the GPU memory space, but I'm not sure how making
these objects demand-paged would help all that much.
On Fri, 16 May 2008 11:16:26 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Now if you want to map paging-capable VRAM,
that's what the on-card VRAM aperture page table is for. You stated that
it's a bad idea to use it. Why?
If there is aperture page table than the solution you propose
Jerome Glisse wrote:
On Fri, 16 May 2008 11:16:26 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Now if you want to map paging-capable VRAM,
that's what the on-card VRAM aperture page table is for. You stated that
it's a bad idea to use it. Why?
If there is aperture page table
Keith Packard wrote:
On Fri, 2008-05-16 at 09:28 +0200, Thomas Hellström wrote:
Hi.
I have a couple of question w r t the TTM vs GEM discussion:
1) How does pwrite() avoid clflush()es or wbinvd()s in the i915 gem case?
It doesn't, but as pwrite uses non-temporal stores, the
On Fri, 16 May 2008 12:20:29 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Cache coherency and caching policy is a non-issue with user-space VRAM
mappings.
I think with the pwrite approach you will run into severe performance
problems if used for
long-lived buffers.
Think EXA, vertical
Jerome Glisse wrote:
On Fri, 16 May 2008 12:20:29 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
Cache coherency and caching policy is a non-issue with user-space VRAM
mappings.
I think with the pwrite approach you will run into severe performance
problems if used for
long-lived
On Fri, 16 May 2008 10:05:18 +0200
Jerome Glisse [EMAIL PROTECTED] wrote:
My current understanding is that on newer GPU each client got its
own memory address space on the GPU. I can manage this space
transparently based on hint from userspace, ie i can place page
either in ram or vram and i
58 matches
Mail list logo
