Intel DRM driver for SNB

Segovia, Benjamin benjamin.segovia at
Mon Dec 13 20:32:42 PST 2010

To be more explicit, my concern is that I read that Chris Wilson proposed a patch preventing the VM to swap pages still in GTT. I did not see any trace of this patch in the main line yet. 

So, it is anyway a bug which will be solved at some point? Can I be sure that once pinned in GTT and mapped in user space, my buffer can be safely used by both CPUs and GPUs and that the VM will never swap it?


----Original Message-----
From: Segovia, Benjamin 
Sent: Monday, December 13, 2010 8:20 PM
To: Segovia, Benjamin; Zhenyu Wang
Subject: RE: Intel DRM driver for SNB

I have been keeping on reading DRM driver. I am not sure I need to modify the driver (I would like to avoid it)

The application does the following:
1/ I pin a buffer in gtt space
2/ I map the buffer in user space using MMAP ioctl or dri_bo_map
3/ I directly use the GTT offset with no relocation when I am referencing the buffer in any states
4/ I exec a buffer with some surface states pointing to that mapped and pinned buffer

* Now, is there anything bad that may happen if I read and write from the CPU this mapped and pinned buffer?
* Am I sure that both CPU and GPU will read and write the same _physical_ piece of memory while Gen is processing the batch buffer?

The software I write for both EUs and CPUs will carefully handle memory coherency (flush of Gen caches in particular in Gen code). I just need to be sure that both are reading the same physical bits during the time GPU is processing the batch buffer.

Am I doing something correct?


-----Original Message-----
From: at [ at] On Behalf Of Segovia, Benjamin
Sent: Friday, December 10, 2010 8:15 PM
To: Zhenyu Wang
Subject: RE: Intel DRM driver for SNB

Thanks for the answer

I actually have no a rather simple prototype doing shared memory between CPU and GPU. Basically:
1/ I create a buffer B
2/ I map B and get a pointer to it
3/ I exec a batch buffer with B still mapped (ugly) and B pointed via a surface state internally 
4/ CPU and GPU are communicating throught B

To make things cleaner, I would like to let a non-root user pin the buffer in GTT (so change the ioctl rights) and write one more ioctl to make the CPU pages unevictable in shmfs (if I am right)

I would like to write an external module on top of i915 for these two functions. However, I am not sure I can get symbols from i915 properly. Is a i915 patch the only solution? 


From: Zhenyu Wang [zhenyuw at]
Sent: Monday, December 06, 2010 11:00 PM
To: Segovia, Benjamin
Subject: Re: Intel DRM driver for SNB

On 2010.12.06 15:18:02 -0800, Segovia, Benjamin wrote:
> Hello all,
> is the kernel driver configured to support reads/writes to LLC (last level cache i.e. L3) on SNB?

Now it's under limited use for the buffer that is sure to be cached,
e.g hw status page, etc. code lives in drivers/char/agp/intel-gtt.c.

Open Source Technology Center, Intel ltd.

$gpg --keyserver --recv-keys 4D781827
dri-devel mailing list
dri-devel at

More information about the dri-devel mailing list