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
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
-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
-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
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
-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
|> cont
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
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 u
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 spe
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
-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 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 w
-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 b
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
>
> 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
>
-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
-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
us
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
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
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 */
>
> glUnmapBuf
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
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
-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:
|>
-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 ha
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:
>
> |
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
-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
-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
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 fo
-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
60 matches
Mail list logo
