Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <!4902>

Most of these will never actually be compiled by windows, but in the
interest of being able to make using struct foo = {}; an error and
avoiding breaking windows removing a handful of safe uses seems like a
good trade off.

Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Acked-by: Eric Engestrom <eric.engestrom@intel.com>

To make PIPE_FORMATs usable from non-gallium parts of Mesa, I want to
move their helpers out of gallium.  Since u_format used
util_copy_rect(), I moved that in there, too.

I've put it in a separate directory in util/ because it's a big chunk
of related code, and it's not clear to me whether we might want it as
a separate library from libmesa_util at some point.

Closes: #1905


Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>

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 <marcandre.lureau@gmail.com>
(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 <marek.olsak@amd.com>

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: 848b49b2

 ("gallium: add renderonly library")
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>

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 <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>

Emma Anholt authored May 09, 2017 and Christian Gmeiner committed May 15, 2017

vc4 was rejecting renderonly's import, because the offset field was
nonzero.

Fixes: 848b49b2

 ("gallium: add renderonly library")
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Philipp Zabel authored Apr 28, 2017 and Christian Gmeiner committed May 02, 2017

To restart interrupted system calls, use drmIoctl.

Fixes: 848b49b2

 ("gallium: add renderonly library")
CC: <mesa-stable@lists.freedesktop.org>
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Philipp Zabel authored Apr 27, 2017 and Christian Gmeiner committed May 02, 2017

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: 848b49b2

 ("gallium: add renderonly library")
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Philipp Zabel authored Apr 27, 2017 and Christian Gmeiner committed May 02, 2017

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: 848b49b2

 ("gallium: add renderonly library")
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Christian Gmeiner authored Dec 23, 2016 and Emil Velikov committed Jan 12, 2017

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 <christian.gmeiner@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>