| Age | Commit message (Collapse) | Author |
|---|
|
Add a flag allowing Nouveau to specify that an object should be coherent
at allocation time. This is required for some class of objects like
fences which are randomly-accessed by both the CPU and GPU. This flag
instructs the kernel driver to make sure the object remains coherent
even on architectures for which coherency is not guaranteed by the bus.
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
|
|
|
|
|
|
This commit encompasses the changes necessary to run on top of the 0.0.16
nouveau interface, additional APIs to support the new features of the
interface, as well as code from Luca Barbieri to improve the pushbuf
interface, which just happens to break nouveau's libdrm ABI so was delayed
until now.
API changes as a result of 0.0.16 DRM interface:
1. No more bo_pin()/bo_unpin(), these were only there for UMS and we no
longer support it.
2. Any random nouveau_bo can be submitted to the GPU as a push buffer.
3. Relocations can be applied on any nouveau_bo
This patch changes the pushbuffer ABI to:
1. No longer use/expose nouveau_pushbuffer. Everything is directly
in nouveau_channel. This saves the extra "pushbuf" pointer dereference.
2. Use cur/end pointers instead of tracking the remaining size.
Pushing data now only needs to alter cur and not both cur and remaining.
The goal is to make the *_RING macros faster and make the interface simpler
and cleaner in the process.
The *_RING APIs are unchanged, but those are inlined and the ABI is changed.
Also, anything accessing pushbuf->remaining instead of using AVAIL_RING
will need to be fixed.
|
|
|
|
The nouveau_drmif.h is not the Nouveau DRM kernel ABI file, but purely
user space stuff. Remove it, it does not belong in include/drm/.
Copy the right header from Nouveau kernel v2.6.31-rc9-757-gaca551c.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
