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 appl
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 bus
-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 rele
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 e
>
> 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
>
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 hav
-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 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:
|>
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/
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 han
> > 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 understandin
- Original Message
> From: Dave Airlie <[EMAIL PROTECTED]>
> To: Jerome Glisse <[EMAIL PROTECTED]>
> Cc: Keith Whitwell <[EMAIL PROTECTED]>; Ian Romanick <[EMAIL PROTECTED]>; DRI
>
> Sent: Monday, May 19, 2008 12:16:57 PM
> Subject: Re: TTM v
- Original Message
> From: Dave Airlie <[EMAIL PROTECTED]>
> To: Ian Romanick <[EMAIL PROTECTED]>
> Cc: DRI
> Sent: Monday, May 19, 2008 4:38:02 AM
> Subject: Re: TTM vs GEM discussion questions
>
>
> >
> > All the good that's do
>
> 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 sup
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 poin
- Original Message
> From: Thomas Hellström <[EMAIL PROTECTED]>
> To: Stephane Marchesin <[EMAIL PROTECTED]>
> Cc: DRI
> Sent: Monday, May 19, 2008 9:49:21 AM
> Subject: Re: TTM vs GEM discussion questions
>
> Stephane Marchesin wrote:
>
- Original Message
> From: Ian Romanick <[EMAIL PROTECTED]>
> To: DRI
> 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:
>
> |
-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 read_dom
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
-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! W
>
> 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
> neve
-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 every
>
> 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
-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 fa
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, a
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
>> > own memory address space on the GPU. I can manag
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 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 a
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
>> l
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,
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 st
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 apertur
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 propos
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 t
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 th
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
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 clflush doesn't
affect the cache
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 im
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
r
39 matches
Mail list logo