| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Only radeonsi uses them, so adjust them to match its needs.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This just renames this as we want to add an shm handle which
isn't really drm related.
Originally by: Marc-André Lureau <[email protected]>
(airlied: I used this sed script instead)
This was generated with:
git grep -l 'DRM_API_' | xargs sed -i 's/DRM_API_/WINSYS_/g'
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Take into account the resource format, instead of applying a hardcoded
32bpp. This not only over-allocates 16bpp formats, but also results in
a wrong stride being filled into the handle.
Fixes: 848b49b288f ("gallium: add renderonly library")
CC: <[email protected]>
Signed-off-by: Lucas Stach <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
The current way of importing the resource from renderonly after allocation
is opaque and is taking away control from the driver, which it needs in
order to implement more advanced scenarios than the simple linear scanout
with matching stride alignments.
Signed-off-by: Lucas Stach <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
Acked-by: Daniel Stone <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Note that for requests for Prime FDs or flink names, we return handles to
the etanviv BO, not the scanout BO. This is at least better than previous
behavior of returning GEM handles for a request for an FD or flink name.
And add an assert that renderonly_get_handle is only used for getting the
GEM handle.
Signed-off-by: Eric Anholt <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
vc4 was rejecting renderonly's import, because the offset field was
nonzero.
Fixes: 848b49b288f ("gallium: add renderonly library")
Cc: [email protected]
Signed-off-by: Eric Anholt <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
To restart interrupted system calls, use drmIoctl.
Fixes: 848b49b288f ("gallium: add renderonly library")
CC: <[email protected]>
Suggested-by: Emil Velikov <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The renderonly_scanout holds a reference on its prime pipe resource,
which should be released when it is destroyed. If it was created by
renderonly_create_kms_dumb_buffer_for_resource, the dumb BO also has
to be destroyed.
Fixes: 848b49b288f ("gallium: add renderonly library")
CC: <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
prime_fd is only used to transfer the scanout buffer to the GPU inside
renderonly_create_kms_dumb_buffer_for_resource. It should be closed
immediately to avoid leaking the DMA-BUF file handle.
Fixes: 848b49b288f ("gallium: add renderonly library")
CC: <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
|
|
|
This a very lightweight library to add basic support for renderonly
GPUs. A kms gallium driver must specify how a renderonly_scanout
objects gets created. Also it must provide file handles to the used
kms device and the used gpu device.
This could look like:
struct renderonly ro = {
.create_for_resource = renderonly_create_gpu_import_for_resource,
.kms_fd = fd,
.gpu_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC)
};
The renderonly_scanout object exits for two reasons:
- Do any special treatment for a scanout resource like importing the
GPU resource into the scanout hw.
- Make it easier for a gallium driver to detect if anything special
needs to be done in flush_resource(..) like a resolve to linear.
A GPU gallium driver which gets used as renderonly GPU needs to be
aware of the renderonly library.
This library will likely break android support and hopefully will get
replaced with a better solution based on gbm2.
Changes from V1 -> V2:
- reworked the lifecycle of renderonly object (suggested by Nicolai Hähnle)
- killed the midlayer (suggested by Thierry Reding)
- made the API more explicit regarding gpu and kms fd's
- added some docs
Signed-off-by: Christian Gmeiner <[email protected]>
Acked-by: Emil Velikov <[email protected]>
Tested-by: Alexandre Courbot <[email protected]>
|
