Re: TTM vs GEM discussion questions

2008-05-30 Thread Matthias Hopf
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

Re: TTM vs GEM discussion questions

2008-05-28 Thread Steven J Newbury
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

Re: TTM vs GEM discussion questions

2008-05-21 Thread Ian Romanick
-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

Re: TTM vs GEM discussion questions

2008-05-21 Thread Eric Anholt
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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Dave Airlie
> > 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 >

Re: TTM vs GEM discussion questions

2008-05-19 Thread Thomas Hellström
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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Ian Romanick
-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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Ian Romanick
-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: |>

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
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/

Re: TTM vs GEM discussion questions

2008-05-19 Thread Jerome Glisse
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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
> > 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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
- 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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
- 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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Dave Airlie
> > 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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Jerome Glisse
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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
- 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: >

Re: TTM vs GEM discussion questions

2008-05-19 Thread Keith Whitwell
- 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: > > |

Re: TTM vs GEM discussion questions

2008-05-19 Thread Ian Romanick
-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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Thomas Hellström
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

Re: TTM vs GEM discussion questions

2008-05-19 Thread Ian Romanick
-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

Re: TTM vs GEM discussion questions

2008-05-18 Thread Dave Airlie
> > 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

Re: TTM vs GEM discussion questions

2008-05-18 Thread Ian Romanick
-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

Re: TTM vs GEM discussion questions

2008-05-18 Thread Dave Airlie
> > 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

Re: TTM vs GEM discussion questions

2008-05-18 Thread Ian Romanick
-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

Re: TTM vs GEM discussion questions

2008-05-18 Thread Stephane Marchesin
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

Re: TTM vs GEM discussion questions

2008-05-18 Thread Thomas Hellström
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

Re: TTM vs GEM discussion questions

2008-05-18 Thread Stephane Marchesin
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Pekka Paalanen
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Thomas Hellström
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Jerome Glisse
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,

Re: TTM vs GEM discussion questions

2008-05-16 Thread Thomas Hellström
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Thomas Hellström
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Jerome Glisse
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Thomas Hellström
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Jerome Glisse
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Thomas Hellström
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Keith Packard
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

Re: TTM vs GEM discussion questions

2008-05-16 Thread Jerome Glisse
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

TTM vs GEM discussion questions

2008-05-16 Thread Thomas Hellström
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