-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
http://bugzilla.kernel.org/show_bug.cgi?id=10744
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED],
|
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 doi
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 o
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
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'
>
> 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
>
>
> 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 per
-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
>
> 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
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: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 st
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 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
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, 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 acheiv
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!
>
> M
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, 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 ma
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:
>>>
>>>
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
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 supp
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 b
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 manage
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 sus
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, s
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.
--
Con
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 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 qu
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
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 phy
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 wr
> > 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 vs GEM discussion questions
>
> >
> > For r
- 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 done us and our users. After more than *5 years* of
> >
>
> 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:
> > On 5/18/08, Thomas Hellström 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:
>
> | I've read the GEM documentation several time
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
52 matches
Mail list logo
