summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/renderonly/renderonly.h
Commit message (Collapse)AuthorAgeFilesLines
* renderonly/etnaviv: stop importing resource from renderonlyLucas Stach2017-07-191-10/+10
| | | | | | | | | | | 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: drop resources on destroyPhilipp Zabel2017-05-021-1/+2
| | | | | | | | | | | | | 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]>
* gallium: add renderonly libraryChristian Gmeiner2017-01-121-0/+109
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]>