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
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
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
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!
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
- 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 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
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
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
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 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
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
36 matches
Mail list logo
