|author||feydun <email@example.com>||2012-09-18 18:11:14 +0100|
|committer||Stéphane Marchesin <firstname.lastname@example.org>||2012-10-08 15:30:34 -0700|
minor changes to section 5.1 only
1 files changed, 39 insertions, 40 deletions
diff --git a/linuxgraphicsdrivers.lyx b/linuxgraphicsdrivers.lyx
index 8071316..8ad801e 100644
@@ -5216,8 +5216,8 @@ y to user space.
More recently, the DRM was improved to achieve modesetting.
This simplifies the previous situation where both the DRM and the framebuffer
driver were fighting to access the same GPU.
- Instead, the framebuffer driver is removed and instead framebuffer support
- is implemented in the DRM.
+ Instead, the framebuffer driver has been removed and framebuffer support
+ is implemented from within the DRM.
@@ -5445,16 +5445,16 @@ One of the duties of the DRM is to multiplex the GPU itself between multiple
user space processes.
-Given that the GPU holds graphics state, a problem arises when multiple
+Given that the GPU holds the graphics state, a problem arises when multiple
applications use the same GPU: if nothing is done, the applications can
stomp over each other's state.
- Depending on the hardware at hand, there are two major cases:
+ Depending on the hardware, there are two main cases:
When the GPU features hardware state tracking, the hardware sharing is simpler
- since each application can send to a separate context, and the GPU tracks
- each application's state itself.
+ since each application can send to a separate context, and the GPU itself
+ tracks each application's state.
This is the way the nouveau driver works.
@@ -5466,13 +5466,13 @@ When the GPU doesn't have multiple hardware contexts, the common way of
batch buffer; it's the way the intel and radeon drivers multiplex the GPU.
Note that this duty of reemitting the state relies on user space entirely.
If the user space doesn't reemit the state at the begining of each batch
- buffer, the state from other DRM processes will leak onto it.
+ buffer, the state from other DRM processes will leak into it.
-The DRM also prevent simultaneous access to the same hardware.
+The DRM also prevents simultaneous access to the same hardware.
@@ -5486,22 +5486,22 @@ Memory management and security
The kernel has the ability to move memory areas around to handle high memory
- Depending on the hardware, there are two ways to achieve it:
+ Depending on the hardware, there are two ways to do this:
If the hardware has complete memory protection and virtualization, then
- it is possible to page in memory resources into the GPU as they get allocated
+ it is possible to page memory resources into the GPU as they get allocated
and isolate them per-process.
- Therefore not much is required to support memory protection of GPU memory.
+ In this case not much is required to support memory protection for GPU
When the hardware doesn't have memory protection, this can still be achieved
- entirely in the kernel, in a way where the user space is completely oblivious
- to it.
+ entirely in the kernel, transparently to user space.
In order to allow relocations to work for a user space process which is
otherwise unaware of them, the command submission ioctl will rewrite the
command buffers in the kernel by replacing all the hardware offsets to
@@ -5516,7 +5516,7 @@ To prevent access to arbitrary GPU memory, the command submission ioctl
can also check that each of these offsets is owned by the calling process,
and reject the batch buffer if it isn't.
That way it is possible to implement memory protection when the hardware
- doesn't provide that functionality.
+ doesn't provide the functionality.
Although there is some overhead for doing command buffer parsing, it is
bearable, and this is how the open source radeon drivers work.
@@ -5528,19 +5528,19 @@ GEM Buffer management
GPU buffer allocation and management is done in the kernel and exposed to
the userspace through the GEM interface.
- Such buffer is then called an object or a buffer object (BO).
+ The resulting buffer is then called an object or a buffer object (BO).
-GEM has been introduced by Intel in 2008 to simplify Tungsten Graphics'
- TTM (Translation Table Maps) and became the standard way to allocate, read,
- write and sharing BOs between applications.
+GEM was introduced by Intel in 2008 to simplify Tungsten Graphics' TTM (Translat
+ion Table Maps) and became the standard way to allocate, read, write and
+ sharing BOs between applications.
It is however impossible to share buffers between drivers through GEM.
-As the GEM interface is driver-dependent, it is advised to use the driver-depend
-ent libdrm calls to manage your buffers.
+As the GEM interface is driver-dependent, it is best to use the driver-dependent
+ libdrm calls to manage your buffers.
However, the general outline of the interface remains fairly constant.
@@ -5574,7 +5574,7 @@ pread/pwrite : syscalls to read/write to/from a buffer object.
-mapping the BO : it is possible for the userspace to map the BO in his memory
+mapping the BO : it is possible for the userspace to map the BO in its memory
Mapping takes the BO offset and size that should be mapped as an argument.
It then returns the address of the BO in the user's virtual address space.
@@ -5590,27 +5590,27 @@ The GEM interface specifies a way for applications/clients to share buffers.
-call GEM_FLINK with the handle of the buffer object to be shared.
- An uint32 name will be returned.
+Call GEM_FLINK with the handle of the buffer object to be shared.
+ A uint32 name will be returned.
-transfer this name to the clients that should access the buffer object
+Transfer this name to the clients that should access the buffer object.
-the remote clients should open the BO by name by using the GEM_OPEN IOCTL.
+The remote clients should open the BO by name, using the GEM_OPEN IOCTL.
By default, no buffers are shared between clients.
However, when one buffer is shared, any authenticated client can read/write
- to the BO.
+ the BO.
No access control is done between authenticated clients.
-A client is said to be authenticated if his euid is 0 (root) or if an already-au
+A client is said to be authenticated if its euid is 0 (root) or if an already-au
thenticated client added this client to the authenticated-clients list.
@@ -5619,16 +5619,16 @@ The procedure to authenticate a non-root client is:
-get a magic cookie from the dri interface (drm_getmagic)
+Get a magic cookie from the dri interface (drm_getmagic).
-send the magic cookie to an already-authenticated client
+Send the magic cookie to an already-authenticated client.
-the authenticated client calls drm_authmagic to authenticate the cookie
- and thus, the original client
+The authenticated client calls drm_authmagic to authenticate the cookie
+ and thus the original client.
@@ -5636,8 +5636,8 @@ Learning more about GEM
-The best documentation for GEM is the source code the drivers exposing it
- (libdrm for the userspace, the drm driver for the kernelspace).
+The best documentation for GEM is the source code of the drivers exposing
+ it (libdrm for userspace, the drm driver for kernelspace).
However, it is worth reading the initial proposal called
\begin_inset CommandInset href
@@ -5665,9 +5665,9 @@ DMA-Buf is a driver-independent buffer-sharing mechanism for clients.
-Contrarily to GEM buffer sharing, a fd is returned to the client willing
+Unlike GEM buffer sharing, with DMA-Buf a fd is returned to the client willing
to export a buffer.
- It is then the client's responsability to export this fd to the other clients
+ It is then the client's responsibility to export this fd to the other clients
using a UNIX socket as explained by this
\begin_inset CommandInset href
@@ -5677,16 +5677,15 @@ target "http://archives.neohapsis.com/archives/postfix/2000-09/1476.html"
- This sharing solution is more secure since clients cannot access to buffers
- unless explicitely allowed by the exporter contrarily to GEM where names
- are guessable.
+ This sharing solution is more secure since clients cannot access buffers
+ unless explicitly allowed by the exporter, whereas with GEM names are guessable.
-For more information, look at /Documentation/dma-buf-sharing.txt in your
- kernel tree.
+For more information, see /Documentation/dma-buf-sharing.txt in your kernel