Messages in this thread | | | Date | Sat, 6 Dec 2008 16:34:43 +1000 | From | "Dave Airlie" <> | Subject | Re: IO space memcpy support for userspace. |
| |
On Sat, Dec 6, 2008 at 6:22 AM, David Miller <davem@davemloft.net> wrote: > From: "Carlos O'Donell" <carlos@systemhalted.org> > Date: Fri, 5 Dec 2008 12:32:04 -0500 > >> On Thu, Dec 4, 2008 at 10:40 PM, Dave Airlie <airlied@gmail.com> wrote: >> > I'm sure this has come up before and I'm sure I'll either wish I never >> > posted this or someone will show me the crisp corpse of the last guy >> > who suggested it. >> >> Do you plan to prevent the compiler from issuing the same sorts of >> instructions that might appear in an optimized memcpy? >> >> Isn't it dangerous to have memory that doesn't behave like normal >> memory, and yet try to treat it like normal memory? >> >> This mismatch of abstractions is a warning that must not be ignored. > > This is basically my opinion as well. > > You'll pretty much need to surround accesses to these places with > accessor macros that do whatever is necessary on a given platform and > avoids the "dangerous" instructions in cases like IA64. > > Treating them like normal memory isn't going to work on all systems.
Its a real pain in the ass with dynamic buffer objects, we don't want userspace to care where they are located, the kernel migrates them in/out of video memory, GART, local RAM etc.
However I suspect I just need on these platforms to ban any CPU accesses to pixmaps in VRAM. However sw fallbacks to the front buffer will always need these accesses.
Its going to be a real pain getting any traction this stuff upstream (X.org/Mesa) where the world is x86 and maybe the odd powerpc, having to do special accessors for shithouse hw is never going to be fun.
Maybe I should start libshithouse to encapsulate the problem, I'll think about it some more.
Dave.
> BTW, the sunffb xorg driver has special code for "graphics copy" > which is essentially just a scanline by scanline GCOPY using the > MMX like stuff sparc64 has. It also is mindful of avoiding access > patterns that are known to lock up that chip :) > > That's just an aside, since sunffb doesn't provide any offscreen > pixmap memory and thus shouldn't be susceptible to this problem being > discussed here. > >
| |