Hello gurus,
I have two question mostly regarding libdrm_intel
1/ What is the difference between drm_intel_bo_map and drm_intel_gem_bo_map_gtt ? 2/ Will it be possible (or is it already possible) to directly share a regularly allocated piece of physical memory? Typical use case is the following one using OpenCL API: char *ptr = malloc(sz); cl_mem buf = clCreateBuffer(ctx, CL_MEM_USE_HOST_PTR, sz, ptr, &err);
Here, you create a buffer which directly uses the physical memory you are going to use for ptr. The idea, I guess, is to give GTT pages for this piece of memory. Today, I get a similar functionnality the other way using mostly: drm_intel_bo *bo = drm_intel_bo_alloc(..) char *ptr = drm_intel_bo_map(...)
Thanks!
Ben
On Fri, 27 May 2011 14:37:45 -0700, "Segovia, Benjamin" benjamin.segovia@intel.com wrote:
Hello gurus,
I have two question mostly regarding libdrm_intel
1/ What is the difference between drm_intel_bo_map and drm_intel_gem_bo_map_gtt ?
bo_map uses the CPU domain, and so is CPU linear (needs sw detiling). bo_gtt_map uses the uncached [WC] GTT domain, and so is GPU linear (detiling is performed by the hardware using a fence).
2/ Will it be possible (or is it already possible) to directly share a regularly allocated piece of physical memory? Typical use case is the following one using OpenCL API:
Yes. I've proposed a vmap interface to bind user-pages into the GTT, similar to a completely unused bit of TTM functionality. -Chris
1/ Thanks! 2/ Is it available now or is it still a project? Thanks, Ben
-----Original Message----- From: Chris Wilson [mailto:chris@chris-wilson.co.uk] Sent: Saturday, May 28, 2011 1:54 AM To: Segovia, Benjamin; dri-devel@lists.freedesktop.org Subject: Re: Questions about libdrm_intel and way to share physical memory between CPU and GPU
On Fri, 27 May 2011 14:37:45 -0700, "Segovia, Benjamin" benjamin.segovia@intel.com wrote:
Hello gurus,
I have two question mostly regarding libdrm_intel
1/ What is the difference between drm_intel_bo_map and drm_intel_gem_bo_map_gtt ?
bo_map uses the CPU domain, and so is CPU linear (needs sw detiling). bo_gtt_map uses the uncached [WC] GTT domain, and so is GPU linear (detiling is performed by the hardware using a fence).
2/ Will it be possible (or is it already possible) to directly share a regularly allocated piece of physical memory? Typical use case is the following one using OpenCL API:
Yes. I've proposed a vmap interface to bind user-pages into the GTT, similar to a completely unused bit of TTM functionality. -Chris
On Sat, 28 May 2011 09:54:01 +0100 Chris Wilson chris@chris-wilson.co.uk wrote:
On Fri, 27 May 2011 14:37:45 -0700, "Segovia, Benjamin" benjamin.segovia@intel.com wrote:
Hello gurus,
I have two question mostly regarding libdrm_intel
1/ What is the difference between drm_intel_bo_map and drm_intel_gem_bo_map_gtt ?
bo_map uses the CPU domain, and so is CPU linear (needs sw detiling). bo_gtt_map uses the uncached [WC] GTT domain, and so is GPU linear (detiling is performed by the hardware using a fence).
2/ Will it be possible (or is it already possible) to directly share a regularly allocated piece of physical memory? Typical use case is the following one using OpenCL API:
Yes. I've proposed a vmap interface to bind user-pages into the GTT, similar to a completely unused bit of TTM functionality.
It seems to me that stolen memory and other things could all be sorted out somewhat if the GEM layer and GEM as shmemfs backing were split apart a bit. A 'privately backed' GEM object wouldn't be able to support flink() but I can't find much else that would break ?
Wondering about this for things like the GMA500, and also to get back all that memory the i9xx driver burns on a PC.
On Thu, 2 Jun 2011 19:42:03 +0100, Alan Cox alan@lxorguk.ukuu.org.uk wrote:
On Sat, 28 May 2011 09:54:01 +0100 Chris Wilson chris@chris-wilson.co.uk wrote:
On Fri, 27 May 2011 14:37:45 -0700, "Segovia, Benjamin" benjamin.segovia@intel.com wrote:
Hello gurus,
I have two question mostly regarding libdrm_intel
1/ What is the difference between drm_intel_bo_map and drm_intel_gem_bo_map_gtt ?
bo_map uses the CPU domain, and so is CPU linear (needs sw detiling). bo_gtt_map uses the uncached [WC] GTT domain, and so is GPU linear (detiling is performed by the hardware using a fence).
2/ Will it be possible (or is it already possible) to directly share a regularly allocated piece of physical memory? Typical use case is the following one using OpenCL API:
Yes. I've proposed a vmap interface to bind user-pages into the GTT, similar to a completely unused bit of TTM functionality.
It seems to me that stolen memory and other things could all be sorted out somewhat if the GEM layer and GEM as shmemfs backing were split apart a bit. A 'privately backed' GEM object wouldn't be able to support flink() but I can't find much else that would break ?
Wondering about this for things like the GMA500, and also to get back all that memory the i9xx driver burns on a PC.
I'd much rather be able to just hand that memory off to the kernel to use along with everything else and have there be nothing magic about it. But as I recall, the mtrr mappings of that memory was often goofy, so it may take some work to clean it up.
I'd much rather be able to just hand that memory off to the kernel to use along with everything else and have there be nothing magic about it. But as I recall, the mtrr mappings of that memory was often goofy, so it may take some work to clean it up.
That also depends where it is located - you'd need to add memory hot plug, and in the general case (as opposed to the Intel i9xx case) that memory may not be main memory anyway.
We can't go giving memory that is actually part of some other system complex on some of the non Intel devices to the CPU for example. So yes its a hack that works in limited cases for Intel to give the memory to the system but you need 3 level page tables, memory hot plug and PAT enabled to pull that off.
Either way the two appear to be different things, and both have their uses.
Alan
dri-devel@lists.freedesktop.org
-
Alan Cox -
Chris Wilson -
Eric Anholt -
Segovia, Benjamin