aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/renderonly
Commit message (Collapse)AuthorAgeFilesLines
* gallium/winsys: rename DRM_API_HANDLE_* to WINSYS_HANDLE_*Dave Airlie2018-05-302-3/+3
| | | | | | | | | | | | 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]>
* renderonly: fix dumb BO allocation for non 32bpp formatsLucas Stach2018-02-011-1/+2
| | | | | | | | | | | | 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]>
* renderonly/etnaviv: stop importing resource from renderonlyLucas Stach2017-07-192-48/+24
| | | | | | | | | | | 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]>
* etnaviv: Only use renderonly_get_handle for GEM handles.Eric Anholt2017-06-151-0/+1
| | | | | | | | | | | | 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]>
* renderonly: Initialize fields of struct winsys_handle.Eric Anholt2017-05-151-0/+1
| | | | | | | | | | 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]>
* renderonly: use drmIoctlPhilipp Zabel2017-05-021-4/+3
| | | | | | | | | | | 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]>
* renderonly: drop resources on destroyPhilipp Zabel2017-05-022-2/+12
| | | | | | | | | | | | | 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]>
* renderonly: close transfer prime_fdPhilipp Zabel2017-05-021-0/+2
| | | | | | | | | | | | 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]>
* gallium: add renderonly libraryChristian Gmeiner2017-01-122-0/+284
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]>