Re: [Mesa-dev] Android + tegra + mesa

[Thierry Reding]

On Fri, Jan 18, 2019 at 01:26:30PM +0300, Artyom Bambalov wrote:
> Do you have some notes on how to reproduce your setup? I've been meaning
> to try this out but never found enough time to see it through. Having a
> set of simple instructions for getting this built and booted would help
> reproduce the behavior and debug.
> 
> My device is xiaomi mipad 1(codename is mocha). It's similar with with
> shieldtablet(tn8), but uses different lcd panel, pmic(tps65913 like in t114
> instead of as3xxx) and some other secondary hardware. 
> My device tree(lineage-16.0 branch): https://github.com/art/
> android_device_xiaomi_mocha_mainline
> My kernel(android-4.19_mocha-changes branch): https://github.com/Insei/linux
> 
> 
> 
> That said, it looks like you've got a completely white display, which
> usually means that you're getting page faults from the SMMU, so maybe
> that'd be an interesting place to look at. You should be seeing errors
> from the SMMU in the kernel log in that case.
> 
> The display can be white or black. It depends on real picture color. 
> 
> 
> 
> There was a brief period where the SMMU wasn't working properly with
> Nouveau, which could be related to this, especially since it was around
> the timeframe of 4.19. That issue was fixed with this commit:
> 
> b59fb482b522 ("drm/nouveau: tegra: Detach from ARM DMA/IOMMU
> mapping")
> 
> which was merged into v4.19, but maybe it's not in the tree from Google
> that you're using (for whatever reason).
> 
> Come to think of it, that wouldn't really explain the white display,
> though, since that usually happens on SMMU faults for reads by the
> display controller. In any case, the kernel log would hopefully contain
> some clues as to what could be wrong.
> 
> Thierry
> 
> 
> I attached dmesg. It contains pretty much nouveau errors. 
[...]
> [  202.341300] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.341332] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.341359] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.341383] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 17e0 data 001e
> [  202.341418] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.341453] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.341476] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.341499] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 17e0 data 001e
> [  202.415128] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.415162] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.415188] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 0d78 data 0004
> [  202.415213] nouveau 5700.gpu: gr: DATA_ERROR 009c [] ch 6 
> [0400441000 RenderThread[924]] subc 0 class a297 mthd 17e0 data 001e

These errors certainly look like something's wrong with the IOMMU. Can
you post the contents of this:

$ ls -l /sys/class/iommu/70019000.memory-controller/devices

from your system?

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Android + tegra + mesa

[Thierry Reding]

On Fri, Jan 18, 2019 at 12:28:07AM +0300, Artyom Bambalov wrote:
> Hello, guys. I have device with tegra K1(T124). I try to get open source
> graphical stack. What I use: mesa 3d(18.2-19.0), libdrm(2.4.96),
> drm_hwcomposer(the latest), gbm_gralloc(the latest), 4.19 kernel by
> google(tegra drm + nouveau). What I get: normal bootanimatin, but the
> system UI is not displaying properly(look at pinned picture). I also tested
> the kernel with linux distr and all works fine. So, I wanted to ask is it
> possible to get a normal picture on android with nouveau on tegra K1(T124)?

Do you have some notes on how to reproduce your setup? I've been meaning
to try this out but never found enough time to see it through. Having a
set of simple instructions for getting this built and booted would help
reproduce the behavior and debug.

That said, it looks like you've got a completely white display, which
usually means that you're getting page faults from the SMMU, so maybe
that'd be an interesting place to look at. You should be seeing errors
from the SMMU in the kernel log in that case.

There was a brief period where the SMMU wasn't working properly with
Nouveau, which could be related to this, especially since it was around
the timeframe of 4.19. That issue was fixed with this commit:

b59fb482b522 ("drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping")

which was merged into v4.19, but maybe it's not in the tree from Google
that you're using (for whatever reason).

Come to think of it, that wouldn't really explain the white display,
though, since that usually happens on SMMU faults for reads by the
display controller. In any case, the kernel log would hopefully contain
some clues as to what could be wrong.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] meson: add missing tegra vdpau driver

[Thierry Reding]

On Tue, Dec 18, 2018 at 11:34:31AM -0800, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-12-18 09:43:18)
> > 
> > 
> > On December 18, 2018 5:36:19 PM UTC, Dylan Baker  
> > wrote:
> > > Quoting Ilia Mirkin (2018-12-06 09:39:25)
> > > > On Thu, Dec 6, 2018 at 12:17 PM Eric Engestrom
> > >  wrote:
> > > > >
> > > > > On Thursday, 2018-12-06 12:07:06 -0500, Ilia Mirkin wrote:
> > > > > > Under what circumstances would tegra have a vdpau
> > > implementation?
> > > > >
> > > > > I don't know about that, but this patch brings meson on par with
> > > > > autotools. Are you saying autotools was wrong and it should be
> > > removed
> > > > > there instead?
> > > > >
> > > > > FtR, src/gallium/targets/vdpau/Makefile.am includes
> > > > > src/gallium/drivers/tegra/Automake.inc which adds tegra to the
> > > > > TARGET_DRIVERS, which in turn produces libvdpau_tegra.so
> > > > >
> > > > > If this was wrong, then that include on line 60 of
> > > > > src/gallium/targets/vdpau/Makefile.am should be removed.
> > > > >
> > > > > This line was added by Thierry Reding (cc'ed) when he first
> > > introduced
> > > > > tegra support in 1755f608f5201e0a23f00 "tegra: Initial support".
> > > > 
> > > > I'd like to hear tagr opine on this, but AFAIK tegra is a
> > > > renderonly-style driver, which uses nouveau as its actual rendering
> > > > backend. While nouveau does support VDPAU, the decoding engines are
> > > > not available as part of the GPU device on Tegra platforms. They
> > > still
> > > > have decoders, they're just separate platform devices (which I
> > > suspect
> > > > operate very similarly to their desktop GPU counterparts, but that's
> > > a
> > > > separate matter).
> > > > 
> > > >   -ilia
> > > 
> > > Ping?
> > 
> > I suggest we land this patch to bring meson on par with autotools, and if 
> > we decide later
> > that autotools was wrong, we can just remove it from both places at once; 
> > ack?
> 
> I'd vote lets at least give Thierry till tomorrow to respond, and we can merge
> it tomorrow around this time if he hasn't, with the remove fallback if tegra
> shouldn't have a vdpau module? Does that sound reasonable to everyone?

Sorry, I completely missed this. Ilia is right, Tegra doesn't have any
decoding engines in the GPU. Ilia is also correct that the engines are
separate devices and similar to their desktop GPU counterparts. While
it'd technically be possible to somehow enable video decoding in the
Tegra gallium driver (I had done some prototyping on this a while ago),
it doesn't look like the best option at this point. The problem is that
gallium makes a bunch of assumptions that just don't apply to Tegra.

At this point, it seems more likely that video decoding will be
implemented as V4L2 memory-to-memory drivers.

So I think we should just remove the vdpau support for Tegra from the
autotools build. It's completely non-functional and there are no plans
to make it work.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [1/3] tegra: Remove usage of non-stable UAPI

[Thierry Reding]

On Tue, May 29, 2018 at 12:46:35PM +0200, Daniel Kolesa wrote:
> Hello,
> 
> On 2018/04/19 18:31, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > This code path is no longer required with framebuffer modifier support.
> 
> This patch series fixes Xorg 1.20 startup (since 1.20, it does not modeset
> with upstream Mesa tegra driver unless xserver commit c8c276c9 is reverted)
> as well as the need to revert a patch in the upstream kernel (4ae4b5c0) at
> very least on my Tegra X1 device, therefore:
> 
> Tested-by: Daniel Kolesa 
> 
> It looks to me like a bugfix series, can this get in an 18.1 bugfix release
> or will it have to wait for 18.2?

I've pushed these to the master branch with your Tested-by and a Cc:
mesa-stable tag, so they should find their way into a bugfix release.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] tegra: Fix scanout resources without modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Resources created for scanout but without modifiers need to be treated
as pitch-linear. This is because applications that don't use modifiers
to create resources must be assumed to not understand modifiers and in
turn won't be able to create a DRM framebuffer and passing along which
modifiers were picked by the implementation.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/tegra/tegra_screen.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/tegra/tegra_screen.c 
b/src/gallium/drivers/tegra/tegra_screen.c
index 41bf2052f945..8b61c0901600 100644
--- a/src/gallium/drivers/tegra/tegra_screen.c
+++ b/src/gallium/drivers/tegra/tegra_screen.c
@@ -260,6 +260,7 @@ tegra_screen_resource_create(struct pipe_screen *pscreen,
  const struct pipe_resource *template)
 {
struct tegra_screen *screen = to_tegra_screen(pscreen);
+   uint64_t modifier = DRM_FORMAT_MOD_INVALID;
struct tegra_resource *resource;
int err;
 
@@ -267,7 +268,23 @@ tegra_screen_resource_create(struct pipe_screen *pscreen,
if (!resource)
   return NULL;
 
-   resource->gpu = screen->gpu->resource_create(screen->gpu, template);
+   /*
+* Applications that create scanout resources without modifiers are very
+* unlikely to support modifiers at all. In that case the resources need
+* to be created with a pitch-linear layout so that they can be properly
+* shared with scanout hardware.
+*
+* Technically it is possible for applications to create resources without
+* specifying a modifier but still query the modifier associated with the
+* resource (e.g. using gbm_bo_get_modifier()) before handing it to the
+* framebuffer creation API (such as the DRM_IOCTL_MODE_ADDFB2 IOCTL).
+*/
+   if (template->bind & PIPE_BIND_SCANOUT)
+  modifier = DRM_FORMAT_MOD_LINEAR;
+
+   resource->gpu = screen->gpu->resource_create_with_modifiers(screen->gpu,
+   template,
+   , 1);
if (!resource->gpu)
   goto free;
 
-- 
2.16.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] tegra: Remove usage of non-stable UAPI

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This code path is no longer required with framebuffer modifier support.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/tegra/tegra_screen.c | 69 ++--
 1 file changed, 3 insertions(+), 66 deletions(-)

diff --git a/src/gallium/drivers/tegra/tegra_screen.c 
b/src/gallium/drivers/tegra/tegra_screen.c
index 669f22a19449..41bf2052f945 100644
--- a/src/gallium/drivers/tegra/tegra_screen.c
+++ b/src/gallium/drivers/tegra/tegra_screen.c
@@ -219,11 +219,9 @@ free:
 }
 
 static int tegra_screen_import_resource(struct tegra_screen *screen,
-struct tegra_resource *resource,
-bool has_modifiers)
+struct tegra_resource *resource)
 {
unsigned usage = PIPE_HANDLE_USAGE_READ;
-   struct drm_tegra_gem_set_tiling args;
struct winsys_handle handle;
boolean status;
int fd, err;
@@ -254,67 +252,6 @@ static int tegra_screen_import_resource(struct 
tegra_screen *screen,
 
close(fd);
 
-   if (!has_modifiers) {
-  memset(, 0, sizeof(args));
-  args.handle = resource->handle;
-
-  switch (handle.modifier) {
- case DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_TILED;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 0;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 1;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 2;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 3;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 4;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 5;
-break;
-
- default:
-debug_printf("unsupported modifier %" PRIx64 ", assuming linear\n",
- handle.modifier);
-/* fall-through */
-
- case DRM_FORMAT_MOD_LINEAR:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_PITCH;
-break;
-  }
-
-  err = drmIoctl(screen->fd, DRM_IOCTL_TEGRA_GEM_SET_TILING, );
-  if (err < 0) {
- fprintf(stderr, "failed to set tiling parameters: %s\n",
- strerror(errno));
- err = -errno;
- goto out;
-  }
-   }
-
-   return 0;
-
-out:
return err;
 }
 
@@ -336,7 +273,7 @@ tegra_screen_resource_create(struct pipe_screen *pscreen,
 
/* import scanout buffers for display */
if (template->bind & PIPE_BIND_SCANOUT) {
-  err = tegra_screen_import_resource(screen, resource, false);
+  err = tegra_screen_import_resource(screen, resource);
   if (err < 0)
  goto destroy;
}
@@ -575,7 +512,7 @@ tegra_screen_resource_create_with_modifiers(struct 
pipe_screen *pscreen,
if (!resource->gpu)
   goto free;
 
-   err = tegra_screen_import_resource(screen, resource, true);
+   err = tegra_screen_import_resource(screen, resource);
if (err < 0)
   goto destroy;
 
-- 
2.16.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] tegra: Treat resources with modifiers as scanout

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Resources created with modifiers are treated as scanout because there is
no way for applications to specify the usage (though that capability may
be useful to have in the future). Currently all the resources created by
applications with modifiers are for scanout, so make sure they have bind
flags set accordingly.

This is necessary in order to properly export buffers for such resources
so that they can be shared with scanout hardware.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/tegra/tegra_screen.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/tegra/tegra_screen.c 
b/src/gallium/drivers/tegra/tegra_screen.c
index 8b61c0901600..e03e71f81a2a 100644
--- a/src/gallium/drivers/tegra/tegra_screen.c
+++ b/src/gallium/drivers/tegra/tegra_screen.c
@@ -515,6 +515,7 @@ tegra_screen_resource_create_with_modifiers(struct 
pipe_screen *pscreen,
 int count)
 {
struct tegra_screen *screen = to_tegra_screen(pscreen);
+   struct pipe_resource tmpl = *template;
struct tegra_resource *resource;
int err;
 
@@ -522,8 +523,18 @@ tegra_screen_resource_create_with_modifiers(struct 
pipe_screen *pscreen,
if (!resource)
   return NULL;
 
+   /*
+* Assume that resources created with modifiers will always be used for
+* scanout. This is necessary because some of the APIs that are used to
+* create resources with modifiers (e.g. gbm_bo_create_with_modifiers())
+* can't pass along usage information. Adding that capability might be
+* worth adding to remove this ambiguity. Not all future use-cases that
+* involve modifiers may always be targetting scanout hardware.
+*/
+   tmpl.bind |= PIPE_BIND_SCANOUT;
+
resource->gpu = screen->gpu->resource_create_with_modifiers(screen->gpu,
-   template,
+   ,
modifiers,
count);
if (!resource->gpu)
-- 
2.16.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH kmscube 3/4] Automatically select modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

If available, use the formats/modifiers blob from a DRM/KMS device to
automatically detect which modifiers to use. In the absence of the blob,
leave it up to the implementation to choose an appropriate format.

Based on work by Lucas Stach <l.st...@pengutronix.de>.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 common.c | 10 +
 common.h |  2 +-
 drm-atomic.c | 70 +++-
 drm-common.h |  5 -
 kmscube.c|  8 +--
 5 files changed, 86 insertions(+), 9 deletions(-)

diff --git a/common.c b/common.c
index 3dcd9bd3d8f4..a886962ea7b1 100644
--- a/common.c
+++ b/common.c
@@ -41,17 +41,19 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
   const uint64_t *modifiers,
   const unsigned int count);
 
-const struct gbm * init_gbm(const struct drm *drm, uint64_t modifier)
+const struct gbm * init_gbm(const struct drm *drm)
 {
gbm.dev = gbm_create_device(drm->fd);
gbm.format = GBM_FORMAT_XRGB;
 
-   if (gbm_surface_create_with_modifiers) {
+   if (gbm_surface_create_with_modifiers && drm->num_modifiers > 0) {
gbm.surface = gbm_surface_create_with_modifiers(gbm.dev,
drm->mode->hdisplay, drm->mode->vdisplay,
-   gbm.format, , 1);
+   gbm.format, drm->modifiers,
+   drm->num_modifiers);
} else {
-   if (modifier != DRM_FORMAT_MOD_LINEAR) {
+   if (drm->num_modifiers > 0 &&
+   drm->modifiers[0] != DRM_FORMAT_MOD_LINEAR) {
fprintf(stderr, "Modifiers requested but support isn't 
available\n");
return NULL;
}
diff --git a/common.h b/common.h
index 8ff1ed3a6aa3..bed316786557 100644
--- a/common.h
+++ b/common.h
@@ -84,7 +84,7 @@ struct gbm {
 };
 
 struct drm;
-const struct gbm *init_gbm(const struct drm *drm, uint64_t modifier);
+const struct gbm *init_gbm(const struct drm *drm);
 
 struct egl {
EGLDisplay display;
diff --git a/drm-atomic.c b/drm-atomic.c
index 99ac33d6a686..a68f036a9aab 100644
--- a/drm-atomic.c
+++ b/drm-atomic.c
@@ -337,7 +337,66 @@ static int get_plane_id(void)
return ret;
 }
 
-const struct drm * init_drm_atomic(const char *device)
+static unsigned int
+get_modifiers(drmModePropertyBlobPtr blob, struct drm_format_modifier **modsp)
+{
+   struct drm_format_modifier_blob *data = blob->data;
+
+   *modsp = blob->data + data->modifiers_offset;
+
+   return data->count_modifiers;
+}
+
+static int
+drm_atomic_get_modifiers(struct drm *drm)
+{
+   unsigned int i, j, format_index = 0;
+
+   for (i = 0; i < drm->plane->plane->count_formats; i++) {
+   if (drm->plane->plane->formats[i] == DRM_FORMAT_XRGB)
+   format_index = i;
+   }
+
+   for (i = 0; i < drm->plane->props->count_props; i++) {
+   if (!strcmp(drm->plane->props_info[i]->name, "IN_FORMATS")) {
+   struct drm_format_modifier *mods;
+   drmModePropertyBlobPtr blob;
+   unsigned int count;
+
+   blob = drmModeGetPropertyBlob(drm->fd,
+ 
drm->plane->props->prop_values[i]);
+   if (!blob) {
+   printf("failed to get blob for property %s\n",
+  drm->plane->props_info[i]->name);
+   return -ENOMEM;
+   }
+
+   count = get_modifiers(blob, );
+
+   for (j = 0; j < count; j++) {
+   if (mods[j].formats & (1ULL << format_index))
+   drm->num_modifiers++;
+   }
+
+   drm->modifiers = calloc(drm->num_modifiers,
+   sizeof(uint64_t));
+   if (!drm->modifiers) {
+   printf("failed to allocate modifiers\n");
+   return -ENOMEM;
+   }
+
+   for (j = 0; j < count; j++) {
+   if (mods[j].formats & (1ULL << format_index))
+   drm->modifiers[j] = mods[j].modifier;
+   }
+   }
+   }
+
+   return 0;
+}
+
+const struct drm *init_drm_atomic(const char *device, uint64_t *modifiers,
+ unsigned int 

[Mesa-dev] [PATCH kmscube 4/4] drm-atomic: Implement user interruption

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

In legacy mode, the user can interrupt kmscube by pressing the return
key. Implement the same behaviour for atomic mode.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 drm-atomic.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drm-atomic.c b/drm-atomic.c
index a68f036a9aab..30f978e1d873 100644
--- a/drm-atomic.c
+++ b/drm-atomic.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "common.h"
 #include "drm-common.h"
@@ -179,6 +180,8 @@ static int atomic_run(const struct gbm *gbm, const struct 
egl *egl)
struct drm_fb *fb;
uint32_t i = 0;
uint32_t flags = DRM_MODE_ATOMIC_NONBLOCK;
+   struct timeval timeout;
+   fd_set fds;
int ret;
 
if (egl_check(egl, eglDupNativeFenceFDANDROID) ||
@@ -274,6 +277,28 @@ static int atomic_run(const struct gbm *gbm, const struct 
egl *egl)
 
/* Allow a modeset change for the first commit only. */
flags &= ~(DRM_MODE_ATOMIC_ALLOW_MODESET);
+
+   /* watch for user interruption */
+   FD_ZERO();
+   FD_SET(0, );
+   memset(, 0, sizeof(timeout));
+
+   ret = select(1, , NULL, NULL, );
+   if (ret < 0) {
+   printf("select() failed: %s\n", strerror(errno));
+   break;
+   }
+
+   /*
+* select() will immediately timeout if there was no user
+* interrupt because of the 0 timeout. However, that's an
+* expected situation, not an error, so we just ignore it
+* here.
+*/
+   if (FD_ISSET(0, )) {
+   printf("user interrupted!\n");
+   break;
+   }
}
 
return ret;
-- 
2.16.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH kmscube 2/4] Pass struct drm to init_gbm()

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This helps cut down on the number of parameters that we need to pass
around. Subsequent patches will also add more data to struct drm that
init_gbm() needs to access, so passing in the struct make sure these
will be available.

Based on work by Lucas Stach <l.st...@pengutronix.de>.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 common.c  | 22 +++---
 common.h  |  4 ++--
 kmscube.c |  3 +--
 3 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/common.c b/common.c
index faecd4215039..3dcd9bd3d8f4 100644
--- a/common.c
+++ b/common.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "common.h"
+#include "drm-common.h"
 
 static struct gbm gbm;
 
@@ -40,25 +41,24 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
   const uint64_t *modifiers,
   const unsigned int count);
 
-const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier)
+const struct gbm * init_gbm(const struct drm *drm, uint64_t modifier)
 {
-   gbm.dev = gbm_create_device(drm_fd);
+   gbm.dev = gbm_create_device(drm->fd);
gbm.format = GBM_FORMAT_XRGB;
 
if (gbm_surface_create_with_modifiers) {
-   gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
-   gbm.format,
-   , 1);
-
+   gbm.surface = gbm_surface_create_with_modifiers(gbm.dev,
+   drm->mode->hdisplay, drm->mode->vdisplay,
+   gbm.format, , 1);
} else {
if (modifier != DRM_FORMAT_MOD_LINEAR) {
fprintf(stderr, "Modifiers requested but support isn't 
available\n");
return NULL;
}
-   gbm.surface = gbm_surface_create(gbm.dev, w, h,
-   gbm.format,
-   GBM_BO_USE_SCANOUT | 
GBM_BO_USE_RENDERING);
 
+   gbm.surface = gbm_surface_create(gbm.dev, drm->mode->hdisplay,
+   drm->mode->vdisplay, gbm.format,
+   GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING);
}
 
if (!gbm.surface) {
@@ -66,8 +66,8 @@ const struct gbm * init_gbm(int drm_fd, int w, int h, 
uint64_t modifier)
return NULL;
}
 
-   gbm.width = w;
-   gbm.height = h;
+   gbm.width = drm->mode->hdisplay;
+   gbm.height = drm->mode->vdisplay;
 
return 
 }
diff --git a/common.h b/common.h
index 898010dd546f..8ff1ed3a6aa3 100644
--- a/common.h
+++ b/common.h
@@ -83,8 +83,8 @@ struct gbm {
int width, height;
 };
 
-const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier);
-
+struct drm;
+const struct gbm *init_gbm(const struct drm *drm, uint64_t modifier);
 
 struct egl {
EGLDisplay display;
diff --git a/kmscube.c b/kmscube.c
index 87a4205ddc20..b05e57df7faf 100644
--- a/kmscube.c
+++ b/kmscube.c
@@ -130,8 +130,7 @@ int main(int argc, char *argv[])
return -1;
}
 
-   gbm = init_gbm(drm->fd, drm->mode->hdisplay, drm->mode->vdisplay,
-   modifier);
+   gbm = init_gbm(drm, modifier);
if (!gbm) {
printf("failed to initialize GBM\n");
return -1;
-- 
2.16.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH kmscube 1/4] drm-atomic: Fix indentation

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

One of the error returns ended up being indented twice. Fix it.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 drm-atomic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drm-atomic.c b/drm-atomic.c
index 82531d346d73..99ac33d6a686 100644
--- a/drm-atomic.c
+++ b/drm-atomic.c
@@ -116,7 +116,7 @@ static int drm_atomic_commit(uint32_t fb_id, uint32_t flags)
if (flags & DRM_MODE_ATOMIC_ALLOW_MODESET) {
if (add_connector_property(req, drm.connector_id, "CRTC_ID",
drm.crtc_id) < 0)
-   return -1;
+   return -1;
 
if (drmModeCreatePropertyBlob(drm.fd, drm.mode, 
sizeof(*drm.mode),
  _id) != 0)
-- 
2.16.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 6/6] autotools: Add tegra to AM_DISTCHECK_CONFIGURE_FLAGS

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This allows the driver to be built on a make distcheck and makes sure
that it properly builds when a distribution tarball is made.

Suggested-by: Emil Velikov <emil.veli...@collabora.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 5c3a6717d34e..de6921bf1fcb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -45,7 +45,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
--enable-libunwind \
--with-platforms=x11,wayland,drm,surfaceless \
--with-dri-drivers=i915,i965,nouveau,radeon,r200,swrast \
-   
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,swr,etnaviv,imx
 \
+   
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,tegra,virgl,swr,etnaviv,imx
 \
--with-vulkan-drivers=intel,radeon
 
 ACLOCAL_AMFLAGS = -I m4
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 5/6] tegra: Initial support

[Thierry Reding]

Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
But the GPU is a pure render node and has no display engine, hence the
scanout needs to happen on the Tegra display hardware. The GPU and the
display engine each have a separate DRM device node exposed by the
kernel.

To make the setup appear as a single device, this driver instantiates
a Nouveau screen with each instance of a Tegra screen and forwards GPU
requests to the Nouveau screen. For purposes of scanout it will import
buffers created on the GPU into the display driver. Handles that
userspace requests are those of the display driver so that they can be
used to create framebuffers.

This has been tested with some GBM test programs, as well as kmscube and
weston. All of those run without modifications, but I'm sure there is a
lot that can be improved.

Some fixes contributed by Hector Martin <mar...@marcan.st>.

Changes in v2:
- duplicate file descriptor in winsys to avoid potential issues
- require nouveau when building the tegra driver
- check for nouveau driver name on render node
- remove unneeded dependency on libdrm_tegra
- remove zombie references to libudev
- add missing headers to C_SOURCES variable
- drop unneeded tegra/ prefix for includes
- open device files with O_CLOEXEC
- update copyrights

Changes in v3:
- properly unwrap resources in ->resource_copy_region()
- support vertex buffers passed by user pointer
- allocate custom stream and const uploader
- silence error message on pre-Tegra124
- support X without explicit PRIME

Changes in v4:
- ship Meson build files in distribution tarball
- drop duplicate driver_tegra dependency

Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Reviewed-by: Dmitry Osipenko <dig...@gmail.com>
Reviewed-by: Dylan Baker <dy...@pnwbakers.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 configure.ac   |   12 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   14 +
 src/gallium/drivers/tegra/Makefile.sources |6 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1384 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  688 ++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   13 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   49 +
 26 files changed, 2770 insertions(+), 4 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

diff --git a/configure.ac b/configure.ac
index 172da6b443c6..40e7855994a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1357,7 +1357,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
 AC_ARG_WITH([gallium-drivers],
 [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
 [comma delimited Gallium drivers list, e.g.
-
"i915,nouveau,r300,r600,

[Mesa-dev] [PATCH v5 0/6] NVIDIA Tegra support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This series of patches implements initial support for Tegra. The first
two patches import DRM UAPI from v4.16-rc1 that provides framebuffer
modifiers that can be used to specify buffers shared between Nouveau
and the Tegra DRM driver.

Patches 3 and 4 add support for framebuffer modifiers to Nouveau and
patch 5 build on top of those to provide initial Tegra support in Mesa.
The current patches allow running common use-cases such as Wayland,
kmscube, etc.

Patch 6 adds the Tegra driver to the list of gallium drivers built
during a `make distcheck'.

Some people have been using earlier versions of these patches to run a
completely open-source graphics stack on various Tegra210 devices. I've
Cc'ed some of them so that they can provide feedback.

This series is also available in a git repository here:

https://cgit.freedesktop.org/~tagr/mesa #tegra-v5

Thierry

Thierry Reding (6):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers
  nouveau/nvc0: Extract common tile mode macro
  nouveau: Add framebuffer modifier support
  tegra: Initial support
  autotools: Add tegra to AM_DISTCHECK_CONFIGURE_FLAGS

 Makefile.am|2 +-
 configure.ac   |   12 +-
 include/drm-uapi/drm_fourcc.h  |   38 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/nouveau/Android.mk |3 +
 src/gallium/drivers/nouveau/Makefile.am|1 +
 src/gallium/drivers/nouveau/meson.build|4 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|   81 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c   |   59 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h   |   18 +-
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   14 +
 src/gallium/drivers/tegra/Makefile.sources |6 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1384 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  688 ++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   13 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   49 +
 34 files changed, 2946 insertions(+), 34 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 4/6] nouveau: Add framebuffer modifier support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This adds support for framebuffer modifiers to Nouveau. This will be
used by the Tegra driver to share metadata about the format of buffers
(such as the tiling mode or compression).

Changes in v2:
- remove unused parameters to nouveau_buffer_create()
- move format modifier query code to nvc0 backend
- restrict format modifiers to 2D textures
- implement ->query_dmabuf_modifiers()

Changes in v4:
- add UAPI include path on meson builds

Changes in v5:
- remove unnecessary includes

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/Android.mk   |  3 +
 src/gallium/drivers/nouveau/Makefile.am  |  1 +
 src/gallium/drivers/nouveau/meson.build  |  4 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  | 81 +++-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 59 -
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  3 +-
 6 files changed, 146 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/Android.mk 
b/src/gallium/drivers/nouveau/Android.mk
index 2de22e73ec18..a446774a86e8 100644
--- a/src/gallium/drivers/nouveau/Android.mk
+++ b/src/gallium/drivers/nouveau/Android.mk
@@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
$(NVC0_CODEGEN_SOURCES) \
$(NVC0_C_SOURCES)
 
+LOCAL_C_INCLUDES := \
+   $(MESA_TOP)/include/drm-uapi
+
 LOCAL_SHARED_LIBRARIES := libdrm_nouveau
 LOCAL_MODULE := libmesa_pipe_nouveau
 
diff --git a/src/gallium/drivers/nouveau/Makefile.am 
b/src/gallium/drivers/nouveau/Makefile.am
index 91547178e397..f6126b544811 100644
--- a/src/gallium/drivers/nouveau/Makefile.am
+++ b/src/gallium/drivers/nouveau/Makefile.am
@@ -24,6 +24,7 @@ include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CPPFLAGS = \
+   -I$(top_srcdir)/include/drm-uapi \
$(GALLIUM_DRIVER_CFLAGS) \
$(LIBDRM_CFLAGS) \
$(NOUVEAU_CFLAGS)
diff --git a/src/gallium/drivers/nouveau/meson.build 
b/src/gallium/drivers/nouveau/meson.build
index e44be2616e70..242ee0e0001b 100644
--- a/src/gallium/drivers/nouveau/meson.build
+++ b/src/gallium/drivers/nouveau/meson.build
@@ -207,7 +207,9 @@ files_libnouveau = files(
 libnouveau = static_library(
   'nouveau',
   [files_libnouveau],
-  include_directories : [inc_src, inc_include, inc_gallium, inc_gallium_aux],
+  include_directories : [
+inc_src, inc_include, inc_gallium, inc_gallium_aux, inc_drm_uapi
+  ],
   c_args : [c_vis_args],
   cpp_args : [cpp_vis_args],
   dependencies : [dep_libdrm, dep_libdrm_nouveau],
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 27674f72a7c0..7983c4030876 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -20,8 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
+
 #include "pipe/p_state.h"
 #include "pipe/p_defines.h"
+#include "state_tracker/drm_driver.h"
 #include "util/u_inlines.h"
 #include "util/u_format.h"
 
@@ -233,9 +236,79 @@ nvc0_miptree_init_layout_tiled(struct nv50_miptree *mt)
}
 }
 
+static uint64_t nvc0_miptree_get_modifier(struct nv50_miptree *mt)
+{
+   union nouveau_bo_config *config = >base.bo->config;
+   uint64_t modifier;
+
+   if (mt->layout_3d)
+  return DRM_FORMAT_MOD_INVALID;
+
+   switch (config->nvc0.memtype) {
+   case 0x00:
+  modifier = DRM_FORMAT_MOD_LINEAR;
+  break;
+
+   case 0xfe:
+  switch (NVC0_TILE_MODE_Y(config->nvc0.tile_mode)) {
+  case 0:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB;
+ break;
+
+  case 1:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB;
+ break;
+
+  case 2:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB;
+ break;
+
+  case 3:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB;
+ break;
+
+  case 4:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB;
+ break;
+
+  case 5:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB;
+ break;
+
+  default:
+ modifier = DRM_FORMAT_MOD_INVALID;
+ break;
+  }
+  break;
+
+   default:
+  modifier = DRM_FORMAT_MOD_INVALID;
+  break;
+   }
+
+   return modifier;
+}
+
+static boolean
+nvc0_miptree_get_handle(struct pipe_screen *pscreen,
+struct pipe_resource *pt,
+struct winsys_handle *whandle)
+{
+   struct nv50_miptree *mt = nv50_miptree(pt);
+   boolean ret;
+
+   ret = nv50_miptree_get_handle(pscreen, pt, whandle);
+   if (!ret)
+  return ret;
+
+   whandle->modifier = nvc0_miptree_get_modifier(mt);
+
+   return true;
+}
+
 const s

[Mesa-dev] [PATCH v5 2/6] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

This is based on commit 268892cb63a822315921a8dab48ac3e4abf7dd03 from
Linux v4.16-rc1.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index a76ed8f9e383..e04613d30a13 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -178,7 +178,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
-#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
@@ -338,29 +338,17 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
-/* NVIDIA Tegra frame buffer modifiers */
-
-/*
- * Some modifiers take parameters, for example the number of vertical GOBs in
- * a block. Reserve the lower 32 bits for parameters
- */
-#define __fourcc_mod_tegra_mode_shift 32
-#define fourcc_mod_tegra_code(val, params) \
-   fourcc_mod_code(NV, __u64)val) << __fourcc_mod_tegra_mode_shift) | 
params))
-#define fourcc_mod_tegra_mod(m) \
-   (m & ~((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
-#define fourcc_mod_tegra_param(m) \
-   (m & ((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
+/* NVIDIA frame buffer modifiers */
 
 /*
  * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
  *
  * Pixels are arranged in simple tiles of 16 x 16 bytes.
  */
-#define NV_FORMAT_MOD_TEGRA_TILED fourcc_mod_tegra_code(1, 0)
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
 
 /*
- * Tegra 16Bx2 Block Linear layout, used by TK1/TX1
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
  *
  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
@@ -380,7 +368,21 @@ extern "C" {
  * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
  * in full detail.
  */
-#define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+   fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+   fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+   fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+   fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+   fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x15)
 
 /*
  * Broadcom VC4 "T" format
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 3/6] nouveau/nvc0: Extract common tile mode macro

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Add a new macro that can be used to extract the tiling mode from a
tile_mode value. This is will be used to determine the number of GOBs
used in block linear mode.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
index 0d5f026d6e1c..c68a50948360 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
@@ -6,14 +6,17 @@
 
 #define NVC0_RESOURCE_FLAG_VIDEO (NOUVEAU_RESOURCE_FLAG_DRV_PRIV << 0)
 
+#define NVC0_TILE_MODE_X(m) (((m) >> 0) & 0xf)
+#define NVC0_TILE_MODE_Y(m) (((m) >> 4) & 0xf)
+#define NVC0_TILE_MODE_Z(m) (((m) >> 8) & 0xf)
 
-#define NVC0_TILE_SHIFT_X(m) m) >> 0) & 0xf) + 6)
-#define NVC0_TILE_SHIFT_Y(m) m) >> 4) & 0xf) + 3)
-#define NVC0_TILE_SHIFT_Z(m) m) >> 8) & 0xf) + 0)
+#define NVC0_TILE_SHIFT_X(m) (NVC0_TILE_MODE_X(m) + 6)
+#define NVC0_TILE_SHIFT_Y(m) (NVC0_TILE_MODE_Y(m) + 3)
+#define NVC0_TILE_SHIFT_Z(m) (NVC0_TILE_MODE_Z(m) + 0)
 
-#define NVC0_TILE_SIZE_X(m) (64 << (((m) >> 0) & 0xf))
-#define NVC0_TILE_SIZE_Y(m) ( 8 << (((m) >> 4) & 0xf))
-#define NVC0_TILE_SIZE_Z(m) ( 1 << (((m) >> 8) & 0xf))
+#define NVC0_TILE_SIZE_X(m) (64 << NVC0_TILE_MODE_X(m))
+#define NVC0_TILE_SIZE_Y(m) ( 8 << NVC0_TILE_MODE_Y(m))
+#define NVC0_TILE_SIZE_Z(m) ( 1 << NVC0_TILE_MODE_Z(m))
 
 /* it's ok to mask only in the end because max value is 3 * 5 */
 
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 1/6] drm/fourcc: Fix fourcc_mod_code() definition

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Avoid a compiler warnings when the val parameter is an expression.

This is based on commit 5843f4e02fbe86a59981e35adc6cabebee46fdc0 from
Linux v4.16-rc1.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index 3ad838d3f93f..a76ed8f9e383 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -188,7 +188,7 @@ extern "C" {
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
 
 #define fourcc_mod_code(vendor, val) \
-   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 
0x00ffULL))
 
 /*
  * Format Modifier tokens:
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 4/6] nouveau: Add framebuffer modifier support

[Thierry Reding]

On Wed, Mar 07, 2018 at 01:15:35PM -0500, Ilia Mirkin wrote:
> On Wed, Mar 7, 2018 at 10:53 AM, Thierry Reding
> <thierry.red...@gmail.com> wrote:
> > From: Thierry Reding <tred...@nvidia.com>
> >
> > This adds support for framebuffer modifiers to Nouveau. This will be
> > used by the Tegra driver to share metadata about the format of buffers
> > (such as the tiling mode or compression).
> >
> > Changes in v2:
> > - remove unused parameters to nouveau_buffer_create()
> > - move format modifier query code to nvc0 backend
> > - restrict format modifiers to 2D textures
> > - implement ->query_dmabuf_modifiers()
> >
> > Changes in v4:
> > - add UAPI include path on meson builds
> >
> > Acked-by: Emil Velikov <emil.veli...@collabora.com>
> > Tested-by: Andre Heider <a.hei...@gmail.com>
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  src/gallium/drivers/nouveau/Android.mk   |  3 +
> >  src/gallium/drivers/nouveau/Makefile.am  |  1 +
> >  src/gallium/drivers/nouveau/meson.build  |  4 +-
> >  src/gallium/drivers/nouveau/nouveau_screen.c |  4 ++
> >  src/gallium/drivers/nouveau/nv30/nv30_resource.c |  2 +
> >  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  | 81 
> > +++-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 59 -
> >  src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  3 +-
> >  8 files changed, 152 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/Android.mk 
> > b/src/gallium/drivers/nouveau/Android.mk
> > index 2de22e73ec18..a446774a86e8 100644
> > --- a/src/gallium/drivers/nouveau/Android.mk
> > +++ b/src/gallium/drivers/nouveau/Android.mk
> > @@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
> > $(NVC0_CODEGEN_SOURCES) \
> > $(NVC0_C_SOURCES)
> >
> > +LOCAL_C_INCLUDES := \
> > +   $(MESA_TOP)/include/drm-uapi
> > +
> >  LOCAL_SHARED_LIBRARIES := libdrm_nouveau
> >  LOCAL_MODULE := libmesa_pipe_nouveau
> >
> > diff --git a/src/gallium/drivers/nouveau/Makefile.am 
> > b/src/gallium/drivers/nouveau/Makefile.am
> > index 91547178e397..f6126b544811 100644
> > --- a/src/gallium/drivers/nouveau/Makefile.am
> > +++ b/src/gallium/drivers/nouveau/Makefile.am
> > @@ -24,6 +24,7 @@ include Makefile.sources
> >  include $(top_srcdir)/src/gallium/Automake.inc
> >
> >  AM_CPPFLAGS = \
> > +   -I$(top_srcdir)/include/drm-uapi \
> > $(GALLIUM_DRIVER_CFLAGS) \
> > $(LIBDRM_CFLAGS) \
> > $(NOUVEAU_CFLAGS)
> > diff --git a/src/gallium/drivers/nouveau/meson.build 
> > b/src/gallium/drivers/nouveau/meson.build
> > index e44be2616e70..242ee0e0001b 100644
> > --- a/src/gallium/drivers/nouveau/meson.build
> > +++ b/src/gallium/drivers/nouveau/meson.build
> > @@ -207,7 +207,9 @@ files_libnouveau = files(
> >  libnouveau = static_library(
> >'nouveau',
> >[files_libnouveau],
> > -  include_directories : [inc_src, inc_include, inc_gallium, 
> > inc_gallium_aux],
> > +  include_directories : [
> > +inc_src, inc_include, inc_gallium, inc_gallium_aux, inc_drm_uapi
> > +  ],
> >c_args : [c_vis_args],
> >cpp_args : [cpp_vis_args],
> >dependencies : [dep_libdrm, dep_libdrm_nouveau],
> > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
> > b/src/gallium/drivers/nouveau/nouveau_screen.c
> > index c144b39b2dd2..b84ef13ebe7f 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_screen.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
> > @@ -1,3 +1,5 @@
> > +#include 
> > +
> >  #include "pipe/p_defines.h"
> >  #include "pipe/p_screen.h"
> >  #include "pipe/p_state.h"
> > @@ -23,6 +25,8 @@
> >  #include "nouveau_mm.h"
> >  #include "nouveau_buffer.h"
> >
> > +#include "nvc0/nvc0_resource.h"
> 
> Pretty sure I've mentioned before that this was undesirable (and also
> seemingly unnecessary). Did you forget to fix it, or did you send the
> wrong version of the patch?

Ugh... yeah, looks like I ended up squashing the fix for this into a
patch unrelated to this series. Fixed for v5, sorry.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx/apple: Ship meson build file in tarball

[Thierry Reding]

On Wed, Mar 07, 2018 at 10:08:59AM -0800, Dylan Baker wrote:
> Quoting Thierry Reding (2018-03-07 07:55:37)
> > From: Thierry Reding <tred...@nvidia.com>
> > 
> > The meson build file for Apple GLX is not listed in the EXTRA_DIST make
> > variable and therefore isn't shipped as part of the release tarball, so
> > meson builds from the tarball will fail.
> > 
> > Add the file to EXTRA_DIST to ensure it is included in the tarball.
> > 
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  src/glx/apple/Makefile.am | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/glx/apple/Makefile.am b/src/glx/apple/Makefile.am
> > index bfa18b1c2f3d..8f9326863597 100644
> > --- a/src/glx/apple/Makefile.am
> > +++ b/src/glx/apple/Makefile.am
> > @@ -1,4 +1,6 @@
> > -EXTRA_DIST = RELEASE_NOTES
> > +EXTRA_DIST = \
> > +   RELEASE_NOTES \
> > +   meson.build
> >  
> >  noinst_LTLIBRARIES = libappleglx.la
> >  
> > -- 
> > 2.16.2
> > 
> 
> Is this in 18.0? If it is please either add a Fixes: tag or CC to stable.
> 
> Reviewed-by: Dylan Baker <dy...@pnwbakers.com>

This is only in master.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glx/apple: Ship meson build file in tarball

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The meson build file for Apple GLX is not listed in the EXTRA_DIST make
variable and therefore isn't shipped as part of the release tarball, so
meson builds from the tarball will fail.

Add the file to EXTRA_DIST to ensure it is included in the tarball.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/glx/apple/Makefile.am | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/glx/apple/Makefile.am b/src/glx/apple/Makefile.am
index bfa18b1c2f3d..8f9326863597 100644
--- a/src/glx/apple/Makefile.am
+++ b/src/glx/apple/Makefile.am
@@ -1,4 +1,6 @@
-EXTRA_DIST = RELEASE_NOTES
+EXTRA_DIST = \
+   RELEASE_NOTES \
+   meson.build
 
 noinst_LTLIBRARIES = libappleglx.la
 
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4 5/6] tegra: Initial support

[Thierry Reding]

Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
But the GPU is a pure render node and has no display engine, hence the
scanout needs to happen on the Tegra display hardware. The GPU and the
display engine each have a separate DRM device node exposed by the
kernel.

To make the setup appear as a single device, this driver instantiates
a Nouveau screen with each instance of a Tegra screen and forwards GPU
requests to the Nouveau screen. For purposes of scanout it will import
buffers created on the GPU into the display driver. Handles that
userspace requests are those of the display driver so that they can be
used to create framebuffers.

This has been tested with some GBM test programs, as well as kmscube and
weston. All of those run without modifications, but I'm sure there is a
lot that can be improved.

Some fixes contributed by Hector Martin <mar...@marcan.st>.

Changes in v2:
- duplicate file descriptor in winsys to avoid potential issues
- require nouveau when building the tegra driver
- check for nouveau driver name on render node
- remove unneeded dependency on libdrm_tegra
- remove zombie references to libudev
- add missing headers to C_SOURCES variable
- drop unneeded tegra/ prefix for includes
- open device files with O_CLOEXEC
- update copyrights

Changes in v3:
- properly unwrap resources in ->resource_copy_region()
- support vertex buffers passed by user pointer
- allocate custom stream and const uploader
- silence error message on pre-Tegra124
- support X without explicit PRIME

Changes in v4:
- ship Meson build files in distribution tarball
- drop duplicate driver_tegra dependency

Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Reviewed-by: Dmitry Osipenko <dig...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 configure.ac   |   12 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   14 +
 src/gallium/drivers/tegra/Makefile.sources |6 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1384 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  688 ++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   13 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   49 +
 26 files changed, 2770 insertions(+), 4 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

diff --git a/configure.ac b/configure.ac
index 172da6b443c6..40e7855994a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1357,7 +1357,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
 AC_ARG_WITH([gallium-drivers],
 [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
 [comma delimited Gallium drivers list, e.g.
-
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,vc4,vc5,virgl,etnaviv,imx

[Mesa-dev] [PATCH v4 1/6] drm/fourcc: Fix fourcc_mod_code() definition

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Avoid a compiler warnings when the val parameter is an expression.

This is based on commit 5843f4e02fbe86a59981e35adc6cabebee46fdc0 from
Linux v4.16-rc1.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index 3ad838d3f93f..a76ed8f9e383 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -188,7 +188,7 @@ extern "C" {
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
 
 #define fourcc_mod_code(vendor, val) \
-   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 
0x00ffULL))
 
 /*
  * Format Modifier tokens:
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4 6/6] autotools: Add tegra to AM_DISTCHECK_CONFIGURE_FLAGS

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This allows the driver to be built on a make distcheck and makes sure
that it properly builds when a distribution tarball is made.

Suggested-by: Emil Velikov <emil.veli...@collabora.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 5c3a6717d34e..de6921bf1fcb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -45,7 +45,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
--enable-libunwind \
--with-platforms=x11,wayland,drm,surfaceless \
--with-dri-drivers=i915,i965,nouveau,radeon,r200,swrast \
-   
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,swr,etnaviv,imx
 \
+   
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,tegra,virgl,swr,etnaviv,imx
 \
--with-vulkan-drivers=intel,radeon
 
 ACLOCAL_AMFLAGS = -I m4
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4 4/6] nouveau: Add framebuffer modifier support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This adds support for framebuffer modifiers to Nouveau. This will be
used by the Tegra driver to share metadata about the format of buffers
(such as the tiling mode or compression).

Changes in v2:
- remove unused parameters to nouveau_buffer_create()
- move format modifier query code to nvc0 backend
- restrict format modifiers to 2D textures
- implement ->query_dmabuf_modifiers()

Changes in v4:
- add UAPI include path on meson builds

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/Android.mk   |  3 +
 src/gallium/drivers/nouveau/Makefile.am  |  1 +
 src/gallium/drivers/nouveau/meson.build  |  4 +-
 src/gallium/drivers/nouveau/nouveau_screen.c |  4 ++
 src/gallium/drivers/nouveau/nv30/nv30_resource.c |  2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  | 81 +++-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 59 -
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  3 +-
 8 files changed, 152 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/Android.mk 
b/src/gallium/drivers/nouveau/Android.mk
index 2de22e73ec18..a446774a86e8 100644
--- a/src/gallium/drivers/nouveau/Android.mk
+++ b/src/gallium/drivers/nouveau/Android.mk
@@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
$(NVC0_CODEGEN_SOURCES) \
$(NVC0_C_SOURCES)
 
+LOCAL_C_INCLUDES := \
+   $(MESA_TOP)/include/drm-uapi
+
 LOCAL_SHARED_LIBRARIES := libdrm_nouveau
 LOCAL_MODULE := libmesa_pipe_nouveau
 
diff --git a/src/gallium/drivers/nouveau/Makefile.am 
b/src/gallium/drivers/nouveau/Makefile.am
index 91547178e397..f6126b544811 100644
--- a/src/gallium/drivers/nouveau/Makefile.am
+++ b/src/gallium/drivers/nouveau/Makefile.am
@@ -24,6 +24,7 @@ include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CPPFLAGS = \
+   -I$(top_srcdir)/include/drm-uapi \
$(GALLIUM_DRIVER_CFLAGS) \
$(LIBDRM_CFLAGS) \
$(NOUVEAU_CFLAGS)
diff --git a/src/gallium/drivers/nouveau/meson.build 
b/src/gallium/drivers/nouveau/meson.build
index e44be2616e70..242ee0e0001b 100644
--- a/src/gallium/drivers/nouveau/meson.build
+++ b/src/gallium/drivers/nouveau/meson.build
@@ -207,7 +207,9 @@ files_libnouveau = files(
 libnouveau = static_library(
   'nouveau',
   [files_libnouveau],
-  include_directories : [inc_src, inc_include, inc_gallium, inc_gallium_aux],
+  include_directories : [
+inc_src, inc_include, inc_gallium, inc_gallium_aux, inc_drm_uapi
+  ],
   c_args : [c_vis_args],
   cpp_args : [cpp_vis_args],
   dependencies : [dep_libdrm, dep_libdrm_nouveau],
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index c144b39b2dd2..b84ef13ebe7f 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -1,3 +1,5 @@
+#include 
+
 #include "pipe/p_defines.h"
 #include "pipe/p_screen.h"
 #include "pipe/p_state.h"
@@ -23,6 +25,8 @@
 #include "nouveau_mm.h"
 #include "nouveau_buffer.h"
 
+#include "nvc0/nvc0_resource.h"
+
 /* XXX this should go away */
 #include "state_tracker/drm_driver.h"
 
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_resource.c 
b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
index ff34f6e5f9fa..386bd3459bd3 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_resource.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
@@ -23,6 +23,8 @@
  *
  */
 
+#include 
+
 #include "util/u_format.h"
 #include "util/u_inlines.h"
 
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 27674f72a7c0..7983c4030876 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -20,8 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
+
 #include "pipe/p_state.h"
 #include "pipe/p_defines.h"
+#include "state_tracker/drm_driver.h"
 #include "util/u_inlines.h"
 #include "util/u_format.h"
 
@@ -233,9 +236,79 @@ nvc0_miptree_init_layout_tiled(struct nv50_miptree *mt)
}
 }
 
+static uint64_t nvc0_miptree_get_modifier(struct nv50_miptree *mt)
+{
+   union nouveau_bo_config *config = >base.bo->config;
+   uint64_t modifier;
+
+   if (mt->layout_3d)
+  return DRM_FORMAT_MOD_INVALID;
+
+   switch (config->nvc0.memtype) {
+   case 0x00:
+  modifier = DRM_FORMAT_MOD_LINEAR;
+  break;
+
+   case 0xfe:
+  switch (NVC0_TILE_MODE_Y(config->nvc0.tile_mode)) {
+  case 0:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB;
+ break;
+
+  case 1:
+ modifier = DRM_FORMAT_M

[Mesa-dev] [PATCH v4 3/6] nouveau/nvc0: Extract common tile mode macro

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Add a new macro that can be used to extract the tiling mode from a
tile_mode value. This is will be used to determine the number of GOBs
used in block linear mode.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
index 0d5f026d6e1c..c68a50948360 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
@@ -6,14 +6,17 @@
 
 #define NVC0_RESOURCE_FLAG_VIDEO (NOUVEAU_RESOURCE_FLAG_DRV_PRIV << 0)
 
+#define NVC0_TILE_MODE_X(m) (((m) >> 0) & 0xf)
+#define NVC0_TILE_MODE_Y(m) (((m) >> 4) & 0xf)
+#define NVC0_TILE_MODE_Z(m) (((m) >> 8) & 0xf)
 
-#define NVC0_TILE_SHIFT_X(m) m) >> 0) & 0xf) + 6)
-#define NVC0_TILE_SHIFT_Y(m) m) >> 4) & 0xf) + 3)
-#define NVC0_TILE_SHIFT_Z(m) m) >> 8) & 0xf) + 0)
+#define NVC0_TILE_SHIFT_X(m) (NVC0_TILE_MODE_X(m) + 6)
+#define NVC0_TILE_SHIFT_Y(m) (NVC0_TILE_MODE_Y(m) + 3)
+#define NVC0_TILE_SHIFT_Z(m) (NVC0_TILE_MODE_Z(m) + 0)
 
-#define NVC0_TILE_SIZE_X(m) (64 << (((m) >> 0) & 0xf))
-#define NVC0_TILE_SIZE_Y(m) ( 8 << (((m) >> 4) & 0xf))
-#define NVC0_TILE_SIZE_Z(m) ( 1 << (((m) >> 8) & 0xf))
+#define NVC0_TILE_SIZE_X(m) (64 << NVC0_TILE_MODE_X(m))
+#define NVC0_TILE_SIZE_Y(m) ( 8 << NVC0_TILE_MODE_Y(m))
+#define NVC0_TILE_SIZE_Z(m) ( 1 << NVC0_TILE_MODE_Z(m))
 
 /* it's ok to mask only in the end because max value is 3 * 5 */
 
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4 2/6] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

This is based on commit 268892cb63a822315921a8dab48ac3e4abf7dd03 from
Linux v4.16-rc1.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index a76ed8f9e383..e04613d30a13 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -178,7 +178,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
-#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
@@ -338,29 +338,17 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
-/* NVIDIA Tegra frame buffer modifiers */
-
-/*
- * Some modifiers take parameters, for example the number of vertical GOBs in
- * a block. Reserve the lower 32 bits for parameters
- */
-#define __fourcc_mod_tegra_mode_shift 32
-#define fourcc_mod_tegra_code(val, params) \
-   fourcc_mod_code(NV, __u64)val) << __fourcc_mod_tegra_mode_shift) | 
params))
-#define fourcc_mod_tegra_mod(m) \
-   (m & ~((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
-#define fourcc_mod_tegra_param(m) \
-   (m & ((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
+/* NVIDIA frame buffer modifiers */
 
 /*
  * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
  *
  * Pixels are arranged in simple tiles of 16 x 16 bytes.
  */
-#define NV_FORMAT_MOD_TEGRA_TILED fourcc_mod_tegra_code(1, 0)
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
 
 /*
- * Tegra 16Bx2 Block Linear layout, used by TK1/TX1
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
  *
  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
@@ -380,7 +368,21 @@ extern "C" {
  * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
  * in full detail.
  */
-#define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+   fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+   fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+   fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+   fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+   fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x15)
 
 /*
  * Broadcom VC4 "T" format
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4 0/6] NVIDIA Tegra support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This series of patches implements initial support for Tegra. The first
two patches import DRM UAPI from v4.16-rc1 that provides framebuffer
modifiers that can be used to specify buffers shared between Nouveau
and the Tegra DRM driver.

Patches 3 and 4 add support for framebuffer modifiers to Nouveau and
patch 5 build on top of those to provide initial Tegra support in Mesa.
The current patches allow running common use-cases such as Wayland,
kmscube, etc.

Patch 6 adds the Tegra driver to the list of gallium drivers built
during a `make distcheck'.

Some people have been using earlier versions of these patches to run a
completely open-source graphics stack on various Tegra210 devices. I've
Cc'ed some of them so that they can provide feedback.

This series is also available in a git repository here:

https://cgit.freedesktop.org/~tagr/mesa #tegra-v4

Thierry

Thierry Reding (6):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers
  nouveau/nvc0: Extract common tile mode macro
  nouveau: Add framebuffer modifier support
  tegra: Initial support
  autotools: Add tegra to AM_DISTCHECK_CONFIGURE_FLAGS

 Makefile.am|2 +-
 configure.ac   |   12 +-
 include/drm-uapi/drm_fourcc.h  |   38 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/nouveau/Android.mk |3 +
 src/gallium/drivers/nouveau/Makefile.am|1 +
 src/gallium/drivers/nouveau/meson.build|4 +-
 src/gallium/drivers/nouveau/nouveau_screen.c   |4 +
 src/gallium/drivers/nouveau/nv30/nv30_resource.c   |2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|   81 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c   |   59 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h   |   18 +-
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   14 +
 src/gallium/drivers/tegra/Makefile.sources |6 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1384 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  688 ++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   13 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   49 +
 36 files changed, 2952 insertions(+), 34 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] loader: Add support for platform and host1x busses

[Thierry Reding]

On Fri, Mar 02, 2018 at 01:31:22PM +, Emil Velikov wrote:
> On 2 March 2018 at 11:29, Thierry Reding <thierry.red...@gmail.com> wrote:
> > From: Thierry Reding <tred...@nvidia.com>
> >
> > ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
> > support for this bus in order to allow use of the DRI_PRIME environment
> > variable with those devices.
> >
> > While at it, also support the host1x bus, which is effectively the same
> > but uses an additional layer in the bus hierarchy.
> >
> > Note that it isn't enough to support the bus that has the rendering GPU
> > because the loader code will also try to construct an ID path tag for a
> > scanout-only device if it is the default that is being opened.
> >
> > The ID path tag for a device can be obtained by running udevadm info on
> > the device node, as shown in this example on NVIDIA Tegra:
> >
> > $ udevadm info /dev/dri/card0 | grep ID_PATH_TAG
> > E: ID_PATH_TAG=platform-5000_host1x
> >
> > The corresponding OF_FULLNAME property, from which the ID_PATH_TAG is
> > constructed, can be found in the sysfs "uevent" attribute for the card0
> > device's parent:
> >
> > $ grep OF_FULLNAME /sys/devices/platform/5000.host1x/drm/uevent
> > OF_FULLNAME=/host1x@5000
> >
> > Similarily, /dev/dri/card1 corresponds to the GPU:
> >
> > $ udevadm info /dev/dri/card1 | grep ID_PATH_TAG
> > E: ID_PATH_TAG=platform-5700_gpu
> >
> > and:
> >
> > $ grep OF_FULLNAME /sys/devices/platform/5700.gpu/uevent
> > OF_FULLNAME=/gpu@5700
> >
> > Changes in v2:
> > - avoid confusing pre-increment in strdup()
> > - add examples of tags to commit log
> >
> > Reviewed-by: Eric Engestrom <e...@engestrom.ch>
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> Smashing, thanks for the examples Thierry.
> 
> Reviewed-by: Emil Velikov <emil.veli...@collabora.com>

Thanks! Pushed to master.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 5/6] tegra: Initial support

[Thierry Reding]

On Thu, Mar 01, 2018 at 09:10:39AM -0800, Dylan Baker wrote:
> Quoting Thierry Reding (2018-03-01 05:54:53)
> > --- /dev/null
> > +++ b/src/gallium/winsys/tegra/drm/meson.build
> > @@ -0,0 +1,33 @@
> > +# Copyright © 2018 NVIDIA CORPORATION
> > +
> > +# Permission is hereby granted, free of charge, to any person obtaining a 
> > copy
> > +# of this software and associated documentation files (the "Software"), to 
> > deal
> > +# in the Software without restriction, including without limitation the 
> > rights
> > +# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> > +# copies of the Software, and to permit persons to whom the Software is
> > +# furnished to do so, subject to the following conditions:
> > +
> > +# The above copyright notice and this permission notice shall be included 
> > in
> > +# all copies or substantial portions of the Software.
> > +
> > +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> > THE
> > +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> > FROM,
> > +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
> > IN THE
> > +# SOFTWARE.
> > +
> > +libtegradrm = static_library(
> > +  'tegradrm',
> > +  'tegra_drm_winsys.c',
> > +  include_directories : [
> > +inc_include, inc_src, inc_gallium, inc_gallium_aux, 
> > inc_gallium_drivers,
> > +inc_gallium_winsys
> > +  ],
> > +)
> > +
> > +driver_tegra = declare_dependency(
> > +  compile_args : '-DGALLIUM_TEGRA',
> > +  link_with : libtegradrm,
> > +)
> 
> We don't need this driver_tegra, since the one in drivers/tegra is actually
> complete, right?
> 
> Dylan

Yeah, I think you're right. I don't remember why I added this. Let me
run some build tests without it.

Thanks,
Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/6] nouveau: Add framebuffer modifier support

[Thierry Reding]

On Fri, Mar 02, 2018 at 12:28:02PM +, Daniel Stone wrote:
> Hi,
> 
> On 2 March 2018 at 12:06, Thierry Reding <thierry.red...@gmail.com> wrote:
> > On Thu, Mar 01, 2018 at 09:37:28AM -0500, Ilia Mirkin wrote:
> >> > +static void
> >> > +nvc0_query_dmabuf_modifiers(struct pipe_screen *screen,
> >> > +enum pipe_format format, int max,
> >>
> >> Maybe change this to "unsigned max"? That would avoid unnecessary
> >> complications below to check if it's negative.
> >
> > I would like that very much, but I'm afraid it's probably too late to
> > change this now because the signedness is handed down directly from the
> > EGL_EXT_image_dma_buf_import_modifiers extension:
> >
> > 
> > https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
> >
> > Adding Pekka and Daniel for visibility, maybe there were reasons for why
> > these are explicitly signed. I'm not familiar with the process of
> > getting an extension changed, but, even though a very minor change, this
> > would be changing the API of a completed extension, which doesn't seem
> > like something that you're supposed to do.
> 
> The main reason was the precedent of, e.g., eglChooseConfig using
> EGLint. It's not ideal, but then again every time I type 'int i' these
> days I get a momentary shiver not knowing if it should be an unsigned
> int or not.

It also seems like EGL doesn't even define EGLuint, which would be a
good reason why everything is signed in the EGL API.

> > That said, the revision history of the extension mentions that revision
> > 4 introduced a new type for the modifiers, so perhaps there is some
> > leeway in what we can do.
> 
> r4 was made before the extension was actually finalised/used anywhere,
> so it's not really precedent.
> 
> > I guess we could always force a cast in dri2_query_dma_buf_modifiers()
> > if changing the extension is not possible. That way we could at least
> > internally not worry about the signedness.
> 
> If you think that'd make for a better Gallium interface, by all means
> please go for it, especially if it makes sense in the context of the
> rest of the Gallium API.

Yeah, I think it'd make sense. Gallium is already fairly consistently
using unsigned for values that can never be negative.

I was already halfway through the conversion when I noticed that this
comes originally from the EGL extension, so I'll wrap all of it into a
patch and send it out for review.

Thanks,
Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 5/6] tegra: Initial support

[Thierry Reding]

On Thu, Mar 01, 2018 at 09:41:37AM -0500, Ilia Mirkin wrote:
> Is this substantially different than the renderonly helper? i.e. could
> you reuse it somehow? (If not, that's fine too, just asking.)

Yeah, this is fairly different from renderonly in that it completely
wraps another driver. renderonly was derived from an earlier version of
this patch and simplified this by actually returning the GPU screen from
the scanout "frontend" driver. This requires changing the GPU driver to
know about a potential scanout engine because the GPU driver needs to
call into the scanout driver when creating resources in order for the
scanout driver to allocate or import the resources so that it is able to
scan them out.

This reversal makes things very simple, but at the same time limits the
flexibility because the "frontend" driver becomes essentially a slave to
the GPU driver. The other disadvantage is that the GPU driver needs to
be aware of the scanout part to make it all work.

Note that there are cases where this is absolutely fine. If all you care
about is passing buffers between scanout and render engines, renderonly
is good enough. Or if that's all you can do, then renderonly will do a
good job.

The wrapper driver has the same goal of making split scanout/render
setups behave as any other combined scanout/render setup, so that
applications don't have to be made aware of the split and encapsulate
the mechanism of how buffers are shared between GPU and scanout within
Mesa. But, in my opinion, there are some advantages to it: firstly, the
situation on Tegra is somewhat different from other SoCs in that the
same GPU driver (Nouveau) is also used on combined scanout/render
devices. So modifying it to talk to an external scanout engine seems a
little tacked on. Secondly, having a wrapper around Nouveau allows us to
implement policy specific to Tegra. For example, some formats or
modifiers may work well on a desktop GPU but perform very badly on
Tegra. The wrapper driver gives us more flexibility in filtering out
such combinations and exposing Tegra-specific capabilities if need be.
Thirdly we have a couple of other hardware units on Tegra that we may
want to use in a Mesa driver (such as VIC for image composition). These
units are not available to Nouveau, but via the host1x interface that is
accessed using the Tegra DRM device node. The wrapper driver makes it
easy to intercept some operations and redirect them to VIC if we know
that they will be better suited to its capabilities.

Technically we could reuse the renderonly helper, but we'd be limiting
ourselves to using Nouveau underneath. We'd also need to modify Nouveau
to become aware of non-GPU aspects of Tegra and we'd be unable to use
non-GPU hardware units to offload some operations. Those are all fairly
big restrictions, so the wrapper driver is the preferred solution.

> Also, will this work with the following code in nvc0_resource_fence
> (which I recently discovered does *not* play nice with the trace
> driver):
> 
>struct nvc0_screen *screen = nvc0_screen(res->base.screen);
> 
> i.e. will the resource's screen be the nvc0 screen or the tegra
> screen? [for resources passed into the nvc0 driver obviously]

Yes, this should work fine. I've occasionally seen crashes caused by the
wrapper handing the wrong resources to nvc0, but I'm fairly confident
that these are all fixed now. I was able to run a fairly wide range of
applications, on all of bare-metal, X and Wayland, including glxgears,
glmark2, kmscube, Weston (with some of the sample applications), some
NVIDIA internal demos as well as a source port of Doom 3[0].

The way this is achieved is that the Tegra driver wraps every resources
upon allocation and storing a pointer to the nvc0 resource created by
Nouveau. When these resources are used, the Tegra driver unwraps the
resources and passes the pointer to the nvc0 resource to the nvc0
context.

Thierry

[0]: https://github.com/dhewm/dhewm3


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/6] nouveau: Add framebuffer modifier support

[Thierry Reding]

On Thu, Mar 01, 2018 at 09:04:58AM -0800, Dylan Baker wrote:
> Quoting Thierry Reding (2018-03-01 05:54:52)
> > From: Thierry Reding <tred...@nvidia.com>
> > 
> > This adds support for framebuffer modifiers to Nouveau. This will be
> > used by the Tegra driver to share metadata about the format of buffers
> > (such as the tiling mode or compression).
> > 
> > Changes in v2:
> > - remove unused parameters to nouveau_buffer_create()
> > - move format modifier query code to nvc0 backend
> > - restrict format modifiers to 2D textures
> > - implement ->query_dmabuf_modifiers()
> > 
> > Acked-by: Emil Velikov <emil.veli...@collabora.com>
> > Tested-by: Andre Heider <a.hei...@gmail.com>
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  src/gallium/drivers/nouveau/Android.mk   |  3 +
> >  src/gallium/drivers/nouveau/Makefile.am  |  1 +
> >  src/gallium/drivers/nouveau/nouveau_screen.c |  4 ++
> >  src/gallium/drivers/nouveau/nv30/nv30_resource.c |  2 +
> >  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  | 81 
> > +++-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 59 -
> >  src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  3 +-
> >  7 files changed, 149 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/nouveau/Android.mk 
> > b/src/gallium/drivers/nouveau/Android.mk
> > index 2de22e73ec18..a446774a86e8 100644
> > --- a/src/gallium/drivers/nouveau/Android.mk
> > +++ b/src/gallium/drivers/nouveau/Android.mk
> > @@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
> > $(NVC0_CODEGEN_SOURCES) \
> > $(NVC0_C_SOURCES)
> >  
> > +LOCAL_C_INCLUDES := \
> > +   $(MESA_TOP)/include/drm-uapi
> > +
> >  LOCAL_SHARED_LIBRARIES := libdrm_nouveau
> >  LOCAL_MODULE := libmesa_pipe_nouveau
> >  
> > diff --git a/src/gallium/drivers/nouveau/Makefile.am 
> > b/src/gallium/drivers/nouveau/Makefile.am
> > index 91547178e397..f6126b544811 100644
> > --- a/src/gallium/drivers/nouveau/Makefile.am
> > +++ b/src/gallium/drivers/nouveau/Makefile.am
> > @@ -24,6 +24,7 @@ include Makefile.sources
> >  include $(top_srcdir)/src/gallium/Automake.inc
> >  
> >  AM_CPPFLAGS = \
> > +   -I$(top_srcdir)/include/drm-uapi \
> 
> This needs to be added for the meson build as well, right? Should just need to
> add "inc_drm_uapi" to the relevant "include_directories" lines.

It seems like this was working "by accident" for me because I was
building against a locally modified version of libdrm that provided the
necessary UABI changes.

Fixed now.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/6] nouveau: Add framebuffer modifier support

[Thierry Reding]

On Thu, Mar 01, 2018 at 09:37:28AM -0500, Ilia Mirkin wrote:
> On Thu, Mar 1, 2018 at 8:54 AM, Thierry Reding <thierry.red...@gmail.com> 
> wrote:
> > From: Thierry Reding <tred...@nvidia.com>
> >
> > This adds support for framebuffer modifiers to Nouveau. This will be
> > used by the Tegra driver to share metadata about the format of buffers
> > (such as the tiling mode or compression).
> >
> > Changes in v2:
> > - remove unused parameters to nouveau_buffer_create()
> > - move format modifier query code to nvc0 backend
> > - restrict format modifiers to 2D textures
> > - implement ->query_dmabuf_modifiers()
> >
> > Acked-by: Emil Velikov <emil.veli...@collabora.com>
> > Tested-by: Andre Heider <a.hei...@gmail.com>
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  src/gallium/drivers/nouveau/Android.mk   |  3 +
> >  src/gallium/drivers/nouveau/Makefile.am  |  1 +
> >  src/gallium/drivers/nouveau/nouveau_screen.c |  4 ++
> >  src/gallium/drivers/nouveau/nv30/nv30_resource.c |  2 +
> >  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  | 81 
> > +++-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 59 -
> >  src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  3 +-
> >  7 files changed, 149 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/Android.mk 
> > b/src/gallium/drivers/nouveau/Android.mk
> > index 2de22e73ec18..a446774a86e8 100644
> > --- a/src/gallium/drivers/nouveau/Android.mk
> > +++ b/src/gallium/drivers/nouveau/Android.mk
> > @@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
> > $(NVC0_CODEGEN_SOURCES) \
> > $(NVC0_C_SOURCES)
> >
> > +LOCAL_C_INCLUDES := \
> > +   $(MESA_TOP)/include/drm-uapi
> > +
> >  LOCAL_SHARED_LIBRARIES := libdrm_nouveau
> >  LOCAL_MODULE := libmesa_pipe_nouveau
> >
> > diff --git a/src/gallium/drivers/nouveau/Makefile.am 
> > b/src/gallium/drivers/nouveau/Makefile.am
> > index 91547178e397..f6126b544811 100644
> > --- a/src/gallium/drivers/nouveau/Makefile.am
> > +++ b/src/gallium/drivers/nouveau/Makefile.am
> > @@ -24,6 +24,7 @@ include Makefile.sources
> >  include $(top_srcdir)/src/gallium/Automake.inc
> >
> >  AM_CPPFLAGS = \
> > +   -I$(top_srcdir)/include/drm-uapi \
> > $(GALLIUM_DRIVER_CFLAGS) \
> > $(LIBDRM_CFLAGS) \
> > $(NOUVEAU_CFLAGS)
> 
> Someone is likely to complain about forgetting about the N+1 build
> system, meson.

Interestingly I wasn't seeing any build issues without the Meson change.
I think that was probably just out of luck because I was building
against a locally modifier version of libdrm which had the UAPI changes.

Fixed now.

> > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
> > b/src/gallium/drivers/nouveau/nouveau_screen.c
> > index c144b39b2dd2..b84ef13ebe7f 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_screen.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
> > @@ -1,3 +1,5 @@
> > +#include 
> > +
> >  #include "pipe/p_defines.h"
> >  #include "pipe/p_screen.h"
> >  #include "pipe/p_state.h"
> > @@ -23,6 +25,8 @@
> >  #include "nouveau_mm.h"
> >  #include "nouveau_buffer.h"
> >
> > +#include "nvc0/nvc0_resource.h"
> 
> Can't have that... why do you need it here?

I don't. This is left over from an earlier version where code later in
this file was calling into the nvc0 backend directly. I've since then
pushed that code into the nvc0 backend itself but forgot to remove the
include here.

Dropped now.

> > +
> >  /* XXX this should go away */
> >  #include "state_tracker/drm_driver.h"
> >
> > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_resource.c 
> > b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
> > index ff34f6e5f9fa..386bd3459bd3 100644
> > --- a/src/gallium/drivers/nouveau/nv30/nv30_resource.c
> > +++ b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
> > @@ -23,6 +23,8 @@
> >   *
> >   */
> >
> > +#include 
> > +
> >  #include "util/u_format.h"
> >  #include "util/u_inlines.h"
> >
> > diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
> > b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
> > index 27674f72a7c0..7983c4030876 100644
> > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
> > +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.

[Mesa-dev] [PATCH v2] loader: Add support for platform and host1x busses

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
support for this bus in order to allow use of the DRI_PRIME environment
variable with those devices.

While at it, also support the host1x bus, which is effectively the same
but uses an additional layer in the bus hierarchy.

Note that it isn't enough to support the bus that has the rendering GPU
because the loader code will also try to construct an ID path tag for a
scanout-only device if it is the default that is being opened.

The ID path tag for a device can be obtained by running udevadm info on
the device node, as shown in this example on NVIDIA Tegra:

$ udevadm info /dev/dri/card0 | grep ID_PATH_TAG
E: ID_PATH_TAG=platform-5000_host1x

The corresponding OF_FULLNAME property, from which the ID_PATH_TAG is
constructed, can be found in the sysfs "uevent" attribute for the card0
device's parent:

$ grep OF_FULLNAME /sys/devices/platform/5000.host1x/drm/uevent
OF_FULLNAME=/host1x@5000

Similarily, /dev/dri/card1 corresponds to the GPU:

$ udevadm info /dev/dri/card1 | grep ID_PATH_TAG
E: ID_PATH_TAG=platform-5700_gpu

and:

$ grep OF_FULLNAME /sys/devices/platform/5700.gpu/uevent
OF_FULLNAME=/gpu@5700

Changes in v2:
- avoid confusing pre-increment in strdup()
- add examples of tags to commit log

Reviewed-by: Eric Engestrom <e...@engestrom.ch>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/loader/loader.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 92b4c5204b19..43275484cc2e 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -120,6 +120,33 @@ static char *drm_construct_id_path_tag(drmDevicePtr device)
device->businfo.pci->func) < 0) {
  return NULL;
   }
+   } else if (device->bustype == DRM_BUS_PLATFORM ||
+  device->bustype == DRM_BUS_HOST1X) {
+  char *fullname, *name, *address;
+
+  if (device->bustype == DRM_BUS_PLATFORM)
+ fullname = device->businfo.platform->fullname;
+  else
+ fullname = device->businfo.host1x->fullname;
+
+  name = strrchr(fullname, '/');
+  if (!name)
+ name = strdup(fullname);
+  else
+ name = strdup(name + 1);
+
+  address = strchr(name, '@');
+  if (address) {
+ *address++ = '\0';
+
+ if (asprintf(, "platform-%s_%s", address, name) < 0)
+tag = NULL;
+  } else {
+ if (asprintf(, "platform-%s", name) < 0)
+tag = NULL;
+  }
+
+  free(name);
}
return tag;
 }
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] disk cache: Link with -latomic if necessary

[Thierry Reding]

On Thu, Mar 01, 2018 at 08:53:59AM -0800, Dylan Baker wrote:
> Quoting Thierry Reding (2018-03-01 05:28:07)
> > From: Thierry Reding <tred...@nvidia.com>
> > 
> > The disk cache implementation uses 64-bit atomic operations. For some
> > architectures, such as 32-bit ARM, GCC will not be able to translate
> > these operations into atomic, lock-free instructions and will instead
> > rely on the external atomics library to provide these operations.
> > 
> > Check at configuration time whether or not linking against libatomic
> > is necessary and if so, create a dependency that can be used while
> > linking the mesautil library.
> > 
> > This is the meson equivalent of 2ef7f23820a6 ("configure: check if
> > -latomic is needed for __atomic_*").
> > 
> > For some background information on this, see:
> > 
> > https://gcc.gnu.org/wiki/Atomic/GCCMM
> > 
> > Changes in v2:
> > - clarify meaning of lock-free in commit message
> > - fix build if -latomic is not necessary
> > 
> > Acked-by: Matt Turner <matts...@gmail.com>
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  meson.build  | 17 +
> >  src/util/meson.build |  2 +-
> >  2 files changed, 18 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index e9928a379313..bb6a835084fe 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -790,9 +790,26 @@ else
> >  endif
> >  
> >  # Check for GCC style atomics
> > +dep_atomic = declare_dependency()
> > +
> >  if cc.compiles('int main() { int n; return __atomic_load_n(, 
> > __ATOMIC_ACQUIRE); }',
> > name : 'GCC atomic builtins')
> >pre_args += '-DUSE_GCC_ATOMIC_BUILTINS'
> > +
> > +  # Not all atomic calls can be turned into lock-free instructions, in 
> > which
> > +  # GCC will make calls into the libatomic library. Check whether we need 
> > to
> > +  # link with -latomic.
> > +  #
> > +  # This can happen for 64-bit atomic operations on 32-bit architectures 
> > such
> > +  # as ARM.
> > +  if not cc.links('''#include 
> > + int main() {
> > +   uint64_t n;
> > +   return (int)__atomic_load_n(, __ATOMIC_ACQUIRE);
> > + }''',
> > +  name : 'GCC atomic builtins required -latomic')
> > +dep_atomic = cc.find_library('atomic')
> > +  endif
> >  endif
> >  if not cc.links('''#include 
> > uint64_t v;
> > diff --git a/src/util/meson.build b/src/util/meson.build
> > index b23dba3a9851..eece1cefef6a 100644
> > --- a/src/util/meson.build
> > +++ b/src/util/meson.build
> > @@ -102,7 +102,7 @@ libmesa_util = static_library(
> >'mesa_util',
> >[files_mesa_util, format_srgb],
> >include_directories : inc_common,
> > -  dependencies : [dep_zlib, dep_clock, dep_thread],
> > +  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
> >c_args : [c_msvc_compat_args, c_vis_args],
> >build_by_default : false
> >  )
> > -- 
> > 2.16.2
> > 
> 
> Reviewed-by: Dylan Baker <dy...@pnwbakers.com>

Thanks. Pushed to master.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader: Add support for platform and host1x busses

[Thierry Reding]

On Thu, Mar 01, 2018 at 02:14:41PM +, Eric Engestrom wrote:
> 
> 
> On March 1, 2018 1:31:53 PM UTC, Thierry Reding <thierry.red...@gmail.com> 
> wrote:
> > From: Thierry Reding <tred...@nvidia.com>
> > 
> > ARM SoCs usually have their DRM/KMS devices on the platform bus, so
> > add
> > support for this bus in order to allow use of the DRI_PRIME
> > environment
> > variable with those devices.
> > 
> > While at it, also support the host1x bus, which is effectively the
> > same
> > but uses an additional layer in the bus hierarchy.
> > 
> > Note that it isn't enough to support the bus that has the rendering
> > GPU
> > because the loader code will also try to construct an ID path tag for
> > a
> > scanout-only device if it is the default that is being opened.
> > 
> > The ID path tag for a device can be obtained by running udevadm info
> > on
> > the device node:
> > 
> > $ udevadm info /dev/dri/card0
> > 
> > and looking up the ID_PATH_TAG entry in the output.
> > 
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  src/loader/loader.c | 27 +++
> >  1 file changed, 27 insertions(+)
> > 
> > diff --git a/src/loader/loader.c b/src/loader/loader.c
> > index 92b4c5204b19..ca578b8cd232 100644
> > --- a/src/loader/loader.c
> > +++ b/src/loader/loader.c
> > @@ -120,6 +120,33 @@ static char
> > *drm_construct_id_path_tag(drmDevicePtr device)
> > device->businfo.pci->func) < 0) {
> >   return NULL;
> >}
> > +   } else if (device->bustype == DRM_BUS_PLATFORM ||
> > +  device->bustype == DRM_BUS_HOST1X) {
> > +  char *fullname, *name, *address;
> > +
> > +  if (device->bustype == DRM_BUS_PLATFORM)
> > + fullname = device->businfo.platform->fullname;
> > +  else
> > + fullname = device->businfo.host1x->fullname;
> > +
> > +  name = strrchr(fullname, '/');
> > +  if (!name)
> > + name = strdup(fullname);
> > +  else
> > + name = strdup(++name);
> 
> Looks like UB to me; how about this instead?
> 
>   name = strdup(name + 1);

I don't think the above is problematic. ++name is guaranteed to be
evaluated before the call to strdup(), and name can't be overwritten by
the assignment until after strdup() is done.

But I have no objection to change this to your suggestion, which is
slightly easier to read irrespective of UB or not. I'm honestly not
exactly sure why I wrote it in this strange way. I /think/ an earlier
version of the patch wasn't assigning to name but another variable and
reusing the name variable, which is why it had to be incremented. But
that's no longer necessary.

> With that:
> Reviewed-by: Eric Engestrom <e...@engestrom.ch>

Thanks,
Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 6/6] autotools: Add tegra to AM_DISTCHECK_CONFIGURE_FLAGS

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This allows the driver to be built on a make distcheck and makes sure
that it properly builds when a distribution tarball is made.

Suggested-by: Emil Velikov <emil.veli...@collabora.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 5c3a6717d34e..de6921bf1fcb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -45,7 +45,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
--enable-libunwind \
--with-platforms=x11,wayland,drm,surfaceless \
--with-dri-drivers=i915,i965,nouveau,radeon,r200,swrast \
-   
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,swr,etnaviv,imx
 \
+   
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,tegra,virgl,swr,etnaviv,imx
 \
--with-vulkan-drivers=intel,radeon
 
 ACLOCAL_AMFLAGS = -I m4
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 4/6] nouveau: Add framebuffer modifier support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This adds support for framebuffer modifiers to Nouveau. This will be
used by the Tegra driver to share metadata about the format of buffers
(such as the tiling mode or compression).

Changes in v2:
- remove unused parameters to nouveau_buffer_create()
- move format modifier query code to nvc0 backend
- restrict format modifiers to 2D textures
- implement ->query_dmabuf_modifiers()

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/Android.mk   |  3 +
 src/gallium/drivers/nouveau/Makefile.am  |  1 +
 src/gallium/drivers/nouveau/nouveau_screen.c |  4 ++
 src/gallium/drivers/nouveau/nv30/nv30_resource.c |  2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  | 81 +++-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 59 -
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  3 +-
 7 files changed, 149 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/Android.mk 
b/src/gallium/drivers/nouveau/Android.mk
index 2de22e73ec18..a446774a86e8 100644
--- a/src/gallium/drivers/nouveau/Android.mk
+++ b/src/gallium/drivers/nouveau/Android.mk
@@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
$(NVC0_CODEGEN_SOURCES) \
$(NVC0_C_SOURCES)
 
+LOCAL_C_INCLUDES := \
+   $(MESA_TOP)/include/drm-uapi
+
 LOCAL_SHARED_LIBRARIES := libdrm_nouveau
 LOCAL_MODULE := libmesa_pipe_nouveau
 
diff --git a/src/gallium/drivers/nouveau/Makefile.am 
b/src/gallium/drivers/nouveau/Makefile.am
index 91547178e397..f6126b544811 100644
--- a/src/gallium/drivers/nouveau/Makefile.am
+++ b/src/gallium/drivers/nouveau/Makefile.am
@@ -24,6 +24,7 @@ include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CPPFLAGS = \
+   -I$(top_srcdir)/include/drm-uapi \
$(GALLIUM_DRIVER_CFLAGS) \
$(LIBDRM_CFLAGS) \
$(NOUVEAU_CFLAGS)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index c144b39b2dd2..b84ef13ebe7f 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -1,3 +1,5 @@
+#include 
+
 #include "pipe/p_defines.h"
 #include "pipe/p_screen.h"
 #include "pipe/p_state.h"
@@ -23,6 +25,8 @@
 #include "nouveau_mm.h"
 #include "nouveau_buffer.h"
 
+#include "nvc0/nvc0_resource.h"
+
 /* XXX this should go away */
 #include "state_tracker/drm_driver.h"
 
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_resource.c 
b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
index ff34f6e5f9fa..386bd3459bd3 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_resource.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
@@ -23,6 +23,8 @@
  *
  */
 
+#include 
+
 #include "util/u_format.h"
 #include "util/u_inlines.h"
 
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 27674f72a7c0..7983c4030876 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -20,8 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
+
 #include "pipe/p_state.h"
 #include "pipe/p_defines.h"
+#include "state_tracker/drm_driver.h"
 #include "util/u_inlines.h"
 #include "util/u_format.h"
 
@@ -233,9 +236,79 @@ nvc0_miptree_init_layout_tiled(struct nv50_miptree *mt)
}
 }
 
+static uint64_t nvc0_miptree_get_modifier(struct nv50_miptree *mt)
+{
+   union nouveau_bo_config *config = >base.bo->config;
+   uint64_t modifier;
+
+   if (mt->layout_3d)
+  return DRM_FORMAT_MOD_INVALID;
+
+   switch (config->nvc0.memtype) {
+   case 0x00:
+  modifier = DRM_FORMAT_MOD_LINEAR;
+  break;
+
+   case 0xfe:
+  switch (NVC0_TILE_MODE_Y(config->nvc0.tile_mode)) {
+  case 0:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB;
+ break;
+
+  case 1:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB;
+ break;
+
+  case 2:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB;
+ break;
+
+  case 3:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB;
+ break;
+
+  case 4:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB;
+ break;
+
+  case 5:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB;
+ break;
+
+  default:
+ modifier = DRM_FORMAT_MOD_INVALID;
+ break;
+  }
+  break;
+
+   default:
+  modifier = DRM_FORMAT_MOD_INVALID;
+  break;
+   }
+
+   return modifier;
+}
+
+static boolean
+nvc0_miptree_get_handle(struct pipe_screen *pscreen,
+struct pipe_res

[Mesa-dev] [PATCH v3 3/6] nouveau/nvc0: Extract common tile mode macro

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Add a new macro that can be used to extract the tiling mode from a
tile_mode value. This is will be used to determine the number of GOBs
used in block linear mode.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
index 0d5f026d6e1c..c68a50948360 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
@@ -6,14 +6,17 @@
 
 #define NVC0_RESOURCE_FLAG_VIDEO (NOUVEAU_RESOURCE_FLAG_DRV_PRIV << 0)
 
+#define NVC0_TILE_MODE_X(m) (((m) >> 0) & 0xf)
+#define NVC0_TILE_MODE_Y(m) (((m) >> 4) & 0xf)
+#define NVC0_TILE_MODE_Z(m) (((m) >> 8) & 0xf)
 
-#define NVC0_TILE_SHIFT_X(m) m) >> 0) & 0xf) + 6)
-#define NVC0_TILE_SHIFT_Y(m) m) >> 4) & 0xf) + 3)
-#define NVC0_TILE_SHIFT_Z(m) m) >> 8) & 0xf) + 0)
+#define NVC0_TILE_SHIFT_X(m) (NVC0_TILE_MODE_X(m) + 6)
+#define NVC0_TILE_SHIFT_Y(m) (NVC0_TILE_MODE_Y(m) + 3)
+#define NVC0_TILE_SHIFT_Z(m) (NVC0_TILE_MODE_Z(m) + 0)
 
-#define NVC0_TILE_SIZE_X(m) (64 << (((m) >> 0) & 0xf))
-#define NVC0_TILE_SIZE_Y(m) ( 8 << (((m) >> 4) & 0xf))
-#define NVC0_TILE_SIZE_Z(m) ( 1 << (((m) >> 8) & 0xf))
+#define NVC0_TILE_SIZE_X(m) (64 << NVC0_TILE_MODE_X(m))
+#define NVC0_TILE_SIZE_Y(m) ( 8 << NVC0_TILE_MODE_Y(m))
+#define NVC0_TILE_SIZE_Z(m) ( 1 << NVC0_TILE_MODE_Z(m))
 
 /* it's ok to mask only in the end because max value is 3 * 5 */
 
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 5/6] tegra: Initial support

[Thierry Reding]

Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
But the GPU is a pure render node and has no display engine, hence the
scanout needs to happen on the Tegra display hardware. The GPU and the
display engine each have a separate DRM device node exposed by the
kernel.

To make the setup appear as a single device, this driver instantiates
a Nouveau screen with each instance of a Tegra screen and forwards GPU
requests to the Nouveau screen. For purposes of scanout it will import
buffers created on the GPU into the display driver. Handles that
userspace requests are those of the display driver so that they can be
used to create framebuffers.

This has been tested with some GBM test programs, as well as kmscube and
weston. All of those run without modifications, but I'm sure there is a
lot that can be improved.

Some fixes contributed by Hector Martin <mar...@marcan.st>.

Changes in v2:
- duplicate file descriptor in winsys to avoid potential issues
- require nouveau when building the tegra driver
- check for nouveau driver name on render node
- remove unneeded dependency on libdrm_tegra
- remove zombie references to libudev
- add missing headers to C_SOURCES variable
- drop unneeded tegra/ prefix for includes
- open device files with O_CLOEXEC
- update copyrights

Changes in v3:
- properly unwrap resources in ->resource_copy_region()
- support vertex buffers passed by user pointer
- allocate custom stream and const uploader
- silence error message on pre-Tegra124
- support X without explicit PRIME

Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 configure.ac   |   12 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   11 +
 src/gallium/drivers/tegra/Makefile.sources |6 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1325 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  688 ++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   10 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   49 +
 26 files changed, 2705 insertions(+), 4 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

diff --git a/configure.ac b/configure.ac
index d8093597dd04..27528181b73e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1351,7 +1351,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
 AC_ARG_WITH([gallium-drivers],
 [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
 [comma delimited Gallium drivers list, e.g.
-
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,vc4,vc5,virgl,etnaviv,imx"
+
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,tegra,vc4,vc5,virgl,etnaviv,imx"
 @<:@de

[Mesa-dev] [PATCH v3 0/6] NVIDIA Tegra support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This series of patches implements initial support for Tegra. The first
two patches import DRM UAPI from v4.16-rc1 that provides framebuffer
modifiers that can be used to specify buffers shared between Nouveau
and the Tegra DRM driver.

Patches 3 and 4 add support for framebuffer modifiers to Nouveau and
patch 5 build on top of those to provide initial Tegra support in Mesa.
The current patches allow running common use-cases such as Wayland,
kmscube, etc.

Patch 6 adds the Tegra driver to the list of gallium drivers built
during a `make distcheck'.

Some people have been using earlier versions of these patches to run a
completely open-source graphics stack on various Tegra210 devices. I've
Cc'ed some of them so that they can provide feedback.

This series is also available in a git repository here:

https://cgit.freedesktop.org/~tagr/mesa #tegra-v3

Thierry

Thierry Reding (6):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers
  nouveau/nvc0: Extract common tile mode macro
  nouveau: Add framebuffer modifier support
  tegra: Initial support
  autotools: Add tegra to AM_DISTCHECK_CONFIGURE_FLAGS

 Makefile.am|2 +-
 configure.ac   |   12 +-
 include/drm-uapi/drm_fourcc.h  |   38 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/nouveau/Android.mk |3 +
 src/gallium/drivers/nouveau/Makefile.am|1 +
 src/gallium/drivers/nouveau/nouveau_screen.c   |4 +
 src/gallium/drivers/nouveau/nv30/nv30_resource.c   |2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|   81 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c   |   59 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h   |   18 +-
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   11 +
 src/gallium/drivers/tegra/Makefile.sources |6 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1325 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  688 ++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   10 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   49 +
 35 files changed, 2884 insertions(+), 33 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 2/6] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

This is based on commit 268892cb63a822315921a8dab48ac3e4abf7dd03 from
Linux v4.16-rc1.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index a76ed8f9e383..e04613d30a13 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -178,7 +178,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
-#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
@@ -338,29 +338,17 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
-/* NVIDIA Tegra frame buffer modifiers */
-
-/*
- * Some modifiers take parameters, for example the number of vertical GOBs in
- * a block. Reserve the lower 32 bits for parameters
- */
-#define __fourcc_mod_tegra_mode_shift 32
-#define fourcc_mod_tegra_code(val, params) \
-   fourcc_mod_code(NV, __u64)val) << __fourcc_mod_tegra_mode_shift) | 
params))
-#define fourcc_mod_tegra_mod(m) \
-   (m & ~((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
-#define fourcc_mod_tegra_param(m) \
-   (m & ((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
+/* NVIDIA frame buffer modifiers */
 
 /*
  * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
  *
  * Pixels are arranged in simple tiles of 16 x 16 bytes.
  */
-#define NV_FORMAT_MOD_TEGRA_TILED fourcc_mod_tegra_code(1, 0)
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
 
 /*
- * Tegra 16Bx2 Block Linear layout, used by TK1/TX1
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
  *
  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
@@ -380,7 +368,21 @@ extern "C" {
  * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
  * in full detail.
  */
-#define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+   fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+   fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+   fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+   fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+   fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x15)
 
 /*
  * Broadcom VC4 "T" format
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 1/6] drm/fourcc: Fix fourcc_mod_code() definition

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Avoid a compiler warnings when the val parameter is an expression.

This is based on commit 5843f4e02fbe86a59981e35adc6cabebee46fdc0 from
Linux v4.16-rc1.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index 3ad838d3f93f..a76ed8f9e383 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -188,7 +188,7 @@ extern "C" {
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
 
 #define fourcc_mod_code(vendor, val) \
-   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 
0x00ffULL))
 
 /*
  * Format Modifier tokens:
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] loader: Add support for platform and host1x busses

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
support for this bus in order to allow use of the DRI_PRIME environment
variable with those devices.

While at it, also support the host1x bus, which is effectively the same
but uses an additional layer in the bus hierarchy.

Note that it isn't enough to support the bus that has the rendering GPU
because the loader code will also try to construct an ID path tag for a
scanout-only device if it is the default that is being opened.

The ID path tag for a device can be obtained by running udevadm info on
the device node:

$ udevadm info /dev/dri/card0

and looking up the ID_PATH_TAG entry in the output.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/loader/loader.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 92b4c5204b19..ca578b8cd232 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -120,6 +120,33 @@ static char *drm_construct_id_path_tag(drmDevicePtr device)
device->businfo.pci->func) < 0) {
  return NULL;
   }
+   } else if (device->bustype == DRM_BUS_PLATFORM ||
+  device->bustype == DRM_BUS_HOST1X) {
+  char *fullname, *name, *address;
+
+  if (device->bustype == DRM_BUS_PLATFORM)
+ fullname = device->businfo.platform->fullname;
+  else
+ fullname = device->businfo.host1x->fullname;
+
+  name = strrchr(fullname, '/');
+  if (!name)
+ name = strdup(fullname);
+  else
+ name = strdup(++name);
+
+  address = strchr(name, '@');
+  if (address) {
+ *address++ = '\0';
+
+ if (asprintf(, "platform-%s_%s", address, name) < 0)
+tag = NULL;
+  } else {
+ if (asprintf(, "platform-%s", name) < 0)
+tag = NULL;
+  }
+
+  free(name);
}
return tag;
 }
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] disk cache: Link with -latomic if necessary

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The disk cache implementation uses 64-bit atomic operations. For some
architectures, such as 32-bit ARM, GCC will not be able to translate
these operations into atomic, lock-free instructions and will instead
rely on the external atomics library to provide these operations.

Check at configuration time whether or not linking against libatomic
is necessary and if so, create a dependency that can be used while
linking the mesautil library.

This is the meson equivalent of 2ef7f23820a6 ("configure: check if
-latomic is needed for __atomic_*").

For some background information on this, see:

https://gcc.gnu.org/wiki/Atomic/GCCMM

Changes in v2:
- clarify meaning of lock-free in commit message
- fix build if -latomic is not necessary

Acked-by: Matt Turner <matts...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 meson.build  | 17 +
 src/util/meson.build |  2 +-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index e9928a379313..bb6a835084fe 100644
--- a/meson.build
+++ b/meson.build
@@ -790,9 +790,26 @@ else
 endif
 
 # Check for GCC style atomics
+dep_atomic = declare_dependency()
+
 if cc.compiles('int main() { int n; return __atomic_load_n(, 
__ATOMIC_ACQUIRE); }',
name : 'GCC atomic builtins')
   pre_args += '-DUSE_GCC_ATOMIC_BUILTINS'
+
+  # Not all atomic calls can be turned into lock-free instructions, in which
+  # GCC will make calls into the libatomic library. Check whether we need to
+  # link with -latomic.
+  #
+  # This can happen for 64-bit atomic operations on 32-bit architectures such
+  # as ARM.
+  if not cc.links('''#include 
+ int main() {
+   uint64_t n;
+   return (int)__atomic_load_n(, __ATOMIC_ACQUIRE);
+ }''',
+  name : 'GCC atomic builtins required -latomic')
+dep_atomic = cc.find_library('atomic')
+  endif
 endif
 if not cc.links('''#include 
uint64_t v;
diff --git a/src/util/meson.build b/src/util/meson.build
index b23dba3a9851..eece1cefef6a 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -102,7 +102,7 @@ libmesa_util = static_library(
   'mesa_util',
   [files_mesa_util, format_srgb],
   include_directories : inc_common,
-  dependencies : [dep_zlib, dep_clock, dep_thread],
+  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
   c_args : [c_msvc_compat_args, c_vis_args],
   build_by_default : false
 )
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] disk cache: Link with -latomic if necessary

[Thierry Reding]

On Mon, Feb 26, 2018 at 11:28:23PM +, Mike Lothian wrote:
> On Fri, 23 Feb 2018 at 13:18 Thierry Reding <thierry.red...@gmail.com>
> wrote:
> 
> > From: Thierry Reding <tred...@nvidia.com>
> >
> > The disk cache implementation uses 64-bit atomic operations. For some
> > architectures, such as 32-bit ARM, GCC will not be able to translate
> > these operations into lock-free instructions and will instead rely on
> > the external atomics library to provide these operations.
> >
> > Check at configuration time whether or not linking against libatomic
> > is necessary and if so, create a dependency that can be used while
> > linking the mesautil library.
> >
> > This is the meson equivalent of 2ef7f23820a6 ("configure: check if
> > -latomic is needed for __atomic_*").
> >
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  meson.build  | 15 +++
> >  src/util/meson.build |  2 +-
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/meson.build b/meson.build
> > index 121341a950c4..7c6f40573421 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -800,6 +800,21 @@ endif
> >  if cc.compiles('int main() { int n; return __atomic_load_n(,
> > __ATOMIC_ACQUIRE); }',
> > name : 'GCC atomic builtins')
> >pre_args += '-DUSE_GCC_ATOMIC_BUILTINS'
> > +
> > +  # Not all atomic calls can be turned into lock-free instructions, in
> > which
> > +  # GCC will make calls into the libatomic library. Check whether we need
> > to
> > +  # link with -latomic.
> > +  #
> > +  # This can happen for 64-bit atomic operations on 32-bit architectures
> > such
> > +  # as ARM.
> > +  if not cc.links('''#include 
> > + int main() {
> > +   uint64_t n;
> > +   return (int)__atomic_load_n(, __ATOMIC_ACQUIRE);
> > + }''',
> > +  name : 'GCC atomic builtins required -latomic')
> > +dep_atomic = cc.find_library('atomic')
> > +  endif
> >  endif
> >  if not cc.links('''#include 
> > uint64_t v;
> > diff --git a/src/util/meson.build b/src/util/meson.build
> > index b23dba3a9851..eece1cefef6a 100644
> > --- a/src/util/meson.build
> > +++ b/src/util/meson.build
> > @@ -102,7 +102,7 @@ libmesa_util = static_library(
> >'mesa_util',
> >[files_mesa_util, format_srgb],
> >include_directories : inc_common,
> > -  dependencies : [dep_zlib, dep_clock, dep_thread],
> > +  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
> >c_args : [c_msvc_compat_args, c_vis_args],
> >build_by_default : false
> >  )
> > --
> > 2.16.2
> >
> >
> Hi
> 
> I had this issue when building a 32bit Mesa on x86-64 when using Clang,
> 64bit was fine.
> 
> Will this work for Clang too and if so can a similar change be made for
> autotools?

I think this should work for clang as well. I'm not overly familiar with
it, but Google suggests that clang supports these atomic operations and
will fallback to generating calls into libatomic for those that can't be
turned into lock-free operations.

My understanding is that this should already work for autotools. See my
note about the equivalent commit already in Mesa's master.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] disk cache: Link with -latomic if necessary

[Thierry Reding]

On Mon, Feb 26, 2018 at 12:05:51PM -0800, Dylan Baker wrote:
> Quoting Thierry Reding (2018-02-23 05:18:28)
> > From: Thierry Reding <tred...@nvidia.com>
> > 
> > The disk cache implementation uses 64-bit atomic operations. For some
> > architectures, such as 32-bit ARM, GCC will not be able to translate
> > these operations into lock-free instructions and will instead rely on
> > the external atomics library to provide these operations.
> > 
> > Check at configuration time whether or not linking against libatomic
> > is necessary and if so, create a dependency that can be used while
> > linking the mesautil library.
> > 
> > This is the meson equivalent of 2ef7f23820a6 ("configure: check if
> > -latomic is needed for __atomic_*").
> > 
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  meson.build  | 15 +++
> >  src/util/meson.build |  2 +-
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 121341a950c4..7c6f40573421 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -800,6 +800,21 @@ endif
> >  if cc.compiles('int main() { int n; return __atomic_load_n(, 
> > __ATOMIC_ACQUIRE); }',
> > name : 'GCC atomic builtins')
> >pre_args += '-DUSE_GCC_ATOMIC_BUILTINS'
> > +
> > +  # Not all atomic calls can be turned into lock-free instructions, in 
> > which
> > +  # GCC will make calls into the libatomic library. Check whether we need 
> > to
> > +  # link with -latomic.
> > +  #
> > +  # This can happen for 64-bit atomic operations on 32-bit architectures 
> > such
> > +  # as ARM.
> > +  if not cc.links('''#include 
> > + int main() {
> > +   uint64_t n;
> > +   return (int)__atomic_load_n(, __ATOMIC_ACQUIRE);
> > + }''',
> > +  name : 'GCC atomic builtins required -latomic')
> > +dep_atomic = cc.find_library('atomic')
> 
> dep_atomic is undefined if the cc.links() succeeds right?

Yeah, I noticed that too when building on 64-bit ARM and then forgot to
send out v2. I'll do that shortly. The fix, though I'm not sure if it's
the correct way to do it in Meson, is to declare dep_atomic as an empty
dependency:

dep_atomic = declare_dependency()

unconditionally and then overwrite it with the proper dependency after
libatomic was detected.

Any ideas if this can be done more idiomatically?

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] disk cache: Link with -latomic if necessary

[Thierry Reding]

On Mon, Feb 26, 2018 at 11:14:05AM -0800, Matt Turner wrote:
> On Fri, Feb 23, 2018 at 5:18 AM, Thierry Reding
> <thierry.red...@gmail.com> wrote:
> > From: Thierry Reding <tred...@nvidia.com>
> >
> > The disk cache implementation uses 64-bit atomic operations. For some
> > architectures, such as 32-bit ARM, GCC will not be able to translate
> > these operations into lock-free instructions and will instead rely on
> 
> Here, and in the comment in meson.build, I think you mean "atomic"
> rather than "lock-free" instructions? It's at least confusing, since
> on x86 atomic instructions have a "lock" prefix.

This uses the terminology used by the GCC documentation, see:

https://gcc.gnu.org/wiki/Atomic/GCCMM

I think the GCC terms merely mean that you don't need any explicit
locking for these operations to be atomic.

How about this instead:

"... operations into atomic, lock-free instructions..."

?

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] tegra: Initial support

[Thierry Reding]

On Thu, Feb 22, 2018 at 02:32:26PM +, Emil Velikov wrote:
> On 22 February 2018 at 13:23, Thierry Reding <thierry.red...@gmail.com> wrote:
[...]
> > Good point. Let me check what exactly we use in the closed-source driver
> > and then come up with a proposal.
> >
> > I think perhaps a good choice for the vendor would be "grate". Even
> > though this driver isn't part of the grate project, I'm hoping that we
> > will eventually see Erik's and Dmitry's work merged into this.
> >
> > Adding Erik and Dmitry to get their opinion.
> >
> Ack. Since this can be tweaked later, I'd suggest not blocking the
> series on the name specifics.

So the closed-source driver reports this:

...
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA Tegra X1 (nvgpu)/integrated/DEBUG
...

I suppose we could just do:

vendor = "tegra"
name = "NVIDIA Tegra X1"

The vendor seems to match the driver name for all (to match the Mesa driver 
name like other
  drivers do)
we can base the name on something we could query from sysfs, for
example. So we could display "NVIDIA Tegra 20" and similar for the GPU
supported by grate and K1, X1, X2, ... for those supported by Nouveau.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] disk cache: Link with -latomic if necessary

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The disk cache implementation uses 64-bit atomic operations. For some
architectures, such as 32-bit ARM, GCC will not be able to translate
these operations into lock-free instructions and will instead rely on
the external atomics library to provide these operations.

Check at configuration time whether or not linking against libatomic
is necessary and if so, create a dependency that can be used while
linking the mesautil library.

This is the meson equivalent of 2ef7f23820a6 ("configure: check if
-latomic is needed for __atomic_*").

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 meson.build  | 15 +++
 src/util/meson.build |  2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 121341a950c4..7c6f40573421 100644
--- a/meson.build
+++ b/meson.build
@@ -800,6 +800,21 @@ endif
 if cc.compiles('int main() { int n; return __atomic_load_n(, 
__ATOMIC_ACQUIRE); }',
name : 'GCC atomic builtins')
   pre_args += '-DUSE_GCC_ATOMIC_BUILTINS'
+
+  # Not all atomic calls can be turned into lock-free instructions, in which
+  # GCC will make calls into the libatomic library. Check whether we need to
+  # link with -latomic.
+  #
+  # This can happen for 64-bit atomic operations on 32-bit architectures such
+  # as ARM.
+  if not cc.links('''#include 
+ int main() {
+   uint64_t n;
+   return (int)__atomic_load_n(, __ATOMIC_ACQUIRE);
+ }''',
+  name : 'GCC atomic builtins required -latomic')
+dep_atomic = cc.find_library('atomic')
+  endif
 endif
 if not cc.links('''#include 
uint64_t v;
diff --git a/src/util/meson.build b/src/util/meson.build
index b23dba3a9851..eece1cefef6a 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -102,7 +102,7 @@ libmesa_util = static_library(
   'mesa_util',
   [files_mesa_util, format_srgb],
   include_directories : inc_common,
-  dependencies : [dep_zlib, dep_clock, dep_thread],
+  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
   c_args : [c_msvc_compat_args, c_vis_args],
   build_by_default : false
 )
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 5/6] tegra: Initial support

[Thierry Reding]

Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
But the GPU is a pure render node and has no display engine, hence the
scanout needs to happen on the Tegra display hardware. The GPU and the
display engine each have a separate DRM device node exposed by the
kernel.

To make the setup appear as a single device, this driver instantiates
a Nouveau screen with each instance of a Tegra screen and forwards GPU
requests to the Nouveau screen. For purposes of scanout it will import
buffers created on the GPU into the display driver. Handles that
userspace requests are those of the display driver so that they can be
used to create framebuffers.

This has been tested with some GBM test programs, as well as kmscube and
weston. All of those run without modifications, but I'm sure there is a
lot that can be improved.

Some fixes contributed by Hector Martin <mar...@marcan.st>.

Changes in v2:
- duplicate file descriptor in winsys to avoid potential issues
- require nouveau when building the tegra driver
- check for nouveau driver name on render node
- remove unneeded dependency on libdrm_tegra
- remove zombie references to libudev
- add missing headers to C_SOURCES variable
- drop unneeded tegra/ prefix for includes
- open device files with O_CLOEXEC
- update copyrights

Reviewed-by: Emil Velikov <emil.veli...@collabora.com>
Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 configure.ac   |   12 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   11 +
 src/gallium/drivers/tegra/Makefile.sources |6 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1294 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  692 +++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   10 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   49 +
 26 files changed, 2678 insertions(+), 4 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

diff --git a/configure.ac b/configure.ac
index 8a9172690a87..60a671046016 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1350,7 +1350,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
 AC_ARG_WITH([gallium-drivers],
 [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
 [comma delimited Gallium drivers list, e.g.
-
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,vc4,vc5,virgl,etnaviv,imx"
+
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,tegra,vc4,vc5,virgl,etnaviv,imx"
 @<:@default=r300,r600,svga,swrast@:>@])],
 [with_gallium_drivers="$withval"],
 [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
@@ -2595,6 +2595,10 @@ if test -n "$with_gallium_drivers"; then
ximx)

[Mesa-dev] [PATCH v2 6/6] autotools: Add tegra to AM_DISTCHECK_CONFIGURE_FLAGS

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This allows the driver to be built on a make distcheck and makes sure
that it properly builds when a distribution tarball is made.

Suggested-by: Emil Velikov <emil.veli...@collabora.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 5c3a6717d34e..de6921bf1fcb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -45,7 +45,7 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \
--enable-libunwind \
--with-platforms=x11,wayland,drm,surfaceless \
--with-dri-drivers=i915,i965,nouveau,radeon,r200,swrast \
-   
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,swr,etnaviv,imx
 \
+   
--with-gallium-drivers=i915,nouveau,r300,pl111,r600,radeonsi,freedreno,svga,swrast,vc4,tegra,virgl,swr,etnaviv,imx
 \
--with-vulkan-drivers=intel,radeon
 
 ACLOCAL_AMFLAGS = -I m4
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 3/6] nouveau/nvc0: Extract common tile mode macro

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Add a new macro that can be used to extract the tiling mode from a
tile_mode value. This is will be used to determine the number of GOBs
used in block linear mode.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
index 0d5f026d6e1c..c68a50948360 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
@@ -6,14 +6,17 @@
 
 #define NVC0_RESOURCE_FLAG_VIDEO (NOUVEAU_RESOURCE_FLAG_DRV_PRIV << 0)
 
+#define NVC0_TILE_MODE_X(m) (((m) >> 0) & 0xf)
+#define NVC0_TILE_MODE_Y(m) (((m) >> 4) & 0xf)
+#define NVC0_TILE_MODE_Z(m) (((m) >> 8) & 0xf)
 
-#define NVC0_TILE_SHIFT_X(m) m) >> 0) & 0xf) + 6)
-#define NVC0_TILE_SHIFT_Y(m) m) >> 4) & 0xf) + 3)
-#define NVC0_TILE_SHIFT_Z(m) m) >> 8) & 0xf) + 0)
+#define NVC0_TILE_SHIFT_X(m) (NVC0_TILE_MODE_X(m) + 6)
+#define NVC0_TILE_SHIFT_Y(m) (NVC0_TILE_MODE_Y(m) + 3)
+#define NVC0_TILE_SHIFT_Z(m) (NVC0_TILE_MODE_Z(m) + 0)
 
-#define NVC0_TILE_SIZE_X(m) (64 << (((m) >> 0) & 0xf))
-#define NVC0_TILE_SIZE_Y(m) ( 8 << (((m) >> 4) & 0xf))
-#define NVC0_TILE_SIZE_Z(m) ( 1 << (((m) >> 8) & 0xf))
+#define NVC0_TILE_SIZE_X(m) (64 << NVC0_TILE_MODE_X(m))
+#define NVC0_TILE_SIZE_Y(m) ( 8 << NVC0_TILE_MODE_Y(m))
+#define NVC0_TILE_SIZE_Z(m) ( 1 << NVC0_TILE_MODE_Z(m))
 
 /* it's ok to mask only in the end because max value is 3 * 5 */
 
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 4/6] nouveau: Add framebuffer modifier support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This adds support for framebuffer modifiers to Nouveau. This will be
used by the Tegra driver to share metadata about the format of buffers
(such as the tiling mode or compression).

Changes in v2:
- remove unused parameters to nouveau_buffer_create()
- move format modifier query code to nvc0 backend
- restrict format modifiers to 2D textures
- implement ->query_dmabuf_modifiers()

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/Android.mk   |  3 +
 src/gallium/drivers/nouveau/Makefile.am  |  1 +
 src/gallium/drivers/nouveau/nouveau_screen.c |  4 ++
 src/gallium/drivers/nouveau/nv30/nv30_resource.c |  2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  | 81 +++-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 59 -
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  3 +-
 7 files changed, 149 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/Android.mk 
b/src/gallium/drivers/nouveau/Android.mk
index 2de22e73ec18..a446774a86e8 100644
--- a/src/gallium/drivers/nouveau/Android.mk
+++ b/src/gallium/drivers/nouveau/Android.mk
@@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
$(NVC0_CODEGEN_SOURCES) \
$(NVC0_C_SOURCES)
 
+LOCAL_C_INCLUDES := \
+   $(MESA_TOP)/include/drm-uapi
+
 LOCAL_SHARED_LIBRARIES := libdrm_nouveau
 LOCAL_MODULE := libmesa_pipe_nouveau
 
diff --git a/src/gallium/drivers/nouveau/Makefile.am 
b/src/gallium/drivers/nouveau/Makefile.am
index 91547178e397..f6126b544811 100644
--- a/src/gallium/drivers/nouveau/Makefile.am
+++ b/src/gallium/drivers/nouveau/Makefile.am
@@ -24,6 +24,7 @@ include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CPPFLAGS = \
+   -I$(top_srcdir)/include/drm-uapi \
$(GALLIUM_DRIVER_CFLAGS) \
$(LIBDRM_CFLAGS) \
$(NOUVEAU_CFLAGS)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index c144b39b2dd2..b84ef13ebe7f 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -1,3 +1,5 @@
+#include 
+
 #include "pipe/p_defines.h"
 #include "pipe/p_screen.h"
 #include "pipe/p_state.h"
@@ -23,6 +25,8 @@
 #include "nouveau_mm.h"
 #include "nouveau_buffer.h"
 
+#include "nvc0/nvc0_resource.h"
+
 /* XXX this should go away */
 #include "state_tracker/drm_driver.h"
 
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_resource.c 
b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
index ff34f6e5f9fa..386bd3459bd3 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_resource.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
@@ -23,6 +23,8 @@
  *
  */
 
+#include 
+
 #include "util/u_format.h"
 #include "util/u_inlines.h"
 
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 27674f72a7c0..7983c4030876 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -20,8 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
+
 #include "pipe/p_state.h"
 #include "pipe/p_defines.h"
+#include "state_tracker/drm_driver.h"
 #include "util/u_inlines.h"
 #include "util/u_format.h"
 
@@ -233,9 +236,79 @@ nvc0_miptree_init_layout_tiled(struct nv50_miptree *mt)
}
 }
 
+static uint64_t nvc0_miptree_get_modifier(struct nv50_miptree *mt)
+{
+   union nouveau_bo_config *config = >base.bo->config;
+   uint64_t modifier;
+
+   if (mt->layout_3d)
+  return DRM_FORMAT_MOD_INVALID;
+
+   switch (config->nvc0.memtype) {
+   case 0x00:
+  modifier = DRM_FORMAT_MOD_LINEAR;
+  break;
+
+   case 0xfe:
+  switch (NVC0_TILE_MODE_Y(config->nvc0.tile_mode)) {
+  case 0:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB;
+ break;
+
+  case 1:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB;
+ break;
+
+  case 2:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB;
+ break;
+
+  case 3:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB;
+ break;
+
+  case 4:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB;
+ break;
+
+  case 5:
+ modifier = DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB;
+ break;
+
+  default:
+ modifier = DRM_FORMAT_MOD_INVALID;
+ break;
+  }
+  break;
+
+   default:
+  modifier = DRM_FORMAT_MOD_INVALID;
+  break;
+   }
+
+   return modifier;
+}
+
+static boolean
+nvc0_miptree_get_handle(struct pipe_screen *pscreen,
+struct pipe_res

[Mesa-dev] [PATCH v2 1/6] drm/fourcc: Fix fourcc_mod_code() definition

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Avoid a compiler warnings when the val parameter is an expression.

This is based on commit 5843f4e02fbe86a59981e35adc6cabebee46fdc0 from
Linux v4.16-rc1.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index 3ad838d3f93f..a76ed8f9e383 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -188,7 +188,7 @@ extern "C" {
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
 
 #define fourcc_mod_code(vendor, val) \
-   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 
0x00ffULL))
 
 /*
  * Format Modifier tokens:
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 2/6] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

This is based on commit 268892cb63a822315921a8dab48ac3e4abf7dd03 from
Linux v4.16-rc1.

Acked-by: Emil Velikov <emil.veli...@collabora.com>
Tested-by: Andre Heider <a.hei...@gmail.com>
Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index a76ed8f9e383..e04613d30a13 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -178,7 +178,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
-#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
@@ -338,29 +338,17 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
-/* NVIDIA Tegra frame buffer modifiers */
-
-/*
- * Some modifiers take parameters, for example the number of vertical GOBs in
- * a block. Reserve the lower 32 bits for parameters
- */
-#define __fourcc_mod_tegra_mode_shift 32
-#define fourcc_mod_tegra_code(val, params) \
-   fourcc_mod_code(NV, __u64)val) << __fourcc_mod_tegra_mode_shift) | 
params))
-#define fourcc_mod_tegra_mod(m) \
-   (m & ~((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
-#define fourcc_mod_tegra_param(m) \
-   (m & ((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
+/* NVIDIA frame buffer modifiers */
 
 /*
  * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
  *
  * Pixels are arranged in simple tiles of 16 x 16 bytes.
  */
-#define NV_FORMAT_MOD_TEGRA_TILED fourcc_mod_tegra_code(1, 0)
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
 
 /*
- * Tegra 16Bx2 Block Linear layout, used by TK1/TX1
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
  *
  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
@@ -380,7 +368,21 @@ extern "C" {
  * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
  * in full detail.
  */
-#define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+   fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+   fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+   fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+   fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+   fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x15)
 
 /*
  * Broadcom VC4 "T" format
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 0/6] NVIDIA Tegra support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This series of patches implements initial support for Tegra. The first
two patches import DRM UAPI from v4.16-rc1 that provide framebuffer
modifiers that can be used to specify buffers shared between Nouveau
and the Tegra DRM driver.

Patches 3 and 4 add support for framebuffer modifiers to Nouveau and
patch 5 build on top of those to provide initial Tegra support in Mesa.
The current patches allow running common use-cases such as Wayland,
kmscube, etc.

Patch 6 adds the Tegra driver to the list of gallium drivers built
during a `make distcheck'.

Some people have been using earlier versions of these patches to run a
completely open-source graphics stack on various Tegra210 devices. I've
Cc'ed some of them so that they can provide feedback.

This series is also available in a git repository here:

https://cgit.freedesktop.org/~tagr/mesa #tegra-v2

though that also contains the Nouveau syncfd patches that are still work
in progress and which require new kernel/userspace ABI. The patches here
work on top of a vanilla recent (v4.16-rc1) Linux kernel.

Thierry

Thierry Reding (6):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers
  nouveau/nvc0: Extract common tile mode macro
  nouveau: Add framebuffer modifier support
  tegra: Initial support
  autotools: Add tegra to AM_DISTCHECK_CONFIGURE_FLAGS

 Makefile.am|2 +-
 configure.ac   |   12 +-
 include/drm-uapi/drm_fourcc.h  |   38 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/nouveau/Android.mk |3 +
 src/gallium/drivers/nouveau/Makefile.am|1 +
 src/gallium/drivers/nouveau/nouveau_screen.c   |4 +
 src/gallium/drivers/nouveau/nv30/nv30_resource.c   |2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|   81 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c   |   59 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h   |   18 +-
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   11 +
 src/gallium/drivers/tegra/Makefile.sources |6 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1294 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  692 +++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   10 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   49 +
 35 files changed, 2857 insertions(+), 33 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] fixup! tegra: Initial support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

---
 configure.ac|  5 +++--
 src/gallium/drivers/tegra/Makefile.am   |  9 +---
 src/gallium/drivers/tegra/Makefile.sources  |  5 -
 src/gallium/drivers/tegra/tegra_context.c   |  8 +++
 src/gallium/drivers/tegra/tegra_context.h   |  2 +-
 src/gallium/drivers/tegra/tegra_resource.h  |  2 +-
 src/gallium/drivers/tegra/tegra_screen.c| 30 -
 src/gallium/drivers/tegra/tegra_screen.h|  2 +-
 src/gallium/winsys/tegra/drm/Makefile.am|  3 +--
 src/gallium/winsys/tegra/drm/tegra_drm_public.h |  2 +-
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c | 20 +++--
 11 files changed, 59 insertions(+), 29 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7f83fb9ee17e..60a671046016 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,7 +80,6 @@ LIBDRM_NVVIEUX_REQUIRED=2.4.66
 LIBDRM_NOUVEAU_REQUIRED=2.4.66
 LIBDRM_FREEDRENO_REQUIRED=2.4.89
 LIBDRM_ETNAVIV_REQUIRED=2.4.82
-LIBDRM_TEGRA_REQUIRED=2.4.58
 
 dnl Versions for external dependencies
 DRI2PROTO_REQUIRED=2.8
@@ -2598,7 +2597,6 @@ if test -n "$with_gallium_drivers"; then
 ;;
 xtegra)
 HAVE_GALLIUM_TEGRA=yes
-PKG_CHECK_MODULES([TEGRA], [libdrm_tegra >= 
$LIBDRM_TEGRA_REQUIRED])
 require_libdrm "tegra"
 ;;
 xswrast)
@@ -2725,6 +2723,9 @@ if test "x$HAVE_GALLIUM_VC4" != xyes -a 
"x$HAVE_GALLIUM_PL111" = xyes  ; then
 AC_MSG_ERROR([Building with pl111 requires vc4])
 fi
 
+if test "x$HAVE_GALLIUM_NOUVEAU" != xyes -a "x$HAVE_GALLIUM_TEGRA" = xyes; then
+AC_MSG_ERROR([Building with tegra requires nouveau])
+fi
 
 detect_old_buggy_llvm() {
 dnl llvm-config may not give the right answer when llvm is a built as a
diff --git a/src/gallium/drivers/tegra/Makefile.am 
b/src/gallium/drivers/tegra/Makefile.am
index 1375ee97814f..7e87ea048733 100644
--- a/src/gallium/drivers/tegra/Makefile.am
+++ b/src/gallium/drivers/tegra/Makefile.am
@@ -1,18 +1,11 @@
-AUTOMAKE_OPTIONS = subdir-objects
-
 include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CFLAGS = \
-I$(top_srcdir)/include/drm-uapi \
-   $(GALLIUM_DRIVER_CFLAGS) \
-   $(LIBUDEV_CFLAGS) \
-   $(TEGRA_CFLAGS)
+   $(GALLIUM_DRIVER_CFLAGS)
 
 noinst_LTLIBRARIES = libtegra.la
 
 libtegra_la_SOURCES = \
$(C_SOURCES)
-
-libtegra_la_LIBADD = \
-   $(LIBUDEV_LIBS)
diff --git a/src/gallium/drivers/tegra/Makefile.sources 
b/src/gallium/drivers/tegra/Makefile.sources
index 655c60ab6853..af4ff838c7ca 100644
--- a/src/gallium/drivers/tegra/Makefile.sources
+++ b/src/gallium/drivers/tegra/Makefile.sources
@@ -1,3 +1,6 @@
 C_SOURCES := \
tegra_context.c \
-   tegra_screen.c
+   tegra_context.h \
+   tegra_resource.h \
+   tegra_screen.c \
+   tegra_screen.h
diff --git a/src/gallium/drivers/tegra/tegra_context.c 
b/src/gallium/drivers/tegra/tegra_context.c
index feaa5138c95d..38e6e59b31ff 100644
--- a/src/gallium/drivers/tegra/tegra_context.c
+++ b/src/gallium/drivers/tegra/tegra_context.c
@@ -1,5 +1,5 @@
 /*
- * Copyright © 2014-2016 NVIDIA Corporation
+ * Copyright © 2014-2018 NVIDIA Corporation
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -27,9 +27,9 @@
 #include "util/u_debug.h"
 #include "util/u_inlines.h"
 
-#include "tegra/tegra_context.h"
-#include "tegra/tegra_resource.h"
-#include "tegra/tegra_screen.h"
+#include "tegra_context.h"
+#include "tegra_resource.h"
+#include "tegra_screen.h"
 
 static void
 tegra_destroy(struct pipe_context *pcontext)
diff --git a/src/gallium/drivers/tegra/tegra_context.h 
b/src/gallium/drivers/tegra/tegra_context.h
index 669ae1c0c4ab..4869b0913a6f 100644
--- a/src/gallium/drivers/tegra/tegra_context.h
+++ b/src/gallium/drivers/tegra/tegra_context.h
@@ -1,5 +1,5 @@
 /*
- * Copyright © 2014-2016 NVIDIA Corporation
+ * Copyright © 2014-2018 NVIDIA Corporation
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
diff --git a/src/gallium/drivers/tegra/tegra_resource.h 
b/src/gallium/drivers/tegra/tegra_resource.h
index 43265211be1e..67507d64590d 100644
--- a/src/gallium/drivers/tegra/tegra_resource.h
+++ b/src/gallium/drivers/tegra/tegra_resource.h
@@ -1,5 +1,5 @@
 /*
- * Copyright © 2014-2016 NVIDIA Corporation
+ * Copyright © 2014-2018 NVIDIA Corporation
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
diff --git a/src/gallium/drivers/tegr

[Mesa-dev] [PATCH] fixup! nouveau: Add framebuffer modifier support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

---
 src/gallium/drivers/nouveau/nouveau_buffer.c |  3 +-
 src/gallium/drivers/nouveau/nouveau_buffer.h |  3 +-
 src/gallium/drivers/nouveau/nouveau_screen.c | 10 ---
 src/gallium/drivers/nouveau/nv30/nv30_resource.c |  4 +-
 src/gallium/drivers/nouveau/nv50/nv50_resource.c |  5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  | 73 +++-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 85 +---
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  2 -
 8 files changed, 109 insertions(+), 76 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 73afff961115..2c604419ce05 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -636,8 +636,7 @@ const struct u_resource_vtbl nouveau_buffer_vtbl =
 
 struct pipe_resource *
 nouveau_buffer_create(struct pipe_screen *pscreen,
-  const struct pipe_resource *templ,
-  const uint64_t *modifiers, unsigned int count)
+  const struct pipe_resource *templ)
 {
struct nouveau_screen *screen = nouveau_screen(pscreen);
struct nv04_resource *buffer;
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.h 
b/src/gallium/drivers/nouveau/nouveau_buffer.h
index 466f8cc2b466..3a33fae9ce2f 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.h
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.h
@@ -89,8 +89,7 @@ nouveau_resource_mapped_by_gpu(struct pipe_resource *resource)
 
 struct pipe_resource *
 nouveau_buffer_create(struct pipe_screen *pscreen,
-  const struct pipe_resource *templ,
-  const uint64_t *modifiers, unsigned int count);
+  const struct pipe_resource *templ);
 
 struct pipe_resource *
 nouveau_user_buffer_create(struct pipe_screen *screen, void *ptr,
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index d651cc7f4b8c..b84ef13ebe7f 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -128,15 +128,6 @@ nouveau_screen_bo_from_handle(struct pipe_screen *pscreen,
return bo;
 }
 
-static uint64_t nouveau_bo_get_modifier(struct nouveau_bo *bo)
-{
-   struct nouveau_device *dev = bo->device;
-
-   if (dev->chipset >= 0xc0)
-  return nvc0_bo_get_modifier(bo);
-
-   return DRM_FORMAT_MOD_INVALID;
-}
 
 bool
 nouveau_screen_bo_get_handle(struct pipe_screen *pscreen,
@@ -144,7 +135,6 @@ nouveau_screen_bo_get_handle(struct pipe_screen *pscreen,
  unsigned stride,
  struct winsys_handle *whandle)
 {
-   whandle->modifier = nouveau_bo_get_modifier(bo);
whandle->stride = stride;
 
if (whandle->type == DRM_API_HANDLE_TYPE_SHARED) {
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_resource.c 
b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
index 38d2b2e41c30..386bd3459bd3 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_resource.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
@@ -53,11 +53,9 @@ static struct pipe_resource *
 nv30_resource_create(struct pipe_screen *pscreen,
  const struct pipe_resource *tmpl)
 {
-   const uint64_t modifier = DRM_FORMAT_MOD_INVALID;
-
switch (tmpl->target) {
case PIPE_BUFFER:
-  return nouveau_buffer_create(pscreen, tmpl, , 1);
+  return nouveau_buffer_create(pscreen, tmpl);
default:
   return nv30_miptree_create(pscreen, tmpl);
}
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_resource.c 
b/src/gallium/drivers/nouveau/nv50/nv50_resource.c
index 37592ad66349..aed8c6241d4b 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_resource.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_resource.c
@@ -1,4 +1,3 @@
-#include 
 
 #include "pipe/p_context.h"
 #include "util/u_inlines.h"
@@ -12,11 +11,9 @@ static struct pipe_resource *
 nv50_resource_create(struct pipe_screen *screen,
  const struct pipe_resource *templ)
 {
-   const uint64_t modifier = DRM_FORMAT_MOD_INVALID;
-
switch (templ->target) {
case PIPE_BUFFER:
-  return nouveau_buffer_create(screen, templ, , 1);
+  return nouveau_buffer_create(screen, templ);
default:
   return nv50_miptree_create(screen, templ);
}
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index 627d6b7346c3..7983c4030876 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -24,6 +24,7 @@
 
 #include "pipe/p_state.h"
 #include "pipe/p_defines.h"
+#include "state_tracker/drm_driver.h"
 #include "util/u_inlines.h"
 #include "util/u_format.h"
 
@@ -

Re: [Mesa-dev] [PATCH 5/5] tegra: Initial support

[Thierry Reding]

On Thu, Feb 22, 2018 at 02:31:48PM +0100, Erik Faye-Lund wrote:
> On Thu, Feb 22, 2018 at 2:23 PM, Thierry Reding
> <thierry.red...@gmail.com> wrote:
> > On Wed, Feb 21, 2018 at 05:01:02PM +, Emil Velikov wrote:
> >> Hi Thierry,
> >>
> >> On 21 February 2018 at 15:30, Thierry Reding <thierry.red...@gmail.com> 
> >> wrote:
> >> > +static const char *
> >> > +tegra_screen_get_name(struct pipe_screen *pscreen)
> >> > +{
> >> > +   return "tegra";
> >> > +}
> >> > +
> >> > +static const char *
> >> > +tegra_screen_get_vendor(struct pipe_screen *pscreen)
> >> > +{
> >> > +   return "NVIDIA";
> >> > +}
> >> > +
> >> > +static const char *
> >> > +tegra_screen_get_device_vendor(struct pipe_screen *pscreen)
> >> > +{
> >> > +   return "NVIDIA";
> >> > +}
> >> > +
> >> As-is these might be a bit fiddly, but will do for now.
> >> For example - how will devs distinguish between the closed-source
> >> driver and Mesa.
> >
> > Good point. Let me check what exactly we use in the closed-source driver
> > and then come up with a proposal.
> >
> > I think perhaps a good choice for the vendor would be "grate". Even
> > though this driver isn't part of the grate project, I'm hoping that we
> > will eventually see Erik's and Dmitry's work merged into this.
> >
> > Adding Erik and Dmitry to get their opinion.
> >
> 
> It's not entirely clear to me what the most natural boundary between
> Tegra 2/3/4 (the GPUs the grate-project targets) and Tegra K1 would
> be. The later Tegras are so fundamentally different in how they
> work...
> 
> Should they share the implementation of tegra_screen_create? From a
> quick look, it doesn't seem like it (mostly K1 specifics going on
> there, it seems), but I could be wrong. And if it shouldn't perhaps it
> should simply be a separate gallium-driver ("grate" vs "tegra"
> maybe?)... We can probably share some code, but we can do that without
> sharing the driver, just like intel, amd and broadcom does with just a
> shared folder at src/nvidia or something for utilities...
> 
> I don't know, just trying to avoid having to add too many conditionals here...

I agree with you mostly. I don't think there's a lot that could be
shared here. On the other hand, I think we can easily add the
conditionals to only a few places. We could for example have a
grate_screen_create() function that is called by tegra_screen_create()
after detecting whether or not we have a Nouveau GPU in the system (as
fallback for a tegra_open_render_node() failure). Or we could do it
earlier after checking for Tegra chip ID in sysfs, or perhaps some DT
compatible string (via the drmDevice API).

That way there is one conditional in the initial stages, but we get to
deal with less fragmentation. I think it gives users a better experience
if they just install the Tegra driver and it works regardless of whether
it runs on a Tegra20 or a Tegra124.

We have a pretty consistent experience across all Tegra generations, and
I'd really like to keep that.

All of that said, I'm not exactly sure I understand the purpose of the
vendor name here. We already have the screen name that identifies this
as a Tegra screen and we have the device vendor which identifies who
built the device. So vendor seems to me like it would be whoever
provides the driver. In this case, couldn't that just be "Mesa"?

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] tegra: Initial support

[Thierry Reding]

On Wed, Feb 21, 2018 at 05:01:02PM +, Emil Velikov wrote:
> Hi Thierry,
> 
> On 21 February 2018 at 15:30, Thierry Reding <thierry.red...@gmail.com> wrote:
> 
> > @@ -2595,6 +2596,11 @@ if test -n "$with_gallium_drivers"; then
> > ximx)
> >  HAVE_GALLIUM_IMX=yes
> >  ;;
> > +xtegra)
> > +HAVE_GALLIUM_TEGRA=yes
> > +PKG_CHECK_MODULES([TEGRA], [libdrm_tegra >= 
> > $LIBDRM_TEGRA_REQUIRED])
> > +require_libdrm "tegra"
> > +;;
> 
> Could use the following hunk just after the "... needed dependencies
> for renderonly drivers." comment.
> 
> if test "x$HAVE_GALLIUM_NOUVEAU" != xyes -a "x$HAVE_GALLIUM_TEGRA" =
> xyes  ; then
> AC_MSG_ERROR([Building with tegra requires nouveau])
> fi

Done. It also turns out that we don't need libdrm_tegra (yet), so I can
drop that, which makes it easier to build-test.

> 
> In a future patch we can:
> - add tegra to the Makefile.am DISTCHECK list

I can do that. With the libdrm_tegra dependency gone that should be no
problem. But what if we want to add it back at some point? Are people
supposed to have all the dependencies installed for a make distcheck?

> - wire up the driver with .travis

I'm not very familiar with Travis CI on Mesa. Is there a public instance
that I can check? Also, is there a way to test such a change before
pushing it to make sure we don't inadvertently break it?

Well, I guess that's kind of the point of Travis, but I means things
like making sure the .travis syntax and build dependencies are correct,
and so on.

> > index ..910cbe02d873
> > --- /dev/null
> > +++ b/include/drm-uapi/tegra_drm.h
> 
> Haven't checked this one, but I trust you picked the latest and greatest.

Yeah, this is from v4.16-rc1, though I've updated the include guards to
drop the UAPI from Linux' headers. That seemed to be what others were
doing, so hopefully that was correct.

> > --- /dev/null
> > +++ b/src/gallium/drivers/tegra/Makefile.am
> > @@ -0,0 +1,18 @@
> > +AUTOMAKE_OPTIONS = subdir-objects
> > +
> Not needed - already set at global scope.

Done.

> 
> > +include Makefile.sources
> > +include $(top_srcdir)/src/gallium/Automake.inc
> > +
> > +AM_CFLAGS = \
> > +   -I$(top_srcdir)/include/drm-uapi \
> > +   $(GALLIUM_DRIVER_CFLAGS) \
> > +   $(LIBUDEV_CFLAGS) \
> libudev is gone.

Done. I also removed the TEGRA_CFLAGS which is not (yet) needed.

> 
> > +
> > +noinst_LTLIBRARIES = libtegra.la
> > +
> > +libtegra_la_SOURCES = \
> > +   $(C_SOURCES)
> > +
> > +libtegra_la_LIBADD = \
> > +   $(LIBUDEV_LIBS)
> Ditto.

Done.

> 
> 
> > --- /dev/null
> > +++ b/src/gallium/drivers/tegra/Makefile.sources
> > @@ -0,0 +1,3 @@
> > +C_SOURCES := \
> > +   tegra_context.c \
> > +   tegra_screen.c
> 
> Please include the following to as well.
> tegra_context.h
> tegra_resource.h

Done.

> > index ..feaa5138c95d
> > --- /dev/null
> > +++ b/src/gallium/drivers/tegra/tegra_context.c
> 
> > +#include "tegra/tegra_context.h"
> > +#include "tegra/tegra_resource.h"
> > +#include "tegra/tegra_screen.h"
> > +
> The "tegra/" prefix isn't needed - it doesn't hurt though.

Removed.

> > --- /dev/null
> > +++ b/src/gallium/drivers/tegra/tegra_screen.c
> 
> > +#include "tegra/tegra_context.h"
> > +#include "tegra/tegra_resource.h"
> > +#include "tegra/tegra_screen.h"
> > +
> Ditto.

Removed.

> > +static const char *
> > +tegra_screen_get_name(struct pipe_screen *pscreen)
> > +{
> > +   return "tegra";
> > +}
> > +
> > +static const char *
> > +tegra_screen_get_vendor(struct pipe_screen *pscreen)
> > +{
> > +   return "NVIDIA";
> > +}
> > +
> > +static const char *
> > +tegra_screen_get_device_vendor(struct pipe_screen *pscreen)
> > +{
> > +   return "NVIDIA";
> > +}
> > +
> As-is these might be a bit fiddly, but will do for now.
> For example - how will devs distinguish between the closed-source
> driver and Mesa.

Good point. Let me check what exactly we use in the closed-source driver
and then come up with a proposal.

I think perhaps a good choice for the vendor would be "grate". Even
though this driver isn't part of the grate project, I'm hoping that we
will eventually see Erik's and Dmitry's work merged into this.

Adding Erik and Dmitry to get their 

Re: [Mesa-dev] [PATCH 4/5] nouveau: Add framebuffer modifier support

[Thierry Reding]

On Wed, Feb 21, 2018 at 04:37:45PM +, Emil Velikov wrote:
> Hi Thierry,
> 
> On 21 February 2018 at 15:30, Thierry Reding <thierry.red...@gmail.com> wrote:
> 
> >
> >  struct pipe_resource *
> >  nouveau_buffer_create(struct pipe_screen *pscreen,
> > -  const struct pipe_resource *templ);
> > +  const struct pipe_resource *templ,
> > +  const uint64_t *modifiers, unsigned int count);
> >
> The extra arguments seem unused. I guess it's a left-over from earlier
> iteration?
> Or perhaps you have extra patches that depend on this?

I don't exactly recall why I added those. I guess I must've thought that
the call to nouveau_buffer_create() should be symmetric with the call to
nvc0_miptree_create().

But you're right, I don't think it makes sense to have modifiers for
PIPE_BUFFER, so I'll drop these.

> 
> 
> >  struct pipe_resource *
> >  nouveau_user_buffer_create(struct pipe_screen *screen, void *ptr,
> > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
> > b/src/gallium/drivers/nouveau/nouveau_screen.c
> > index c144b39b2dd2..d651cc7f4b8c 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_screen.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
> > @@ -1,3 +1,5 @@
> > +#include 
> > +
> >  #include "pipe/p_defines.h"
> >  #include "pipe/p_screen.h"
> >  #include "pipe/p_state.h"
> > @@ -23,6 +25,8 @@
> >  #include "nouveau_mm.h"
> >  #include "nouveau_buffer.h"
> >
> > +#include "nvc0/nvc0_resource.h"
> > +
> > +static uint64_t nouveau_bo_get_modifier(struct nouveau_bo *bo)
> > +{
> > +   struct nouveau_device *dev = bo->device;
> > +
> > +   if (dev->chipset >= 0xc0)
> > +  return nvc0_bo_get_modifier(bo);
> > +
> > +   return DRM_FORMAT_MOD_INVALID;
> > +}
> >
> Normally the backends (include and) call into the core nouveau code.
> Calling In the opposite direction is achieved via vfuncs, IIRC.

I think I've figured out a much nicer way to fix this (see also my reply
to Ilia's comment). I'll follow up with a patch to show what I mean.

> 
> 
> > switch (templ->target) {
> > case PIPE_BUFFER:
> > -  return nouveau_buffer_create(screen, templ);
> > +  return nouveau_buffer_create(screen, templ, , 1);
> > default:
> >return nv50_miptree_create(screen, templ);
> > }
> > diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
> > b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
> > index 27674f72a7c0..627d6b7346c3 100644
> > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
> > +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
> > @@ -20,6 +20,8 @@
> >   * OTHER DEALINGS IN THE SOFTWARE.
> >   */
> >
> > +#include 
> > +
> >  #include "pipe/p_state.h"
> >  #include "pipe/p_defines.h"
> >  #include "util/u_inlines.h"
> > @@ -244,7 +246,8 @@ const struct u_resource_vtbl nvc0_miptree_vtbl =
> >
> >  struct pipe_resource *
> >  nvc0_miptree_create(struct pipe_screen *pscreen,
> > -const struct pipe_resource *templ)
> > +const struct pipe_resource *templ,
> > +const uint64_t *modifiers, unsigned int count)
> >  {
> > struct nouveau_device *dev = nouveau_screen(pscreen)->device;
> > struct nouveau_drm *drm = nouveau_screen(pscreen)->drm;
> > @@ -277,6 +280,9 @@ nvc0_miptree_create(struct pipe_screen *pscreen,
> >}
> > }
> >
> > +   if (count == 1 && modifiers[0] == DRM_FORMAT_MOD_LINEAR)
> > +  pt->flags |= NOUVEAU_RESOURCE_FLAG_LINEAR;
> > +
> Through the patch count 1 + DRM_FORMAT_MOD_INVALID is used, yet
> DRM_FORMAT_MOD_LINEAR is checked above.
> Am I having a silly moment and those should be the same or ?

count == 1 and DRM_FORMAT_MOD_INVALID is used in those cases where we
don't care about modifiers.

In this case, however, the idea is that if we're passed in a single
modifier that happens to be DRM_FORMAT_MOD_LINEAR, we do want to make
sure that we're getting a pitch-linear buffer because it's been
requested.

Note that this is a somewhat minimal way of dealing with modifiers. To
be correct we'd have to pass along exactly the modifiers that we got in
the list. For example a caller could pass a list of block-linear
modifiers with different block heights each, in order of priority. That
is something which we would then have to use to override the values
chosen by nvc0_tex_cho

Re: [Mesa-dev] [PATCH 4/5] nouveau: Add framebuffer modifier support

[Thierry Reding]

On Wed, Feb 21, 2018 at 11:05:45AM -0500, Ilia Mirkin wrote:
> On Wed, Feb 21, 2018 at 10:30 AM, Thierry Reding
> <thierry.red...@gmail.com> wrote:
> > From: Thierry Reding <tred...@nvidia.com>
> >
> > This adds support for framebuffer modifiers to Nouveau. This will be
> > used by the Tegra driver to share metadata about the format of buffers
> > (such as the tiling mode or compression).
> >
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> >  src/gallium/drivers/nouveau/Android.mk   |  3 +
> >  src/gallium/drivers/nouveau/Makefile.am  |  1 +
> >  src/gallium/drivers/nouveau/nouveau_buffer.c |  3 +-
> >  src/gallium/drivers/nouveau/nouveau_buffer.h |  3 +-
> >  src/gallium/drivers/nouveau/nouveau_screen.c | 14 +
> >  src/gallium/drivers/nouveau/nv30/nv30_resource.c |  6 +-
> >  src/gallium/drivers/nouveau/nv50/nv50_resource.c |  5 +-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  |  8 ++-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 80 
> > +++-
> >  src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  5 +-
> >  10 files changed, 120 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/Android.mk 
> > b/src/gallium/drivers/nouveau/Android.mk
> > index 2de22e73ec18..a446774a86e8 100644
> > --- a/src/gallium/drivers/nouveau/Android.mk
> > +++ b/src/gallium/drivers/nouveau/Android.mk
> > @@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
> > $(NVC0_CODEGEN_SOURCES) \
> > $(NVC0_C_SOURCES)
> >
> > +LOCAL_C_INCLUDES := \
> > +   $(MESA_TOP)/include/drm-uapi
> > +
> >  LOCAL_SHARED_LIBRARIES := libdrm_nouveau
> >  LOCAL_MODULE := libmesa_pipe_nouveau
> >
> > diff --git a/src/gallium/drivers/nouveau/Makefile.am 
> > b/src/gallium/drivers/nouveau/Makefile.am
> > index 91547178e397..f6126b544811 100644
> > --- a/src/gallium/drivers/nouveau/Makefile.am
> > +++ b/src/gallium/drivers/nouveau/Makefile.am
> > @@ -24,6 +24,7 @@ include Makefile.sources
> >  include $(top_srcdir)/src/gallium/Automake.inc
> >
> >  AM_CPPFLAGS = \
> > +   -I$(top_srcdir)/include/drm-uapi \
> > $(GALLIUM_DRIVER_CFLAGS) \
> > $(LIBDRM_CFLAGS) \
> > $(NOUVEAU_CFLAGS)
> > diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
> > b/src/gallium/drivers/nouveau/nouveau_buffer.c
> > index 2c604419ce05..73afff961115 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_buffer.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
> > @@ -636,7 +636,8 @@ const struct u_resource_vtbl nouveau_buffer_vtbl =
> >
> >  struct pipe_resource *
> >  nouveau_buffer_create(struct pipe_screen *pscreen,
> > -  const struct pipe_resource *templ)
> > +  const struct pipe_resource *templ,
> > +  const uint64_t *modifiers, unsigned int count)
> >  {
> > struct nouveau_screen *screen = nouveau_screen(pscreen);
> > struct nv04_resource *buffer;
> > diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.h 
> > b/src/gallium/drivers/nouveau/nouveau_buffer.h
> > index 3a33fae9ce2f..466f8cc2b466 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_buffer.h
> > +++ b/src/gallium/drivers/nouveau/nouveau_buffer.h
> > @@ -89,7 +89,8 @@ nouveau_resource_mapped_by_gpu(struct pipe_resource 
> > *resource)
> >
> >  struct pipe_resource *
> >  nouveau_buffer_create(struct pipe_screen *pscreen,
> > -  const struct pipe_resource *templ);
> > +  const struct pipe_resource *templ,
> > +  const uint64_t *modifiers, unsigned int count);
> >
> >  struct pipe_resource *
> >  nouveau_user_buffer_create(struct pipe_screen *screen, void *ptr,
> > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
> > b/src/gallium/drivers/nouveau/nouveau_screen.c
> > index c144b39b2dd2..d651cc7f4b8c 100644
> > --- a/src/gallium/drivers/nouveau/nouveau_screen.c
> > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
> > @@ -1,3 +1,5 @@
> > +#include 
> > +
> >  #include "pipe/p_defines.h"
> >  #include "pipe/p_screen.h"
> >  #include "pipe/p_state.h"
> > @@ -23,6 +25,8 @@
> >  #include "nouveau_mm.h"
> >  #include "nouveau_buffer.h"
> >
> > +#include "nvc0/nvc0_resource.h"
> > +
> >  /* XXX this should go away */
> >  #include "state_

[Mesa-dev] [PATCH 5/5] tegra: Initial support

[Thierry Reding]

Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
But the GPU is a pure render node and has no display engine, hence the
scanout needs to happen on the Tegra display hardware. The GPU and the
display engine each have a separate DRM device node exposed by the
kernel.

To make the setup appear as a single device, this driver instantiates
a Nouveau screen with each instance of a Tegra screen and forwards GPU
requests to the Nouveau screen. For purposes of scanout it will import
buffers created on the GPU into the display driver. Handles that
userspace requests are those of the display driver so that they can be
used to create framebuffers.

This has been tested with some GBM test programs, as well as kmscube and
weston. All of those run without modifications, but I'm sure there is a
lot that can be improved.

Some fixes contributed by Hector Martin <mar...@marcan.st>.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 configure.ac   |   11 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   18 +
 src/gallium/drivers/tegra/Makefile.sources |3 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1294 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  674 ++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   11 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   33 +
 26 files changed, 2648 insertions(+), 4 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

diff --git a/configure.ac b/configure.ac
index 8a9172690a87..7f83fb9ee17e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,6 +80,7 @@ LIBDRM_NVVIEUX_REQUIRED=2.4.66
 LIBDRM_NOUVEAU_REQUIRED=2.4.66
 LIBDRM_FREEDRENO_REQUIRED=2.4.89
 LIBDRM_ETNAVIV_REQUIRED=2.4.82
+LIBDRM_TEGRA_REQUIRED=2.4.58
 
 dnl Versions for external dependencies
 DRI2PROTO_REQUIRED=2.8
@@ -1350,7 +1351,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
 AC_ARG_WITH([gallium-drivers],
 [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
 [comma delimited Gallium drivers list, e.g.
-
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,vc4,vc5,virgl,etnaviv,imx"
+
"i915,nouveau,r300,r600,radeonsi,freedreno,pl111,svga,swrast,swr,tegra,vc4,vc5,virgl,etnaviv,imx"
 @<:@default=r300,r600,svga,swrast@:>@])],
 [with_gallium_drivers="$withval"],
 [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
@@ -2595,6 +2596,11 @@ if test -n "$with_gallium_drivers"; then
ximx)
 HAVE_GALLIUM_IMX=yes
 ;;
+xtegra)
+HAVE_GALLIUM_TEGRA=yes
+PKG_CHECK_MODULES([TEGRA], [libdrm_tegra >= 
$LIBDRM_TEGRA_REQUIRED])
+require_libdrm "tegra"
+;;
 xswrast)
 HAVE_GALLIUM_SOFTPIPE=yes
 if test

[Mesa-dev] [PATCH 3/5] nouveau/nvc0: Extract common tile mode macro

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Add a new macro that can be used to extract the tiling mode from a
tile_mode value. This is will be used to determine the number of GOBs
used in block linear mode.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
index 0d5f026d6e1c..c68a50948360 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.h
@@ -6,14 +6,17 @@
 
 #define NVC0_RESOURCE_FLAG_VIDEO (NOUVEAU_RESOURCE_FLAG_DRV_PRIV << 0)
 
+#define NVC0_TILE_MODE_X(m) (((m) >> 0) & 0xf)
+#define NVC0_TILE_MODE_Y(m) (((m) >> 4) & 0xf)
+#define NVC0_TILE_MODE_Z(m) (((m) >> 8) & 0xf)
 
-#define NVC0_TILE_SHIFT_X(m) m) >> 0) & 0xf) + 6)
-#define NVC0_TILE_SHIFT_Y(m) m) >> 4) & 0xf) + 3)
-#define NVC0_TILE_SHIFT_Z(m) m) >> 8) & 0xf) + 0)
+#define NVC0_TILE_SHIFT_X(m) (NVC0_TILE_MODE_X(m) + 6)
+#define NVC0_TILE_SHIFT_Y(m) (NVC0_TILE_MODE_Y(m) + 3)
+#define NVC0_TILE_SHIFT_Z(m) (NVC0_TILE_MODE_Z(m) + 0)
 
-#define NVC0_TILE_SIZE_X(m) (64 << (((m) >> 0) & 0xf))
-#define NVC0_TILE_SIZE_Y(m) ( 8 << (((m) >> 4) & 0xf))
-#define NVC0_TILE_SIZE_Z(m) ( 1 << (((m) >> 8) & 0xf))
+#define NVC0_TILE_SIZE_X(m) (64 << NVC0_TILE_MODE_X(m))
+#define NVC0_TILE_SIZE_Y(m) ( 8 << NVC0_TILE_MODE_Y(m))
+#define NVC0_TILE_SIZE_Z(m) ( 1 << NVC0_TILE_MODE_Z(m))
 
 /* it's ok to mask only in the end because max value is 3 * 5 */
 
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/5] nouveau: Add framebuffer modifier support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This adds support for framebuffer modifiers to Nouveau. This will be
used by the Tegra driver to share metadata about the format of buffers
(such as the tiling mode or compression).

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/gallium/drivers/nouveau/Android.mk   |  3 +
 src/gallium/drivers/nouveau/Makefile.am  |  1 +
 src/gallium/drivers/nouveau/nouveau_buffer.c |  3 +-
 src/gallium/drivers/nouveau/nouveau_buffer.h |  3 +-
 src/gallium/drivers/nouveau/nouveau_screen.c | 14 +
 src/gallium/drivers/nouveau/nv30/nv30_resource.c |  6 +-
 src/gallium/drivers/nouveau/nv50/nv50_resource.c |  5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c  |  8 ++-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 80 +++-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h |  5 +-
 10 files changed, 120 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/nouveau/Android.mk 
b/src/gallium/drivers/nouveau/Android.mk
index 2de22e73ec18..a446774a86e8 100644
--- a/src/gallium/drivers/nouveau/Android.mk
+++ b/src/gallium/drivers/nouveau/Android.mk
@@ -36,6 +36,9 @@ LOCAL_SRC_FILES := \
$(NVC0_CODEGEN_SOURCES) \
$(NVC0_C_SOURCES)
 
+LOCAL_C_INCLUDES := \
+   $(MESA_TOP)/include/drm-uapi
+
 LOCAL_SHARED_LIBRARIES := libdrm_nouveau
 LOCAL_MODULE := libmesa_pipe_nouveau
 
diff --git a/src/gallium/drivers/nouveau/Makefile.am 
b/src/gallium/drivers/nouveau/Makefile.am
index 91547178e397..f6126b544811 100644
--- a/src/gallium/drivers/nouveau/Makefile.am
+++ b/src/gallium/drivers/nouveau/Makefile.am
@@ -24,6 +24,7 @@ include Makefile.sources
 include $(top_srcdir)/src/gallium/Automake.inc
 
 AM_CPPFLAGS = \
+   -I$(top_srcdir)/include/drm-uapi \
$(GALLIUM_DRIVER_CFLAGS) \
$(LIBDRM_CFLAGS) \
$(NOUVEAU_CFLAGS)
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 2c604419ce05..73afff961115 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -636,7 +636,8 @@ const struct u_resource_vtbl nouveau_buffer_vtbl =
 
 struct pipe_resource *
 nouveau_buffer_create(struct pipe_screen *pscreen,
-  const struct pipe_resource *templ)
+  const struct pipe_resource *templ,
+  const uint64_t *modifiers, unsigned int count)
 {
struct nouveau_screen *screen = nouveau_screen(pscreen);
struct nv04_resource *buffer;
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.h 
b/src/gallium/drivers/nouveau/nouveau_buffer.h
index 3a33fae9ce2f..466f8cc2b466 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.h
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.h
@@ -89,7 +89,8 @@ nouveau_resource_mapped_by_gpu(struct pipe_resource *resource)
 
 struct pipe_resource *
 nouveau_buffer_create(struct pipe_screen *pscreen,
-  const struct pipe_resource *templ);
+  const struct pipe_resource *templ,
+  const uint64_t *modifiers, unsigned int count);
 
 struct pipe_resource *
 nouveau_user_buffer_create(struct pipe_screen *screen, void *ptr,
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index c144b39b2dd2..d651cc7f4b8c 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -1,3 +1,5 @@
+#include 
+
 #include "pipe/p_defines.h"
 #include "pipe/p_screen.h"
 #include "pipe/p_state.h"
@@ -23,6 +25,8 @@
 #include "nouveau_mm.h"
 #include "nouveau_buffer.h"
 
+#include "nvc0/nvc0_resource.h"
+
 /* XXX this should go away */
 #include "state_tracker/drm_driver.h"
 
@@ -124,6 +128,15 @@ nouveau_screen_bo_from_handle(struct pipe_screen *pscreen,
return bo;
 }
 
+static uint64_t nouveau_bo_get_modifier(struct nouveau_bo *bo)
+{
+   struct nouveau_device *dev = bo->device;
+
+   if (dev->chipset >= 0xc0)
+  return nvc0_bo_get_modifier(bo);
+
+   return DRM_FORMAT_MOD_INVALID;
+}
 
 bool
 nouveau_screen_bo_get_handle(struct pipe_screen *pscreen,
@@ -131,6 +144,7 @@ nouveau_screen_bo_get_handle(struct pipe_screen *pscreen,
  unsigned stride,
  struct winsys_handle *whandle)
 {
+   whandle->modifier = nouveau_bo_get_modifier(bo);
whandle->stride = stride;
 
if (whandle->type == DRM_API_HANDLE_TYPE_SHARED) {
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_resource.c 
b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
index ff34f6e5f9fa..38d2b2e41c30 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_resource.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_resource.c
@@ -23,6 +23,8 @@
  *
  */
 
+#include 
+
 #include "util/u_format.h"
 #include "uti

[Mesa-dev] [PATCH 2/5] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

This is based on commit 268892cb63a822315921a8dab48ac3e4abf7dd03 from
Linux v4.16-rc1.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index a76ed8f9e383..e04613d30a13 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -178,7 +178,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
-#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
@@ -338,29 +338,17 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
-/* NVIDIA Tegra frame buffer modifiers */
-
-/*
- * Some modifiers take parameters, for example the number of vertical GOBs in
- * a block. Reserve the lower 32 bits for parameters
- */
-#define __fourcc_mod_tegra_mode_shift 32
-#define fourcc_mod_tegra_code(val, params) \
-   fourcc_mod_code(NV, __u64)val) << __fourcc_mod_tegra_mode_shift) | 
params))
-#define fourcc_mod_tegra_mod(m) \
-   (m & ~((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
-#define fourcc_mod_tegra_param(m) \
-   (m & ((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
+/* NVIDIA frame buffer modifiers */
 
 /*
  * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
  *
  * Pixels are arranged in simple tiles of 16 x 16 bytes.
  */
-#define NV_FORMAT_MOD_TEGRA_TILED fourcc_mod_tegra_code(1, 0)
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
 
 /*
- * Tegra 16Bx2 Block Linear layout, used by TK1/TX1
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
  *
  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
@@ -380,7 +368,21 @@ extern "C" {
  * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
  * in full detail.
  */
-#define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+   fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+   fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+   fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+   fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+   fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x15)
 
 /*
  * Broadcom VC4 "T" format
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/5] NVIDIA Tegra support

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

This series of patches implements initial support for Tegra. The first
two patches import DRM UAPI from v4.16-rc1 that provide framebuffer
modifiers that can be used to specify buffers shared between Nouveau
and the Tegra DRM driver.

Patches 3 and 4 add support for framebuffer modifiers to Nouveau and
patch 5 build on top of those to provide initial Tegra support in Mesa.
The current patches allow running common use-cases such as Wayland,
kmscube, etc.

Some people have been using earlier versions of these patches to run a
completely open-source graphics stack on various Tegra210 devices. I've
Cc'ed some of them so that they can provide feedback.

This series is also available in a git repository here:

https://cgit.freedesktop.org/~tagr/mesa #master

though that also contains the Nouveau syncfd patches that are still work
in progress and which require new kernel/userspace ABI. The patches here
work on top of a vanilla recent (v4.16-rc1) Linux kernel.

Thierry

Thierry Reding (5):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers
  nouveau/nvc0: Extract common tile mode macro
  nouveau: Add framebuffer modifier support
  tegra: Initial support

 configure.ac   |   11 +-
 include/drm-uapi/drm_fourcc.h  |   38 +-
 include/drm-uapi/tegra_drm.h   |  225 
 meson.build|7 +-
 src/gallium/Makefile.am|5 +
 .../auxiliary/pipe-loader/pipe_loader_drm.c|7 +-
 src/gallium/auxiliary/target-helpers/drm_helper.h  |   23 +
 .../auxiliary/target-helpers/drm_helper_public.h   |3 +
 src/gallium/drivers/nouveau/Android.mk |3 +
 src/gallium/drivers/nouveau/Makefile.am|1 +
 src/gallium/drivers/nouveau/nouveau_buffer.c   |3 +-
 src/gallium/drivers/nouveau/nouveau_buffer.h   |3 +-
 src/gallium/drivers/nouveau/nouveau_screen.c   |   14 +
 src/gallium/drivers/nouveau/nv30/nv30_resource.c   |6 +-
 src/gallium/drivers/nouveau/nv50/nv50_resource.c   |5 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|8 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c   |   80 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.h   |   20 +-
 src/gallium/drivers/tegra/Automake.inc |   11 +
 src/gallium/drivers/tegra/Makefile.am  |   18 +
 src/gallium/drivers/tegra/Makefile.sources |3 +
 src/gallium/drivers/tegra/meson.build  |   41 +
 src/gallium/drivers/tegra/tegra_context.c  | 1294 
 src/gallium/drivers/tegra/tegra_context.h  |   81 ++
 src/gallium/drivers/tegra/tegra_resource.h |   76 ++
 src/gallium/drivers/tegra/tegra_screen.c   |  674 ++
 src/gallium/drivers/tegra/tegra_screen.h   |   45 +
 src/gallium/meson.build|6 +
 src/gallium/targets/dri/Makefile.am|2 +
 src/gallium/targets/dri/meson.build|4 +-
 src/gallium/targets/dri/target.c   |4 +
 src/gallium/targets/vdpau/Makefile.am  |2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |   11 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |2 +
 src/gallium/winsys/tegra/drm/meson.build   |   33 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|   31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|   33 +
 37 files changed, 2797 insertions(+), 36 deletions(-)
 create mode 100644 include/drm-uapi/tegra_drm.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/meson.build
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/meson.build
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/5] drm/fourcc: Fix fourcc_mod_code() definition

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Avoid a compiler warnings when the val parameter is an expression.

This is based on commit 5843f4e02fbe86a59981e35adc6cabebee46fdc0 from
Linux v4.16-rc1.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm-uapi/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
index 3ad838d3f93f..a76ed8f9e383 100644
--- a/include/drm-uapi/drm_fourcc.h
+++ b/include/drm-uapi/drm_fourcc.h
@@ -188,7 +188,7 @@ extern "C" {
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
 
 #define fourcc_mod_code(vendor, val) \
-   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 
0x00ffULL))
 
 /*
  * Format Modifier tokens:
-- 
2.16.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH libdrm 1/2] drm/fourcc: Fix fourcc_mod_code() definition

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Avoid compiler warnings when the val parameter is an expression.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 3ad838d3f93f..a76ed8f9e383 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -188,7 +188,7 @@ extern "C" {
 #define DRM_FORMAT_RESERVED  ((1ULL << 56) - 1)
 
 #define fourcc_mod_code(vendor, val) \
-   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 
0x00ffULL))
 
 /*
  * Format Modifier tokens:
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH libdrm 0/2] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

These UABI changes have now been merged into drm-next, so synchronize
the libdrm headers and fixup the format modifiers in modetest.

Thierry

Thierry Reding (2):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers

 include/drm/drm_fourcc.h  | 38 --
 tests/modetest/modetest.c | 28 ++--
 2 files changed, 34 insertions(+), 32 deletions(-)

-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH libdrm 2/2] drm/tegra: Sanitize format modifiers

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:

  - The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
  - The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
  - Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
  - The vendor prefix NV is somewhat ambiguous.

Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.

Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 include/drm/drm_fourcc.h  | 36 +++-
 tests/modetest/modetest.c | 28 ++--
 2 files changed, 33 insertions(+), 31 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index a76ed8f9e383..e04613d30a13 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -178,7 +178,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
-#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_NVIDIA  0x03
 #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
 #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
 #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
@@ -338,29 +338,17 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
 
-/* NVIDIA Tegra frame buffer modifiers */
-
-/*
- * Some modifiers take parameters, for example the number of vertical GOBs in
- * a block. Reserve the lower 32 bits for parameters
- */
-#define __fourcc_mod_tegra_mode_shift 32
-#define fourcc_mod_tegra_code(val, params) \
-   fourcc_mod_code(NV, __u64)val) << __fourcc_mod_tegra_mode_shift) | 
params))
-#define fourcc_mod_tegra_mod(m) \
-   (m & ~((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
-#define fourcc_mod_tegra_param(m) \
-   (m & ((1ULL << __fourcc_mod_tegra_mode_shift) - 1))
+/* NVIDIA frame buffer modifiers */
 
 /*
  * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
  *
  * Pixels are arranged in simple tiles of 16 x 16 bytes.
  */
-#define NV_FORMAT_MOD_TEGRA_TILED fourcc_mod_tegra_code(1, 0)
+#define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
 
 /*
- * Tegra 16Bx2 Block Linear layout, used by TK1/TX1
+ * 16Bx2 Block Linear layout, used by desktop GPUs, and Tegra K1 and later
  *
  * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
  * vertically by a power of 2 (1 to 32 GOBs) to form a block.
@@ -380,7 +368,21 @@ extern "C" {
  * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
  * in full detail.
  */
-#define NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(v) fourcc_mod_tegra_code(2, v)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
+   fourcc_mod_code(NVIDIA, 0x10 | ((v) & 0xf))
+
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
+   fourcc_mod_code(NVIDIA, 0x10)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x11)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
+   fourcc_mod_code(NVIDIA, 0x12)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
+   fourcc_mod_code(NVIDIA, 0x13)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
+   fourcc_mod_code(NVIDIA, 0x14)
+#define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
+   fourcc_mod_code(NVIDIA, 0x15)
 
 /*
  * Broadcom VC4 "T" format
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 62d933272423..701547f4b648 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -278,20 +278,20 @@ static const char *modifier_to_string(uint64_t modifier)
return "VIVANTE_SPLIT_TILED";
case DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED:
return "VIVANTE_SPLIT_SUPER_TILED";
-   case NV_FORMAT_MOD_TEGRA_TILED:
-   return "MOD_TEGRA_TILED";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(0):
-   return "MOD_TEGRA_16BX2_BLOCK(0)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(1):
-   return "MOD_TEGRA_16BX2_BLOCK(1)";
-   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(2):
-   return "MOD_TEGRA_16BX2_BLOCK(2)";
-   case NV_FORMAT_M

[Mesa-dev] [PATCH] nouveau: Support fence FDs

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Implements fence FDs based on new libdrm API and the accompanying IOCTL.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
For the kernel patches that add the new IOCTL, see the series at:

https://patchwork.freedesktop.org/series/36361/

The libdrm patch that adds the new API is here:

https://patchwork.freedesktop.org/series/36366/

 src/gallium/drivers/nouveau/nouveau_context.h   |  5 
 src/gallium/drivers/nouveau/nouveau_fence.c | 18 ++---
 src/gallium/drivers/nouveau/nouveau_fence.h |  2 ++
 src/gallium/drivers/nouveau/nouveau_screen.c| 36 +
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 18 ++---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  2 +-
 6 files changed, 73 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_context.h 
b/src/gallium/drivers/nouveau/nouveau_context.h
index c3bbb11bd604..0e40ad2f1046 100644
--- a/src/gallium/drivers/nouveau/nouveau_context.h
+++ b/src/gallium/drivers/nouveau/nouveau_context.h
@@ -54,6 +54,8 @@ struct nouveau_context {
   uint32_t buf_cache_count;
   uint32_t buf_cache_frame;
} stats;
+
+   int in_fence_fd;
 };
 
 static inline struct nouveau_context *
@@ -99,6 +101,9 @@ nouveau_context_destroy(struct nouveau_context *ctx)
   if (ctx->scratch.bo[i])
  nouveau_bo_ref(NULL, >scratch.bo[i]);
 
+   if (ctx->in_fence_fd >= 0)
+  close(ctx->in_fence_fd);
+
FREE(ctx);
 }
 
diff --git a/src/gallium/drivers/nouveau/nouveau_fence.c 
b/src/gallium/drivers/nouveau/nouveau_fence.c
index d14c59b2dd15..b508b9b7163f 100644
--- a/src/gallium/drivers/nouveau/nouveau_fence.c
+++ b/src/gallium/drivers/nouveau/nouveau_fence.c
@@ -30,7 +30,8 @@
 #endif
 
 bool
-nouveau_fence_new(struct nouveau_screen *screen, struct nouveau_fence **fence)
+nouveau_fence_fd(struct nouveau_screen *screen, struct nouveau_fence **fence,
+ int fd)
 {
*fence = CALLOC_STRUCT(nouveau_fence);
if (!*fence)
@@ -38,11 +39,18 @@ nouveau_fence_new(struct nouveau_screen *screen, struct 
nouveau_fence **fence)
 
(*fence)->screen = screen;
(*fence)->ref = 1;
+   (*fence)->fd = dup(fd);
LIST_INITHEAD(&(*fence)->work);
 
return true;
 }
 
+bool
+nouveau_fence_new(struct nouveau_screen *screen, struct nouveau_fence **fence)
+{
+   return nouveau_fence_fd(screen, fence, -1);
+}
+
 static void
 nouveau_fence_trigger_work(struct nouveau_fence *fence)
 {
@@ -105,6 +113,9 @@ nouveau_fence_del(struct nouveau_fence *fence)
   nouveau_fence_trigger_work(fence);
}
 
+   if (fence->fd >= 0)
+  close(fence->fd);
+
FREE(fence);
 }
 
@@ -175,9 +186,10 @@ nouveau_fence_kick(struct nouveau_fence *fence)
  nouveau_fence_emit(fence);
}
 
-   if (fence->state < NOUVEAU_FENCE_STATE_FLUSHED)
-  if (nouveau_pushbuf_kick(screen->pushbuf, screen->pushbuf->channel))
+   if (fence->state < NOUVEAU_FENCE_STATE_FLUSHED) {
+  if (nouveau_pushbuf_kick_fence(screen->pushbuf, 
screen->pushbuf->channel, >fd))
  return false;
+   }
 
if (fence == screen->fence.current)
   nouveau_fence_next(screen);
diff --git a/src/gallium/drivers/nouveau/nouveau_fence.h 
b/src/gallium/drivers/nouveau/nouveau_fence.h
index e14572bce8f9..83a33c5af24b 100644
--- a/src/gallium/drivers/nouveau/nouveau_fence.h
+++ b/src/gallium/drivers/nouveau/nouveau_fence.h
@@ -24,6 +24,7 @@ struct nouveau_fence {
struct nouveau_screen *screen;
int state;
int ref;
+   int fd;
uint32_t sequence;
uint32_t work_count;
struct list_head work;
@@ -32,6 +33,7 @@ struct nouveau_fence {
 void nouveau_fence_emit(struct nouveau_fence *);
 void nouveau_fence_del(struct nouveau_fence *);
 
+bool nouveau_fence_fd(struct nouveau_screen *, struct nouveau_fence **, int);
 bool nouveau_fence_new(struct nouveau_screen *, struct nouveau_fence **);
 bool nouveau_fence_work(struct nouveau_fence *, void (*)(void *), void *);
 void nouveau_fence_update(struct nouveau_screen *, bool flushed);
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index c144b39b2dd2..f40932b5defe 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -1,3 +1,5 @@
+#include 
+
 #include "pipe/p_defines.h"
 #include "pipe/p_screen.h"
 #include "pipe/p_state.h"
@@ -86,6 +88,14 @@ nouveau_screen_fence_finish(struct pipe_screen *screen,
return nouveau_fence_wait(nouveau_fence(pfence), NULL);
 }
 
+static int
+nouveau_screen_fence_get_fd(struct pipe_screen *screen,
+struct pipe_fence_handle *pfence)
+{
+   struct nouveau_fence *fence = nouveau_fence(pfence);
+
+   return dup(fence->fd);
+}
 
 struct nouveau_bo *
 nouveau_screen_bo_from_handle(struct pipe_screen *p

Re: [Mesa-dev] [PATCH v2 3/3] imx: gallium driver for imx-drm scanout driver

[Thierry Reding]

On Fri, Dec 23, 2016 at 11:04:51PM +0100, Christian Gmeiner wrote:
[...]
> +struct pipe_screen *imx_drm_screen_create(int fd)
> +{
> +   struct renderonly ro = {
> +  .create_for_resource = renderonly_create_kms_dumb_buffer_for_resource,
> +  .kms_fd = fd,
> +  .gpu_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC)
> +   };
> +
> +   if (ro.gpu_fd < 0)
> +  return NULL;
> +
> +   struct pipe_screen *screen = etna_drm_screen_create_renderonly();
> +   if (!screen)
> +  close(ro.gpu_fd);
> +
> +   return screen;
> +}

So while trying to port Tegra to this renderonly library, I realized
that we're not going to be able to use this for Tegra after all. It
should work, and I'm going to go through with the port just for the
sake of testing, for the specific use-case of hooking up the GPU and
the scanout device.

However there's some work being done to implement functionality for
other Tegra units within Mesa, which is going to make this a bit of
a showstopper.

To be more specific: in the above, the imx-drm driver returns the screen
associated with the etnaviv render node, rather than a full wrapper for
the KMS file descriptor. That's effectively what allows you to have this
work without jumping through extra hoops since it will cause DRI3 and
Wayland to properly set up the driver for clients.

For Tegra, however, we're going to need a beefier wrapper in order to
multiplex between the GPU and other units, such as the VIC, NVENC or
NVDEC.

Emil, my recollection is that you had fairly strong objections to the
initial proposal of a full-blown wrapper for Tegra. In light of the
above I don't think we can avoid it forever, though.

I guess a good way forward would be to add a very thin driver for Tegra,
similar to what Christian has done for i.MX and move to a more flexible
solution later on when work for VIC/NVENC/NVDEC becomes ready. The most
obvious advantage is that it would get us the long-wanted support fairly
easily. A disadvantage, albeit a small one, is that the changes we need
to make to Nouveau will become obsolete.

Furthermore I think most of the work I did on PRIME support becomes
unnecessary with the above workaround. Given that Mesa will only ever
see the Nouveau pipe_screen, at least Weston should work properly out of
the box. DRI3 might still be problematic according to Alex's earlier
tests of the Tegra renderonly port. I have a couple more ideas that I'd
like to try out to see if they can solve this issue.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] loader: Automatic PRIME detection

[Thierry Reding]

On Tue, Dec 27, 2016 at 01:57:21PM +0100, Axel Davy wrote:
> Hi Thierry,
> 
> Could you explain why in this situation default_fd would be a non-renderable
> device node ?

This is preparatory work to allow drivers for split display/render
setups to be tied together within Mesa. If you want accelerated
rendering on those setups, you currently need to patch applications so
that they can deal with two separate devices (patches exist to allow
this for Weston and kmscube, and possibly others).

In order to avoid having to patch applications, the renderonly (the name
is slightly confusing) drivers (Christian Gmeiner sent out patches a few
weeks ago) open two devices internally and contain some magic to share
buffers between the two devices.

So the typical use-case would be that you have two separate DRM devices,
one representing the scanout device and another representing the GPU. In
most cases the scanout device will be display-only, so it will have a
/dev/dri/cardX node, but no corresponding /dev/dri/renderDY node. On the
other hand the GPU will have a "dummy" /dev/dri/cardX node that doesn't
expose any outputs and a corresponding /dev/dri/renderDY node that is
used for rendering.

A bare-metal application (kmscube, Weston, ...) will have to find a node
to perform a modeset with, so it will have to find a /dev/dri/cardX node
which exposes one or more outputs. That will be the scanout device node.
But given that there's no render node there's no way to accelerate using
that device.

Composite drivers will bind to the scanout device node and find a render
node for the GPU (these are usually ARM SoCs, so it's fairly easy to
find the correct render node) and bind the GPU driver to that node. Then
the GPU driver will export buffers used for scanout and have the scanout
driver import them. That way the application can transparently use those
buffers for DRM/KMS.

> In my understanding, for X11 DRI3 the Xserver is supposed to give you a
> renderable device node,
> and for Wayland, the device path advertised is the one used by the server
> for compositing.

Both X11 and Wayland will try to use the device used by the server for
compositing. In both cases they will receive the /dev/dri/cardX device
node for the scanout device.

Effectively X11 and Wayland will call back into the scanout driver for
acceleration. However with a minimal renderonly driver that's not going
to work. I had posted a complete wrapper driver a long time ago which I
think could be improved to allow even this use-case to work, but I got
significant pushback.

Anyway, both X11 and Wayland use the loader_get_user_preferred_fd()
function that this patch modifies to allow overriding the final file
descriptor to use. Currently the only way to override is by providing
the DRI_PRIME environment variable or by setting up a dri.conf
configuration file.

loader_get_user_preferred_fd() returns a file descriptor (same as the
default_fd by default, or the one referring to the DRI_PRIME node) and a
flag that specifies whether or not the devices are the same. This is
used in order to determine if DMA-BUF or FLINK should be used to share
buffers.

X11 has special code paths to deal with the PRIME use-case involving an
extra blit, which is somewhat unfortunate because on many devices that's
not going to be necessary.

For Wayland the EGL platform code checks for availability of a render
node to determine whether or not DMA-BUF should be used. That breaks for
this particular case as well because we do have a cardX node without a
corresponding renderDY node.

I suspect that with a full wrapper driver this could be solved more
nicely, including avoiding the extra blit in X11 DRI3. However it's a
lot more code to maintain than piggy-backing on top of PRIME support,
and a lot more complicated to get right (and more potential for breaking
existing use-cases).

Thierry

> On 23/12/2016 21:36, Thierry Reding wrote:
> > From: Thierry Reding <tred...@nvidia.com>
> > 
> > If a device doesn't support rendering and support for PRIME isn't
> > enabled via the DRI_PRIME environment variable or dri.conf, attempt to
> > find a render node which can be used to offload rendering.
> > 
> > Signed-off-by: Thierry Reding <tred...@nvidia.com>
> > ---
> > Along with platform and host1x bus support in the loader, this is the
> > final piece of the puzzle to automatically allow split scanout/render
> > devices to work with Wayland compositors and the X.Org server.
> > 
> > Note that this requires that the Wayland compositor and X.Org server
> > are accelerated with a DRI driver to make sure that the default file
> > descriptor is properly set up.
> > 
> >   src/loader/loader.c | 71 
> > ++---
> >   1 file changed, 67 insertions(+), 4 deletions(-)
> > 
> > diff 

[Mesa-dev] [RFC] loader: Automatic PRIME detection

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

If a device doesn't support rendering and support for PRIME isn't
enabled via the DRI_PRIME environment variable or dri.conf, attempt to
find a render node which can be used to offload rendering.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
Along with platform and host1x bus support in the loader, this is the
final piece of the puzzle to automatically allow split scanout/render
devices to work with Wayland compositors and the X.Org server.

Note that this requires that the Wayland compositor and X.Org server
are accelerated with a DRI driver to make sure that the default file
descriptor is properly set up.

 src/loader/loader.c | 71 ++---
 1 file changed, 67 insertions(+), 4 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 505c33133be6..6384432970f2 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -108,6 +108,71 @@ static char *loader_get_dri_config_device_id(void)
 }
 #endif
 
+/*
+ * For all devices that do not support rendering, try to find a different
+ * device that will.
+ *
+ * Note that the absence of a render node doesn't technically imply that
+ * the device can't render, but in practice this should work out fine.
+ */
+static int drm_detect_prime_fd(int default_fd, int *different_device)
+{
+   int err, fd = -ENODEV;
+   drmDevicePtr device;
+
+   err = drmGetDevice(default_fd, );
+   if (err < 0)
+  goto err;
+
+   if ((device->available_nodes & (1 << DRM_NODE_RENDER)) == 0) {
+  unsigned int num_devices, i;
+  drmDevicePtr *devices;
+
+  err = drmGetDevices(NULL, 0);
+  if (err < 0)
+ goto err;
+
+  num_devices = err;
+
+  devices = calloc(num_devices, sizeof(drmDevicePtr));
+  if (!devices)
+ goto err;
+
+  err = drmGetDevices(devices, num_devices);
+  if (err < 0) {
+ free(devices);
+ goto err;
+  }
+
+  num_devices = err;
+
+  for (i = 0; i < num_devices; i++) {
+ if (devices[i]->available_nodes & (1 << DRM_NODE_RENDER)) {
+fd = loader_open_device(devices[i]->nodes[DRM_NODE_RENDER]);
+if (fd < 0) {
+   fd = -errno;
+   continue;
+}
+
+close(default_fd);
+break;
+ }
+  }
+
+  drmFreeDevices(devices, num_devices);
+  free(devices);
+   }
+
+err:
+   if (fd < 0) {
+  *different_device = 0;
+  return default_fd;
+   }
+
+   *different_device = 1;
+   return fd;
+}
+
 static char *drm_construct_id_path_tag(drmDevicePtr device)
 {
 /* Length of "pci-_xx_xx_x\0" */
@@ -213,10 +278,8 @@ int loader_get_user_preferred_fd(int default_fd, int 
*different_device)
   prime = loader_get_dri_config_device_id();
 #endif
 
-   if (prime == NULL) {
-  *different_device = 0;
-  return default_fd;
-   }
+   if (prime == NULL || *prime == '\0')
+  return drm_detect_prime_fd(default_fd, different_device);
 
default_tag = drm_get_id_path_tag_for_fd(default_fd);
if (default_tag == NULL)
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] loader: Add support for USB devices

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Allow USB devices to be used as output slaves for PRIME. Note that this
currently doesn't work on the X.Org server's built-in modesetting driver
because it requires glamor in order to expose the necessary capabilities
through RandR.

It should be possible to use this in order to accelerate Wayland clients
on the GPU, though it's questionable how useful that is without having a
compositor that gets accelerated.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/loader/loader.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 449ff54d1377..d2f7165c1011 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -112,6 +112,8 @@ static char *drm_construct_id_path_tag(drmDevicePtr device)
 {
 /* Length of "pci-_xx_xx_x\0" */
 #define PCI_ID_PATH_TAG_LENGTH 17
+/* Length of "usb-xxx_xxx\0" */
+#define USB_ID_PATH_TAG_LENGTH 12
char *tag = NULL;
 
if (device->bustype == DRM_BUS_PCI) {
@@ -122,6 +124,13 @@ static char *drm_construct_id_path_tag(drmDevicePtr device)
 snprintf(tag, PCI_ID_PATH_TAG_LENGTH, "pci-%04x_%02x_%02x_%1u",
  device->businfo.pci->domain, device->businfo.pci->bus,
  device->businfo.pci->dev, device->businfo.pci->func);
+   } else if (device->bustype == DRM_BUS_USB) {
+  tag = calloc(USB_ID_PATH_TAG_LENGTH, sizeof(char));
+  if (!tag)
+ return NULL;
+
+  snprintf(tag, USB_ID_PATH_TAG_LENGTH, "usb-%03u_%03u",
+   device->businfo.usb->bus, device->businfo.pci->dev);
}
return tag;
 }
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] loader: Add support for platform and host1x busses

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
support for this bus in order to allow use of the DRI_PRIME environment
variable with those devices.

While at it, also support the host1x bus, which is effectively the same
but uses an additional layer in the bus hierarchy.

Note that it isn't enough to support the bus that has the rendering GPU
because the loader code will also try to construct an ID path tag for a
scanout-only device if it is the default that is being opened.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/loader/loader.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index d2f7165c1011..514fe5991613 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -131,6 +131,40 @@ static char *drm_construct_id_path_tag(drmDevicePtr device)
 
   snprintf(tag, USB_ID_PATH_TAG_LENGTH, "usb-%03u_%03u",
device->businfo.usb->bus, device->businfo.pci->dev);
+   } else if (device->bustype == DRM_BUS_PLATFORM) {
+  size_t length = 10; /* platform- + \0 */
+  char *name;
+
+  name = strrchr(device->businfo.platform->fullname, '/');
+  if (!name)
+ name = device->businfo.platform->fullname;
+  else
+ name++;
+
+  length += strlen(name);
+
+  tag = calloc(length, sizeof(char));
+  if (!tag)
+ return NULL;
+
+  snprintf(tag, length, "platform-%s", name);
+   } else if (device->bustype == DRM_BUS_HOST1X) {
+  size_t length = 8; /* host1x- + \0 */
+  char *name;
+
+  name = strrchr(device->businfo.host1x->fullname, '/');
+  if (!name)
+ name = device->businfo.host1x->fullname;
+  else
+ name++;
+
+  length += strlen(name);
+
+  tag = calloc(length, sizeof(char));
+  if (!tag)
+ return NULL;
+
+  snprintf(tag, length, "host1x-%s", name);
}
return tag;
 }
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader: Add vim modeline

[Thierry Reding]

On Wed, Dec 21, 2016 at 08:49:18AM -0500, Ilia Mirkin wrote:
> So you want every file to have a modeline for every editor? Is there no way
> to do this at the directory level, like you can with emacs? I thought there
> was some editorconfig thing...

I'm sure there are ways to do that, I was merely following what was
already being done in other files.

And yes, this isn't optimal, but neither is having each author add their
own indentation style to the files.

Solutions that I've found that do this per directory aren't very optimal
either because you'd still need one file per editor and per directory,
and they all require manual intervention to activate. Most are insecure
to the point where I wouldn't want to enable them.

Thierry

> On Dec 21, 2016 8:44 AM, "Thierry Reding" <thierry.red...@gmail.com> wrote:
> 
> From: Thierry Reding <tred...@nvidia.com>
> 
> Add a vim modeline that defines the identation style used in this file.
> This is useful to avoid vim's defaults (8-column tabs) from getting in
> the way.
> 
> While at it, fix up a few cases where inconsistent indentation is used.
> 
> Signed-off-by: Thierry Reding <tred...@nvidia.com>
> ---
>  src/loader/loader.c | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 449ff54d1377..eb536ac970f9 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -86,9 +86,9 @@ loader_open_device(const char *device_name)
>  #ifdef USE_DRICONF
>  static const char __driConfigOptionsLoader[] =
>  DRI_CONF_BEGIN
> -DRI_CONF_SECTION_INITIALIZATION
> -DRI_CONF_DEVICE_ID_PATH_TAG()
> -DRI_CONF_SECTION_END
> +   DRI_CONF_SECTION_INITIALIZATION
> +  DRI_CONF_DEVICE_ID_PATH_TAG()
> +   DRI_CONF_SECTION_END
>  DRI_CONF_END;
> 
>  static char *loader_get_dri_config_device_id(void)
> @@ -115,13 +115,13 @@ static char *drm_construct_id_path_tag(drmDevicePtr
> device)
> char *tag = NULL;
> 
> if (device->bustype == DRM_BUS_PCI) {
> -tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
> -if (tag == NULL)
> -return NULL;
> +  tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
> +  if (tag == NULL)
> + return NULL;
> 
> -snprintf(tag, PCI_ID_PATH_TAG_LENGTH, "pci-%04x_%02x_%02x_%1u",
> - device->businfo.pci->domain, device->businfo.pci->bus,
> - device->businfo.pci->dev, device->businfo.pci->func);
> +  snprintf(tag, PCI_ID_PATH_TAG_LENGTH, "pci-%04x_%02x_%02x_%1u",
> +   device->businfo.pci->domain, device->businfo.pci->bus,
> +   device->businfo.pci->dev, device->businfo.pci->func);
> }
> return tag;
>  }
> @@ -386,8 +386,8 @@ loader_get_driver_for_fd(int fd)
> 
>  out:
> log_(driver ? _LOADER_DEBUG : _LOADER_WARNING,
> - "pci id for fd %d: %04x:%04x, driver %s\n",
> - fd, vendor_id, chip_id, driver);
> +"pci id for fd %d: %04x:%04x, driver %s\n",
> +fd, vendor_id, chip_id, driver);
> return driver;
>  }
> 
> @@ -415,9 +415,11 @@ loader_get_extensions_name(const char *driver_name)
> 
> const size_t len = strlen(name);
> for (size_t i = 0; i < len; i++) {
> -  if (name[i] == '-')
> -  name[i] = '_';
> +  if (name[i] == '-')
> + name[i] = '_';
> }
> 
> return name;
>  }
> +
> +/* vim: set et sts=3 sw=3 ts=3: */
> --
> 2.11.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] loader: Add vim modeline

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Add a vim modeline that defines the identation style used in this file.
This is useful to avoid vim's defaults (8-column tabs) from getting in
the way.

While at it, fix up a few cases where inconsistent indentation is used.

Signed-off-by: Thierry Reding <tred...@nvidia.com>
---
 src/loader/loader.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 449ff54d1377..eb536ac970f9 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -86,9 +86,9 @@ loader_open_device(const char *device_name)
 #ifdef USE_DRICONF
 static const char __driConfigOptionsLoader[] =
 DRI_CONF_BEGIN
-DRI_CONF_SECTION_INITIALIZATION
-DRI_CONF_DEVICE_ID_PATH_TAG()
-DRI_CONF_SECTION_END
+   DRI_CONF_SECTION_INITIALIZATION
+  DRI_CONF_DEVICE_ID_PATH_TAG()
+   DRI_CONF_SECTION_END
 DRI_CONF_END;
 
 static char *loader_get_dri_config_device_id(void)
@@ -115,13 +115,13 @@ static char *drm_construct_id_path_tag(drmDevicePtr 
device)
char *tag = NULL;
 
if (device->bustype == DRM_BUS_PCI) {
-tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
-if (tag == NULL)
-return NULL;
+  tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
+  if (tag == NULL)
+ return NULL;
 
-snprintf(tag, PCI_ID_PATH_TAG_LENGTH, "pci-%04x_%02x_%02x_%1u",
- device->businfo.pci->domain, device->businfo.pci->bus,
- device->businfo.pci->dev, device->businfo.pci->func);
+  snprintf(tag, PCI_ID_PATH_TAG_LENGTH, "pci-%04x_%02x_%02x_%1u",
+   device->businfo.pci->domain, device->businfo.pci->bus,
+   device->businfo.pci->dev, device->businfo.pci->func);
}
return tag;
 }
@@ -386,8 +386,8 @@ loader_get_driver_for_fd(int fd)
 
 out:
log_(driver ? _LOADER_DEBUG : _LOADER_WARNING,
- "pci id for fd %d: %04x:%04x, driver %s\n",
- fd, vendor_id, chip_id, driver);
+"pci id for fd %d: %04x:%04x, driver %s\n",
+fd, vendor_id, chip_id, driver);
return driver;
 }
 
@@ -415,9 +415,11 @@ loader_get_extensions_name(const char *driver_name)
 
const size_t len = strlen(name);
for (size_t i = 0; i < len; i++) {
-  if (name[i] == '-')
-  name[i] = '_';
+  if (name[i] == '-')
+ name[i] = '_';
}
 
return name;
 }
+
+/* vim: set et sts=3 sw=3 ts=3: */
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] gallium: add renderonly library

[Thierry Reding]

On Mon, Dec 19, 2016 at 08:54:04PM +0100, Christian Gmeiner wrote:
> 2016-12-19 14:08 GMT+01:00 Thierry Reding <thierry.red...@gmail.com>:
> > On Wed, Nov 30, 2016 at 02:44:34PM +0100, Christian Gmeiner wrote:
[...]
> >>  GALLIUM_WINSYS_CFLAGS = \
> >>   -I$(top_srcdir)/src \
> >>   -I$(top_srcdir)/include \
> >> diff --git a/src/gallium/auxiliary/Makefile.am 
> >> b/src/gallium/auxiliary/Makefile.am
> >> index 4a4a4fb..6b63cf1 100644
> >> --- a/src/gallium/auxiliary/Makefile.am
> >> +++ b/src/gallium/auxiliary/Makefile.am
> >> @@ -20,6 +20,16 @@ libgallium_la_SOURCES = \
> >>   $(NIR_SOURCES) \
> >>   $(GENERATED_SOURCES)
> >>
> >> +if HAVE_LIBDRM
> >> +
> >> +AM_CFLAGS += \
> >> + $(LIBDRM_CFLAGS)
> >
> > Same here.
> 
> I just redone what other have done in that file. There are some if's
> in that file and I am unsure
> what to do here.

Maybe Emil has a strong opinion here, I was really just nit-picking, so
feel free to leave this.

> >> diff --git a/src/gallium/auxiliary/Makefile.sources 
> >> b/src/gallium/auxiliary/Makefile.sources
> >> index 5d4fe30..8d3e4a9 100644
> >> --- a/src/gallium/auxiliary/Makefile.sources
> >> +++ b/src/gallium/auxiliary/Makefile.sources
> >> @@ -435,3 +435,7 @@ GALLIVM_SOURCES := \
> >>   draw/draw_llvm_sample.c \
> >>   draw/draw_pt_fetch_shade_pipeline_llvm.c \
> >>   draw/draw_vs_llvm.c
> >> +
> >> +RENDERONLY_SOURCES := \
> >> + renderonly/renderonly.c \
> >> + renderonly/renderonly.h
> >> diff --git a/src/gallium/auxiliary/renderonly/renderonly.c 
> >> b/src/gallium/auxiliary/renderonly/renderonly.c
> >> new file mode 100644
> >> index 000..c4ea784
> >> --- /dev/null
> >> +++ b/src/gallium/auxiliary/renderonly/renderonly.c
> >> @@ -0,0 +1,199 @@
> >> +/*
> >> + * Copyright (C) 2016 Christian Gmeiner <christian.gmei...@gmail.com>
> >> + *
> >> + * Permission is hereby granted, free of charge, to any person obtaining a
> >> + * copy of this software and associated documentation files (the 
> >> "Software"),
> >> + * to deal in the Software without restriction, including without 
> >> limitation
> >> + * the rights to use, copy, modify, merge, publish, distribute, 
> >> sublicense,
> >> + * and/or sell copies of the Software, and to permit persons to whom the
> >> + * Software is furnished to do so, subject to the following conditions:
> >> + *
> >> + * The above copyright notice and this permission notice (including the 
> >> next
> >> + * paragraph) shall be included in all copies or substantial portions of 
> >> the
> >> + * Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> >> EXPRESS OR
> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> >> MERCHANTABILITY,
> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> >> SHALL
> >> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> >> OTHER
> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> >> ARISING FROM,
> >> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
> >> IN THE
> >> + * SOFTWARE.
> >> + *
> >> + * Authors:
> >> + *Christian Gmeiner <christian.gmei...@gmail.com>
> >> + */
> >> +
> >> +#include "renderonly/renderonly.h"
> >
> > This include is oddly placed. Should it not go below all other includes?
> >
> 
> I think thats a matter of style but I can puit it above #include
> "state_tracker/drm_driver.h"

I prefer having these in hierarchical order. That is, anything from the
C runtime goes first, then other system includes, followed by project
core includes and finally driver-local includes. By that ordering
renderonly.h would be very last in line. Not sure if anyone in Mesa is
pedantic enough to insist on a common style, so feel free to leave this
as-is if you prefer.

> >> +struct pipe_screen *
> >> +renderonly_screen_create(int fd, const struct renderonly_ops *ops, void 
> >> *priv)
> >
> > This is slightly nit-picky, but I found it confusing when first reading
> > through the patches: I know this started out as an effort to support the
> > various render-only devices out there, but wha

Re: [Mesa-dev] [PATCH 3/3] imx: gallium driver for imx-drm scanout driver

[Thierry Reding]

On Mon, Dec 19, 2016 at 04:04:34PM +, Emil Velikov wrote:
> On Monday, 19 December 2016, Thierry Reding <thierry.red...@gmail.com>
> wrote:
> 
> > On Wed, Nov 30, 2016 at 02:44:36PM +0100, Christian Gmeiner wrote:
> > [...]
> > > +static struct pipe_screen *imx_open_render_node(struct renderonly *ro)
> > > +{
> > > +   return etna_drm_screen_create_rendernode(ro);
> > > +}
> >
> > Patch 2/3 never made it into my inbox for some reason, and had to find
> > it in some archives. I'll have to resort to commenting on the code here.
> > From what I saw, etna_drm_screen_create_rendernode() hard-codes the GPU
> > render node (to /dev/dri/renderD128, I think). It's a little brittle for
> > obvious reasons, but I think you might be able to get away with it,
> > depending on the SoC.
> >
> > On Tegra we have a bunch of people that stick discrete GPUs into the
> > PCIe slot and run a second instance of Nouveau on that. It's an
> > interesting use-case, but it also has the drawback of creating a second
> > renderD device. What's more, it uses the same kernel driver, so hard-
> > coding the device node is going to give us a 50-50 chance on average
> > that we get the right one. Back when I had written the original proposal
> > I had also coded a heuristic that would walk sysfs and select the render
> > node that was on the same bus as the card node. This was before Emil had
> > removed the dependency on udev, but I've rewritten that code to work
> > with Emil's drmDevice*() API, which needs some fleshing out[0].
> >
> > Out of curiosity, is this something that could happen on i.MX devices as
> > well? Or even if not i.MX, I'm fairly sure that there are other SoCs
> > that have a Vivante GPU and a PCI slot that people could use to stick
> > big GPUs into, so you may run into the same issue eventually.
> 
> Thanks Thierry for the nice write-up. Must admit that I was feeling a bit
> lazy.
> 
> Considering the ~ok odds and the fact that we don't have platform support
> for the drm*Device helpers I'm inclined to have this fixed after the merge.
> 
> Let's have etna and(?) tegra and sort bugs during the RCs ;-)

I'm fine if you want etnaviv as-is. I personally would want to hold off
on Tegra for a wee bit longer. Let's see if Alex has a strong opinion.

What are your requirements for release? Will you be freezing the libdrm
dependency during RCs? I've got most of the patches ready to make this
work reliably on Tegra, though I'd still have to port my patches to
Christian's renderonly library.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] imx: gallium driver for imx-drm scanout driver

[Thierry Reding]

On Wed, Nov 30, 2016 at 02:44:36PM +0100, Christian Gmeiner wrote:
[...]
> +static struct pipe_screen *imx_open_render_node(struct renderonly *ro)
> +{
> +   return etna_drm_screen_create_rendernode(ro);
> +}

Patch 2/3 never made it into my inbox for some reason, and had to find
it in some archives. I'll have to resort to commenting on the code here.
From what I saw, etna_drm_screen_create_rendernode() hard-codes the GPU
render node (to /dev/dri/renderD128, I think). It's a little brittle for
obvious reasons, but I think you might be able to get away with it,
depending on the SoC.

On Tegra we have a bunch of people that stick discrete GPUs into the
PCIe slot and run a second instance of Nouveau on that. It's an
interesting use-case, but it also has the drawback of creating a second
renderD device. What's more, it uses the same kernel driver, so hard-
coding the device node is going to give us a 50-50 chance on average
that we get the right one. Back when I had written the original proposal
I had also coded a heuristic that would walk sysfs and select the render
node that was on the same bus as the card node. This was before Emil had
removed the dependency on udev, but I've rewritten that code to work
with Emil's drmDevice*() API, which needs some fleshing out[0].

Out of curiosity, is this something that could happen on i.MX devices as
well? Or even if not i.MX, I'm fairly sure that there are other SoCs
that have a Vivante GPU and a PCI slot that people could use to stick
big GPUs into, so you may run into the same issue eventually.

Thierry

[0]: Interestingly, things would probably work for Tegra regardless of
whether the GPU is the Tegra one or a discrete one, as long as the
discrete is driven by Nouveau. So perhaps an even more interesting
heuristic would be to look for a render node that's driven by the
Nouveau driver...


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] gallium: add renderonly library

[Thierry Reding]

On Wed, Nov 30, 2016 at 02:44:34PM +0100, Christian Gmeiner wrote:
> This a very lightweight library to add basic support for
> renderonly GPUs. It does all the magic regarding in/exporting
> buffers etc. This library will likely break android support and
> hopefully will get replaced with a better solution based on gbm2.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  src/gallium/Automake.inc  |   5 +
>  src/gallium/auxiliary/Makefile.am |  10 ++
>  src/gallium/auxiliary/Makefile.sources|   4 +
>  src/gallium/auxiliary/renderonly/renderonly.c | 199 
> ++
>  src/gallium/auxiliary/renderonly/renderonly.h |  81 +++
>  5 files changed, 299 insertions(+)
>  create mode 100644 src/gallium/auxiliary/renderonly/renderonly.c
>  create mode 100644 src/gallium/auxiliary/renderonly/renderonly.h

Hi Christian,

sorry for being late to the party. I only ran across this by accident.
Would you mind keeping me in Cc for subsequent versions of this? It's
been more than two years since I wrote the original proposal for this,
but I'm still interested in seeing a solution emerge.

Anyway, thanks for picking this up.

From a diff point of view this is certainly much more terse than the
original proposal. I find it slightly unfortunate that the drivers for
the render GPU have to be changed. But it's hard to argue with the
reduction in size.

I still think that Tegra will eventually require more than the stub that
you have in this series because the same device that exposes the scanout
engine also contains units that can do video compositing, decoding and
encoding. There's in fact recently been discussions on how best to
provide that functionality and Mesa looks like the best long-term target
currently. Anyway, that's a bridge I think we can cross when we get
there, this concept looks fine to get started.

> diff --git a/src/gallium/Automake.inc b/src/gallium/Automake.inc
> index 6fe2e22..6aadcb9 100644
> --- a/src/gallium/Automake.inc
> +++ b/src/gallium/Automake.inc
> @@ -50,6 +50,11 @@ GALLIUM_COMMON_LIB_DEPS = \
>   $(PTHREAD_LIBS) \
>   $(DLOPEN_LIBS)
>  
> +if HAVE_LIBDRM
> +GALLIUM_COMMON_LIB_DEPS += \
> + $(LIBDRM_LIBS)
> +endif

Nit: Is the conditional necessary here? LIBDRM_LIBS would be empty if
libdrm wasn't found, right? So no harm in just appending it to the
GALLIUM_COMMON_LIB_DEPS variable unconditonally?

>  GALLIUM_WINSYS_CFLAGS = \
>   -I$(top_srcdir)/src \
>   -I$(top_srcdir)/include \
> diff --git a/src/gallium/auxiliary/Makefile.am 
> b/src/gallium/auxiliary/Makefile.am
> index 4a4a4fb..6b63cf1 100644
> --- a/src/gallium/auxiliary/Makefile.am
> +++ b/src/gallium/auxiliary/Makefile.am
> @@ -20,6 +20,16 @@ libgallium_la_SOURCES = \
>   $(NIR_SOURCES) \
>   $(GENERATED_SOURCES)
>  
> +if HAVE_LIBDRM
> +
> +AM_CFLAGS += \
> + $(LIBDRM_CFLAGS)

Same here.

> diff --git a/src/gallium/auxiliary/Makefile.sources 
> b/src/gallium/auxiliary/Makefile.sources
> index 5d4fe30..8d3e4a9 100644
> --- a/src/gallium/auxiliary/Makefile.sources
> +++ b/src/gallium/auxiliary/Makefile.sources
> @@ -435,3 +435,7 @@ GALLIVM_SOURCES := \
>   draw/draw_llvm_sample.c \
>   draw/draw_pt_fetch_shade_pipeline_llvm.c \
>   draw/draw_vs_llvm.c
> +
> +RENDERONLY_SOURCES := \
> + renderonly/renderonly.c \
> + renderonly/renderonly.h
> diff --git a/src/gallium/auxiliary/renderonly/renderonly.c 
> b/src/gallium/auxiliary/renderonly/renderonly.c
> new file mode 100644
> index 000..c4ea784
> --- /dev/null
> +++ b/src/gallium/auxiliary/renderonly/renderonly.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 Christian Gmeiner 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
> THE
> + * SOFTWARE.
> + *
> + * Authors:
> + *Christian Gmeiner 
> + */
> 

Re: [Mesa-dev] [PATCH 3/3] imx: gallium driver for imx-drm scanout driver

[Thierry Reding]

On Thu, Dec 01, 2016 at 03:00:20PM +, Emil Velikov wrote:
> On 30 November 2016 at 13:44, Christian Gmeiner
>  wrote:
> > The imx (stub) driver is needed to get hardware acceleration from
> > etnaviv on a platform using imx-drm kms driver. This adds support
> > for wayland and native kms egl apps.
> >
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  configure.ac   | 12 +++
> >  src/gallium/Makefile.am|  4 +++
> >  .../auxiliary/pipe-loader/pipe_loader_drm.c|  5 +++
> >  src/gallium/auxiliary/target-helpers/drm_helper.h  | 23 
> >  .../auxiliary/target-helpers/drm_helper_public.h   |  3 ++
> >  src/gallium/drivers/imx/Automake.inc   |  9 +
> >  src/gallium/drivers/imx/Makefile.am|  9 +
> >  src/gallium/winsys/imx/drm/Makefile.am | 33 +
> >  src/gallium/winsys/imx/drm/Makefile.sources|  3 ++
> >  src/gallium/winsys/imx/drm/imx_drm_public.h| 31 
> >  src/gallium/winsys/imx/drm/imx_drm_winsys.c| 41 
> > ++
> >  11 files changed, 173 insertions(+)
> I think you want to add the following to src/gallium/targets/dri/Makefile.am
> 
> include $(top_srcdir)/src/gallium/drivers/imx/Automake.inc
> 
> Otherwise there will be no imx_dri.so module which you can use.
> ^^ is a must have afaics, everything else (mentioned below) can be
> tackled at a later stage.
> 
> A set of targets/pipe-loader/* changes would be nice... unless I beat
> you to it and fold the final round of duplication that we have in the
> pipe-loader/targets topic ;-)
> 
> 
> > +include Makefile.sources
> > +include $(top_srcdir)/src/gallium/Automake.inc
> > +
> > +AM_CFLAGS = \
> > +   -I$(top_srcdir)/src/gallium/drivers \
> Add the following and then ...
>-I$(top_srcdir)/src/gallium/winsys \
> 
> > +   $(GALLIUM_WINSYS_CFLAGS) \
> > +   $(IMX_CFLAGS)
> > +
> > +noinst_LTLIBRARIES = libimxdrm.la
> > +
> > +libimxdrm_la_SOURCES = $(C_SOURCES)
> > \ No newline at end of file
> Please add the missing newlines throughout.
> 
> 
> > diff --git a/src/gallium/winsys/imx/drm/imx_drm_public.h 
> > b/src/gallium/winsys/imx/drm/imx_drm_public.h
> > new file mode 100644
> > index 000..2d93da2
> > --- /dev/null
> > +++ b/src/gallium/winsys/imx/drm/imx_drm_public.h
> > @@ -0,0 +1,31 @@
> > +/*
> > + * Copyright © 2014 NVIDIA Corporation
> > + *
> Disclaimer: IANAL
> 
> Here and other copyright notices could be updated to reflect you.
> Things have changed noticeably that any recemblense with the original
> is conicidential.

Agreed, there's nothing in this file that I'd consider copyright of
NVIDIA. If there's anything copyrightable in this series at all I'd
think it'd be the create/export/import/tiling dance that the render-
only library does.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH RFC 0/2] GBM API extension to support fusing KMS and render devices

[Thierry Reding]

On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
> Am Freitag, den 04.03.2016, 18:34 + schrieb Emil Velikov:
> > On 4 March 2016 at 17:38, Lucas Stach  wrote:
> > > Am Freitag, den 04.03.2016, 17:20 + schrieb Daniel Stone:
> > >> Hi,
> > >>
> > >> On 4 March 2016 at 16:08, Lucas Stach  wrote:
> > >> > Am Freitag, den 04.03.2016, 15:09 + schrieb Daniel Stone:
> > >> >> Thanks for taking this on, it looks really good! I just have the one
> > >> >> question though - did you look at the EGLDevice extension? Using that
> > >> >> to enumerate the GPUs, we could create the gbm_device using the KMS
> > >> >> device and pass that in to the EGLDisplay, with an additional attrib
> > >> >> to pass in an EGLDevice handle to eglGetPlatformDisplay. This could
> > >> >> possibly be better since it is more independent of DRM as the API, and
> > >> >> also allows people to share device enumeration/selection code with
> > >> >> other platforms (e.g. choosing between multiple GPUs when using a
> > >> >> winsys like Wayland or X11).
> > >> >>
> > >> > I have not looked at this in detail yet, but I think it's just an
> > >> > extension to the interface outlined by this series.
> > >> >
> > >> > If we require the KMS device to have a DRI2/Gallium driver it should be
> > >> > easy to hook up the EGLDevice discovery for them.
> > >> > Passing in a second device handle for the KMS device is then just the
> > >> > EGL implementation calling gbm_device_set_kms_provider() on the render
> > >> > GBM device, instead of the application doing it manually.
> > >>
> > >> It turns the API backwards a bit though ...
> > >>
> > >> Right now, what we require is that the GBM device passed in is the KMS
> > >> device, not the GPU device; what you're suggesting is that we discover
> > >> the GPU device and then add the KMS device.
> > >>
> > >> So, with your proposal:
> > >> gbm_gpu = gbm_device_create("/dev/dri/renderD128");
> > >> egl_dpy = eglGetDisplay(gbm_gpu);
> > >> gbm_kms = gbm_device_create("/dev/dri/card0");
> > >> gbm_device_set_kms_provider(gbm_gpu, gbm_kms);
> > >>
> > >> i.e. the device the user creates first is the GPU device.
> > >>
> > >> With EGLDevice, we would have:
> > >> gbm_kms = gbm_device_create("/dev/dri/card0");
> > >> egl_gpus = eglGetDevicesEXT();
> > >> egl_dpy = eglGetPlatformDisplay(gbm_kms, { EGL_TARGET_DEVICE, 
> > >> egl_gpus[0] });
> > >>
> > >> So, the first/main device the user deals with is the KMS device - same
> > >> as today. This makes sense, since GBM is the allocation API for KMS,
> > >> and EGL should be the one dealing with the GPU ...
> > >>
> > > Right, my API design was from my view of GBM being the API to bootstrap
> > > EGL rendering, but defining it as the KMS allocation API makes a lot
> > > more sense, when you think about it.
> > >
> > >> Maybe it would make sense to reverse the API, so rather than creating
> > >> a GBM device for the GPU and then linking that to the KMS device -
> > >> requiring users to make different calls, e.g. gbm_bo_get_kms_bo(),
> > >> which makes it harder to use and means we need to port current users -
> > >> we create a GBM device for KMS and then link that to a GPU device.
> > >> This would then mean that eglGetPlatformDisplay could do the linkage
> > >> internally, and then existing users using gbm_bo_get_handle() etc
> > >> would still work without needing any different codepaths.
> > >
> > > Yes, this will make the implementation inside GBM a bit more involved,
> > > but it seems more natural this way around when thinking about hooking it
> > > up to EGLDevice. I'll try it out and send an updated RFC after the
> > > weekend.
> > >
> > While I'm more inclined to Daniel's suggestion, I wonder why people
> > moved away from Thierry's approach - creating a composite/wrapped dri
> > module ? Is there anything wrong with it - be that from technical or
> > conceptual POV ?
> > 
> The wrapped driver takes away the ability of the application to decide
> which GPUs to bind together - at least if you want to keep things
> tightly coupled at that level.

That was actually the prime objective of the patches I posted back at
the time. =)

> The point of the explicit application control is that we not only solve
> the "SoCs have split render/scanout devices" issue, but gain an API for
> compositors to work properly on PRIME laptop configurations with
> render/render/scanout. We don't want any autodetection to happen there,
> a compositor may well decide to use the Intel GPU as scanout only and do
> all composition on the discreet GPU. Having a tightly coupled wrapped
> driver for every device combination is not really where we want to go,
> right?

To be honest, I don't think we have much of a choice. Most bare-metal
applications don't make a distinction between render and scanout. They
will simply assume that you can do both on the same device, because
that's what their development machine happens to 

Re: [Mesa-dev] [RFC 1/2] gallium: add renderonly driver

[Thierry Reding]

On Fri, Oct 16, 2015 at 12:09:52AM +0100, Emil Velikov wrote:
> Hi Christian,
> 
> I'm glad to see Thierry's work revived. Hopefully this will soon be
> the basis of many more drivers.
> 
> On 11 October 2015 at 16:09, Christian Gmeiner
>  wrote:
> > This commit adds a generic renderonly driver library, which fullfille
> > the requirements for tegra and etnaviv. As a result it is possible to
> > run unmodified egl software directly (without any compositor) on
> > supported devices.
> >
> > In every use case we import a dumb buffer from scanout gpu into
> > the renderonly gpu.
> >
> > If the scanout hardware does support the used tiling format from the
> > renderonly gpu, a driver can define a function which is used to 'setup'
> > the needed tiling on that imported buffer. This functions gets called
> > during rendertarget resource creation.
> >
> > If the scanout hardware does not support the used tiling format we need
> > to create an extra rendertarget resource for the renderonly gpu.
> > During XXX we blit the renderonly rendertarget onto the imported dumb
> > buffer.
> >
> I'd assume you meant to add something over the XXX here :-P
> 
> But seriously some people might not be too happy with the blit onto
> dumb buffer. Personally I ok, esp. since we don't have anything better
> atm.
> 
> That aside, there are a few minor nitpicks below. With those sorted I
> believe the patch is good to land.

I'd prefer if at least the Tegra part wasn't merged just yet. We know
that it only works in a restricted set of use-cases. So until we figure
it out all the way I don't think it makes sense to have this code in
Mesa yet. I suppose the renderonly part could go in, though I do have
some reservations about the architecture. I'll try to comment on that
in a separate email because this subthread lacks some of the necessary
context.

Thierry


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 1/2] gallium: add renderonly driver

[Thierry Reding]

Hi Christian,

First off, thanks for reviving this effort. It's been one of the things
that I've had nagging at me for much too long and I think it needs to be
solved. So I'm hopeful that the more people we get looking at this the
more likely it will be to come up with a solution that works well for
everyone.

That said, I don't agree with the approach you've chosen here. I'll try
to clarify why below.

On Sun, Oct 11, 2015 at 05:09:21PM +0200, Christian Gmeiner wrote:
> This commit adds a generic renderonly driver library, which fullfille
> the requirements for tegra and etnaviv. As a result it is possible to
> run unmodified egl software directly (without any compositor) on
> supported devices.

Technically this isn't a library but rather a midlayer. There's a subtle
difference, but the implications are what concerns me.

Back when I wrote the original driver for Tegra/Nouveau I also looked
into possibilities to make this more generic. Since I know how bad mid-
layers can be (from kernel experience) I shied away from something like
this early on. What I tried to do next was abstract away enough to make
this usable by more than just a single driver. Unfortunately the end
result was that not much could be reused, so drivers ended up still
having to implement all of the pipe_* objects, only to call generic
functions. Most of the code needed in the various callbacks ended up not
being much more than just a single line, so the gains from a helper
library weren't very big.

Another reason why I think this level of abstraction doesn't gain us
much is that we already have a good level of abstraction, which is
Gallium. I realize that implementing only the skeleton for a full
Gallium driver is rather complicated, but that's due to the fact that
graphics drivers are complex beasts.

That said, I think for some areas it might be beneficial to have helpers
to reduce the amount of duplication. However I think at this point in
time we haven't had enough real-world exposure for this kind of driver
to know what the requirements are. For that reason I think it is
premature to use a generic midlayer such as this. Yes, I know that the
alternative is roughly 2000 lines of code per driver, but on one hand
that's nothing compared to the amount of code required by a proper GPU
driver and on the other hand this will (ideally) be temporary until we
get a better picture of where things need to go. At which point it may
become more obvious how we can solve the boilerplate problem while at
the same time avoiding the restrictions imposed by the midlayer.

> In every use case we import a dumb buffer from scanout gpu into
> the renderonly gpu.
> 
> If the scanout hardware does support the used tiling format from the
> renderonly gpu, a driver can define a function which is used to 'setup'
> the needed tiling on that imported buffer. This functions gets called
> during rendertarget resource creation.
> 
> If the scanout hardware does not support the used tiling format we need
> to create an extra rendertarget resource for the renderonly gpu.
> During XXX we blit the renderonly rendertarget onto the imported dumb
> buffer.
> 
> We assume that the renderonly driver provides a blit function that is
> capable of resolving the tilied into untiled one.

I understand that there's a want to eliminate the amount of boilerplate,
but I think this approach of using a midlayer has several flaws. One of
the typical pitfalls with a midlayer such as this is that it has the
potential to grow into an unmaintainable mess. Granted, this currently
doesn't look all that bad, but that's primarily because it supports only
two types of devices. I suspect that the more devices we add, the more
hooks and quirks we'll need. Every combination of GPU and display is
likely going to have their own specialties that need to be handled and
which are beyond simple things like the tiling format.

We also know that there are issues with the current approach (EGL
clients in Weston don't properly display). It's unknown what the reason
for this is and it may require largish changes to the architecture to
fix it.

For all of the above reasons I think it'd be better to live with a
little boilerplate for now and refactor things as they become obvious
candidates for refactoring.

[...]
> diff --git a/src/gallium/drivers/renderonly/renderonly_screen.c 
> b/src/gallium/drivers/renderonly/renderonly_screen.c
[...]
> +static const char *
> +renderonly_get_vendor(struct pipe_screen *pscreen)
> +{
> + return "renderonly";
> +}

I don't think this going to do us much good. Applications may want to
know more precisely what kind of device they're running on and change
behaviour accordingly.

> +static void renderonly_screen_destroy(struct pipe_screen *pscreen)
> +{
> + struct renderonly_screen *screen = to_renderonly_screen(pscreen);
> +
> + screen->gpu->destroy(screen->gpu);
> + free(pscreen);
> +}
> +
> +static int
> +renderonly_screen_get_param(struct pipe_screen 

Re: [Mesa-dev] Valve games for Mesa/DRI developers

[Thierry Reding]

Hi Daniel,

I'm not much of a gamer myself, but I imagine that these games would be
useful, real-life tests and/or entertaining benchmarks. Given that I
work mostly on ARM systems, do you know if there are any plans on making
these games available on ARM? I know some of Valve's games have been
ported to ARM for Android, but perhaps there isn't enough of an audience
to make it beneficial to get them to run on regular Linux on ARM?

Thierry

On Thu, Apr 09, 2015 at 06:10:42PM +0100, Daniel Stone wrote:
 Hi,
 At Collabora (my lovely dayjob), we've been working with Valve on
 SteamOS. Valve are keen to give back to the community, and we've been
 discussing ways they can help do that, including providing free access
 to Valve games on Steam to Debian developers last year.
 
 We're happy to say that this has been extended to Mesa developers as
 well, to say thanks for all the great work. If you have 25 commits or
 more (an arbitrary number) to Mesa[0] in the past five years, please
 drop me an email (with 'Steam' in the subject) with your freedesktop
 username and Steam username. We can then get you access to all past
 and future Valve-produced games available on Steam[1].
 
 Thanks for all the great work, and enjoy.
 
 Cheers,
 Daniel
 
 [0]: Or DRI-type stuff in the kernel too.
 [1]: Currently this looks like
 https://store.steampowered.com/search/?snr=1_4_4__12term=#category1=998publisher=Valvesort_order=ASCpage=1
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


pgpoAv1E7XAHx.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] FOSDEM15: Graphics DevRoom: call for speakers.

[Thierry Reding]

On Tue, Dec 09, 2014 at 03:39:26PM +0100, Luc Verhaegen wrote:
 On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
  Hi,
  
  At FOSDEM on the 31st of january and the 1st of February 2015, there 
  will be another graphics DevRoom. URL: https://fosdem.org/2015/
 
  Slots will be handed out on a first come, first serve basis. The best 
  slots will go to those who apply the earliest. The amount of slots is 
  currently not known yet, but i expect there to be around 16 available (8 
  on each day), so act quickly.
 
  As for deadlines, i hope to have a pretty much complete schedule between 
  christmas and the new year. The rockhard printed schedule deadline is 
  probably January 9th, after that you will not be featured in the booklet 
  and you will have a lot less visitors. I will hopefully be able to lock 
  down entries and descriptions after that date.
 
 It's been more than 2 months since the original email, it's less than 
 two months away from the event, and one month away from what usually is 
 the deadline for the booklet. File your talk now, while there are still 
 some useful slots available.
 
 Also, for those who have filed already but who have left their abstracts 
 open, please get those filed in ASAP. Your talk will be only be ordered 
 in when at least the basics are provided.

Hi Luc,

I realize I'm terribly late, but it took quite some time to get travel
arranged. Looking at the schedule there still seem to be some free
slots. Does it make sense to still submit a talk? I was asked to give
one on atomic modesetting from a driver developer's perspective.

Thierry


pgpZ7HwNn0W82.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] tegra: Initial support

[Thierry Reding]

On Thu, Nov 27, 2014 at 11:51:08AM -0500, Rob Clark wrote:
 On Thu, Nov 27, 2014 at 11:39 AM, Thierry Reding
 thierry.red...@gmail.com wrote:
  Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
  But the GPU is a pure render node and has no display engine, hence the
  scanout needs to happen on the Tegra display hardware. The GPU and the
  display engine each have a separate DRM device node exposed by the
  kernel.
 
  To make the setup appear as a single device, this driver instantiates
  a Nouveau screen with each instance of a Tegra screen and forwards GPU
  requests to the Nouveau screen. For purposes of scanout it will import
  buffers created on the GPU into the display driver. Handles that
  userspace requests are those of the display driver so that they can be
  used to create framebuffers.
 
  This has been tested with some GBM test programs, as well as kmscube and
  weston. All of those run without modifications, but I'm sure there is a
  lot that can be improved.
 
  TODO:
  - use Nouveau headers to get at the prototype for creating a screen
  - implement enough support to seamlessly integrate with X
  - refactor some of the code to be reusable by other drivers
 
 I haven't looked too carefully at the implementation yet, but couldn't
 you just put in src/gallium/drivers/shim ?  I guess you'd just want a
 small if/else ladder where you create the *actual* screen, to create a
 nouveau screen for tegra, an etnaviv screen for imx, armada, etc..?

That's not how Mesa's loader works. Typically only a file descriptor is
passed in and helpers determine a name for the driver to load, then the
DRI code will load name_dri.so. I don't see how this could be made to
work with a single Gallium driver.

There's also the fact that these drivers need to become very HW-specific
at some point, so sharing a single driver will likely just cause an
explosion of conditionals to special-case for each and everyone of the
drivers.

Lastly, Tegra is also somewhat special in this regard because earlier
generations did have a GPU that's controlled via the same DRM device as
the display part. If ever a Mesa driver shows up for that older GPU we
are going to have a conflict between the shim and the Tegra driver that
isn't going to be easy to untangle. With a separate driver we can use
SoC-specific knowledge to determine whether the driver is running on an
old SoC generation or Tegra K1 and later.

Thierry


pgpwJiZvHdLJl.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Nouveau] [RFC] tegra: Initial support

[Thierry Reding]

On Fri, Nov 28, 2014 at 02:14:24PM +0900, Alexandre Courbot wrote:
 On 11/28/2014 01:39 AM, Thierry Reding wrote:
 Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
 But the GPU is a pure render node and has no display engine, hence the
 scanout needs to happen on the Tegra display hardware. The GPU and the
 display engine each have a separate DRM device node exposed by the
 kernel.
 
 To make the setup appear as a single device, this driver instantiates
 a Nouveau screen with each instance of a Tegra screen and forwards GPU
 requests to the Nouveau screen. For purposes of scanout it will import
 buffers created on the GPU into the display driver. Handles that
 userspace requests are those of the display driver so that they can be
 used to create framebuffers.
 
 This has been tested with some GBM test programs, as well as kmscube and
 weston. All of those run without modifications, but I'm sure there is a
 lot that can be improved.
 
 Tested with kmscube and Weston and I can confirm this works. However, EGL
 clients inside Weston have their window filled with garbage (they seem to
 run fine otherwise). Do you also experience this?

To be honest, that wasn't part of my set of test cases. I had assumed
that since Weston could composite buffers into a final scan out buffer
everything else would just work as well. Do you have any particular
demos that aren't working?

Thierry


pgpqqU8ys0QTu.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] tegra: Initial support

[Thierry Reding]

On Fri, Nov 28, 2014 at 12:32:43AM -0500, Ilia Mirkin wrote:
 On Thu, Nov 27, 2014 at 11:39 AM, Thierry Reding
 thierry.red...@gmail.com wrote:
  Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
  But the GPU is a pure render node and has no display engine, hence the
  scanout needs to happen on the Tegra display hardware. The GPU and the
  display engine each have a separate DRM device node exposed by the
  kernel.
 
  To make the setup appear as a single device, this driver instantiates
  a Nouveau screen with each instance of a Tegra screen and forwards GPU
  requests to the Nouveau screen. For purposes of scanout it will import
  buffers created on the GPU into the display driver. Handles that
  userspace requests are those of the display driver so that they can be
  used to create framebuffers.
 
  This has been tested with some GBM test programs, as well as kmscube and
  weston. All of those run without modifications, but I'm sure there is a
  lot that can be improved.
 
  TODO:
  - use Nouveau headers to get at the prototype for creating a screen
  - implement enough support to seamlessly integrate with X
  - refactor some of the code to be reusable by other drivers
 
  Signed-off-by: Thierry Reding tred...@nvidia.com
 
 With the exception of resource creation, I don't see anything
 tegra-specific in here. Is there perhaps something that could be done
 to abstract that a little more, e.g. a wrapper driver, or...
 something? This is a situation that several mobile GPU's are in,
 AFAIK, and it may be nice to make it work for them as well.

I think it might be possible to factor out some things to reduce some
amount of boilerplate, but I don't expect it to be very much. There is
likely going to be hardware-specific details in each of these drivers
that will be hard to abstract out.

Given that this is the first driver of this sort I have no idea what
other drivers will require, so it doesn't seem wise for me to make this
any more generic. It's very likely to turn out completely wrong. Hence
why I opted for just a straight implementation that would work on Tegra.

That said, if it turns out that drivers for other SoCs need to duplicate
a lot of the code in this driver I'm sure we can find ways to alleviate
some of that. But like I already said in my reply to Rob, I don't think
a common wrapper driver is going to cut it. Perhaps something like the
u_transfer abstraction could work, but there is potential for that to
turn into a midlayer of sorts and actually make things more difficult.

The bottom-line is that the vast majority of the code is really just a
skeleton driver, so it's not unlike any of the existing drivers.
Requiring this particular driver to be common for all mobile SoCs is a
little like saying that Radeon and Nouveau should share code because
they both use PCI as the transport.

 Also, can you explain why it's advantageous for the setup to appear as
 though it is a single device? i.e. what's wrong with just using
 nouveau as a render node or whatever? [The answer may be simple, but
 I'm very unfamiliar with a lot of that stuff, and perhaps others are
 in a similar predicament.]

There are two reasons. For one, pretty much every software out there
that runs on the bare metal (i.e. GBM) uses the same initialization
sequence and it doesn't involve opening two DRM devices. So in order to
support Tegra and other SoCs with a similar architecture, each of these
applications would need to be patched. Now typically a lot of the
applications would run under X or Wayland, so the number of applications
that need patching is somewhat reduced. However, it would still mean
that every Wayland compositor would need to be patched in order to
support this, and each of them would use a mostly identical copy of that
code.

The second reason derives from the first. One of the issues I ran into
when I prototyped the dual-fd code for kmscube was that the code to
share these buffers between GPU and display is in fact highly hardware-
specific. At least on Tegra it is, because we can take advantage of the
tight coupling between GPU and display by directly scanning out block-
linear buffers. For that to work we need to make assumptions and that
just doesn't work generically.

So we need to solve two problems: reduce code duplication and hide the
hardware specific details. The natural solution for these two problems
is to move the code into a library. But we already have that library:
Mesa/GBM.

  diff --git a/src/gallium/winsys/tegra/drm/Makefile.am 
  b/src/gallium/winsys/tegra/drm/Makefile.am
  new file mode 100644
  index ..8e3685ee20e8
  --- /dev/null
  +++ b/src/gallium/winsys/tegra/drm/Makefile.am
  @@ -0,0 +1,11 @@
  +include Makefile.sources
  +include $(top_srcdir)/src/gallium/Automake.inc
  +
  +AM_CFLAGS = \
  +   -I$(top_srcdir)/src/gallium/drivers \
  +   $(GALLIUM_WINSYS_CFLAGS) \
  +   $(FREEDRENO_CFLAGS)
 
 oops?

Yes, I wanted to make it obvious from

Re: [Mesa-dev] [Nouveau] [RFC] tegra: Initial support

[Thierry Reding]

On Fri, Nov 28, 2014 at 05:52:26PM +0900, Alexandre Courbot wrote:
 On Fri, Nov 28, 2014 at 5:48 PM, Thierry Reding
 thierry.red...@gmail.com wrote:
  On Fri, Nov 28, 2014 at 02:14:24PM +0900, Alexandre Courbot wrote:
  On 11/28/2014 01:39 AM, Thierry Reding wrote:
  Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
  But the GPU is a pure render node and has no display engine, hence the
  scanout needs to happen on the Tegra display hardware. The GPU and the
  display engine each have a separate DRM device node exposed by the
  kernel.
  
  To make the setup appear as a single device, this driver instantiates
  a Nouveau screen with each instance of a Tegra screen and forwards GPU
  requests to the Nouveau screen. For purposes of scanout it will import
  buffers created on the GPU into the display driver. Handles that
  userspace requests are those of the display driver so that they can be
  used to create framebuffers.
  
  This has been tested with some GBM test programs, as well as kmscube and
  weston. All of those run without modifications, but I'm sure there is a
  lot that can be improved.
 
  Tested with kmscube and Weston and I can confirm this works. However, EGL
  clients inside Weston have their window filled with garbage (they seem to
  run fine otherwise). Do you also experience this?
 
  To be honest, that wasn't part of my set of test cases. I had assumed
  that since Weston could composite buffers into a final scan out buffer
  everything else would just work as well. Do you have any particular
  demos that aren't working?
 
 Anything using EGL under Wayland - the simplest case would be
 weston-simple-egl. glmark2 also displays a broken window, but then
 crashes shortly after. With weston-simpe-egl I get the framerate
 feedback and can see the GPU performance counters moving as expected,
 indicating that the app is rendering correctly but that Weston gets
 the wrong buffer to display.

Okay, I'll need to look into this more closely. Thanks for reporting.

Thierry


pgpPQF3Qf4zMG.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [RFC] tegra: Initial support

[Thierry Reding]

Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
But the GPU is a pure render node and has no display engine, hence the
scanout needs to happen on the Tegra display hardware. The GPU and the
display engine each have a separate DRM device node exposed by the
kernel.

To make the setup appear as a single device, this driver instantiates
a Nouveau screen with each instance of a Tegra screen and forwards GPU
requests to the Nouveau screen. For purposes of scanout it will import
buffers created on the GPU into the display driver. Handles that
userspace requests are those of the display driver so that they can be
used to create framebuffers.

This has been tested with some GBM test programs, as well as kmscube and
weston. All of those run without modifications, but I'm sure there is a
lot that can be improved.

TODO:
- use Nouveau headers to get at the prototype for creating a screen
- implement enough support to seamlessly integrate with X
- refactor some of the code to be reusable by other drivers

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 configure.ac   |  12 +-
 src/gallium/Makefile.am|   5 +
 .../auxiliary/target-helpers/inline_drm_helper.h   |  30 +
 src/gallium/drivers/tegra/Automake.inc |  11 +
 src/gallium/drivers/tegra/Makefile.am  |  17 +
 src/gallium/drivers/tegra/Makefile.sources |   4 +
 src/gallium/drivers/tegra/tegra_context.c  | 699 +
 src/gallium/drivers/tegra/tegra_context.h  |  80 +++
 src/gallium/drivers/tegra/tegra_resource.c | 219 +++
 src/gallium/drivers/tegra/tegra_resource.h |  98 +++
 src/gallium/drivers/tegra/tegra_screen.c   | 311 +
 src/gallium/drivers/tegra/tegra_screen.h   |  45 ++
 src/gallium/targets/dri/Makefile.am|   2 +
 src/gallium/winsys/tegra/drm/Makefile.am   |  11 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |   2 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|  31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|  33 +
 17 files changed, 1609 insertions(+), 1 deletion(-)
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/drivers/tegra/Makefile.sources
 create mode 100644 src/gallium/drivers/tegra/tegra_context.c
 create mode 100644 src/gallium/drivers/tegra/tegra_context.h
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.c
 create mode 100644 src/gallium/drivers/tegra/tegra_resource.h
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.c
 create mode 100644 src/gallium/drivers/tegra/tegra_screen.h
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

diff --git a/configure.ac b/configure.ac
index 1d9d015481ec..ae50bec95339 100644
--- a/configure.ac
+++ b/configure.ac
@@ -33,6 +33,7 @@ LIBDRM_INTEL_REQUIRED=2.4.52
 LIBDRM_NVVIEUX_REQUIRED=2.4.33
 LIBDRM_NOUVEAU_REQUIRED=2.4.33 libdrm = 2.4.41
 LIBDRM_FREEDRENO_REQUIRED=2.4.57
+LIBDRM_TEGRA_REQUIRED=2.4.58
 DRI2PROTO_REQUIRED=2.6
 DRI3PROTO_REQUIRED=1.0
 PRESENTPROTO_REQUIRED=1.0
@@ -733,7 +734,7 @@ GALLIUM_DRIVERS_DEFAULT=r300,r600,svga,swrast
 AC_ARG_WITH([gallium-drivers],
 [AS_HELP_STRING([--with-gallium-drivers@:@=DIRS...@:@],
 [comma delimited Gallium drivers list, e.g.
-i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,vc4
+i915,ilo,nouveau,r300,r600,radeonsi,freedreno,tegra,svga,swrast,vc4
 @:@default=r300,r600,svga,swrast@:@])],
 [with_gallium_drivers=$withval],
 [with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT])
@@ -1937,6 +1938,12 @@ if test -n $with_gallium_drivers; then
 gallium_require_drm freedreno
 gallium_require_drm_loader
 ;;
+xtegra)
+HAVE_GALLIUM_TEGRA=yes
+PKG_CHECK_MODULES([TEGRA], [libdrm_tegra = 
$LIBDRM_TEGRA_REQUIRED])
+gallium_require_drm tegra
+gallium_require_drm_loader
+;;
 xswrast)
 HAVE_GALLIUM_SOFTPIPE=yes
 if test x$MESA_LLVM = x1; then
@@ -2018,6 +2025,7 @@ AM_CONDITIONAL(HAVE_GALLIUM_RADEON_COMMON, test 
x$HAVE_GALLIUM_R600 = xyes -o
 x$HAVE_GALLIUM_RADEONSI = 
xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_NOUVEAU, test x$HAVE_GALLIUM_NOUVEAU = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_FREEDRENO, test x$HAVE_GALLIUM_FREEDRENO = xyes)
+AM_CONDITIONAL(HAVE_GALLIUM_TEGRA, test x$HAVE_GALLIUM_TEGRA = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_SOFTPIPE, test x$HAVE_GALLIUM_SOFTPIPE = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_LLVMPIPE, test x$HAVE_GALLIUM_LLVMPIPE = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_VC4, test x

Re: [Mesa-dev] [PATCH] dri/kms: Always zero out struct drm_mode_create_dumb

[Thierry Reding]

On Sun, Nov 16, 2014 at 01:37:52AM +, Emil Velikov wrote:
 On 13/11/14 18:05, Thierry Reding wrote:
  From: Thierry Reding tred...@nvidia.com
  
  The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously
  specified, which has the effect that some kernel drivers do not consider
  the .pitch and .size fields of struct drm_mode_create_dumb outputs only.
  Instead they will use these as lower bounds and overwrite them only if
  the values that they compute are larger than what userspace provided.
  
  This works if and only if userspace initializes the fields explicitly to
  either 0 or some meaningful value. However, if userspace just leaves the
  values uninitialized and the struct drm_mode_create_dumb is allocated on
  the stack for example, the driver may try to overallocate buffers.
  
  Fortunately most userspace does zero out the structure before passing it
  to the IOCTL, but there are rare exceptions. Mesa is one of them. In an
  attempt to rectify this situation, kernel drivers are being updated to
  not use the .pitch and .size fields as inputs. However in order to fix
  the issue with older kernels, make sure that Mesa always zeros out the
  structure as well.
  
  Future IOCTLs should be more rigorously defined so that structures can
  be validated and IOCTLs rejected if output fields aren't set to zero.
  
 Thanks Thierry.
 
 I'm pretty sure the intent here was not to misuse the API, yet again
 zeroing the struct sounds like a good idea. I've added Daniel's r-b and
 pushed this to master.

I didn't mean to imply that there were any such intentions. In fact the
API documents that these fields are outputs so it shouldn't be necessary
to set them. As such, the Mesa code wasn't doing anything wrong. But it
turns out this documentation wasn't sufficient and some drivers used the
fields nevertheless.

 Do you think it's of any use if we push this for the stable branches ?
 I've not checked your drm changes, this I don't know if we actually
 check/validate pitch  size. Is the ioctl going to carry on, throw a
 warning or just error out ?

I don't think this needs to go into stable branches. The only drivers
that were using this were ones that are unlikely to be used with Mesa.
The only reason I noticed is because I've been working on a patch that
lets Nouveau integrate better on Tegra, which has the side-effect of
these dumb buffer allocations going through the Tegra DRM driver.

The DRM changes happened in two parts: first all drivers that were
abusing these fields were changed not to do that anymore. The second
change was to zero out these fields in the DRM core before the IOCTL
data is passed into drivers so that new drivers won't fall into the
same trap. That means even for the rare cases where this is actually
relevant new kernels will be able to cope with older Mesa releases.

For future IOCTLs the decision was made to better document inputs and
outputs as well as require outputs to be zeroed out by userspace so that
the kernel can run some sanity checks and refuse an IOCTL with invalid
input/output.

Thierry


pgpxW2UEgGUQZ.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))

[Thierry Reding]

On Sun, Jan 12, 2014 at 10:34:19AM -0800, Keith Packard wrote:
 the drmServerInfo member, debug_print, takes a printf format string
 and varargs list. Tell the compiler about it.
 
 Signed-off-by: Keith Packard kei...@keithp.com
 ---
  xf86drm.h | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/xf86drm.h b/xf86drm.h
 index 1e763a3..5e170f8 100644
 --- a/xf86drm.h
 +++ b/xf86drm.h
 @@ -92,8 +92,14 @@ extern C {
  typedef unsigned int  drmSize, *drmSizePtr;  /** For mapped 
 regions */
  typedef void  *drmAddress, **drmAddressPtr; /** For mapped regions 
 */
  
 +#if (__GNUC__ = 3)
 +#define DRM_PRINTFLIKE(f, a) __attribute__ ((format(__printf__, f, a)))
 +#else
 +#define DRM_PRINTFLIKE(f, a)
 +#endif
 +
  typedef struct _drmServerInfo {
 -  int (*debug_print)(const char *format, va_list ap);
 +  int (*debug_print)(const char *format, va_list ap) DRM_PRINTFLIKE(1,0);
int (*load_module)(const char *name);
void (*get_perms)(gid_t *, mode_t *);
  } drmServerInfo, *drmServerInfoPtr;

While at it, perhaps the drmMsg() and drmDebugPrint() functions should
be similarily annotated as well?

Thierry


pgpizPDWnAMD5.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] rules for merging patches to libdrm

[Thierry Reding]

On Mon, Nov 18, 2013 at 01:38:55PM -0500, Jerome Glisse wrote:
 On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote:
  On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote:
   On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding
   thierry.red...@gmail.com wrote:
On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding
thierry.red...@gmail.com wrote:
 On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote:
 On 11/09/2013 12:11 AM, Dave Airlie wrote:
  How does this interact with the rule that kernel interfaces 
  require an
  open source userspace? Is here are the mesa/libdrm patches 
  that use
  it sufficient to get the kernel interface merged?
 
  That's my understanding: open source userspace needs to exist, 
  but it
  doesn't need to be merged upstream yet.
 
  Having an opensource userspace and having it committed to a final 
  repo
  are different things, as Daniel said patches on the mesa-list were
  sufficient, they're was no hurry to merge them considering a 
  kernel
  release with the code wasn't close, esp with a 3 month release 
  window
  if the kernel merge window is close to that anyways.
 
  libdrm is easy to change and its releases are cheap. What 
  problem does
  committing code that uses an in-progress kernel interface to 
  libdrm
  cause? I guess I'm not understanding something.
 
 
  Releases are cheap, but ABI breaks aren't so you can't just go 
  release
  a libdrm with an ABI for mesa then decide later it was a bad plan.
 
  Introducing new kernel API usually involves assigning numbers 
  for things
  - a new ioctl number, new #defines for bitfield members, and so 
  on.
 
  Multiple patches can be in flight at the same time.  For 
  example, Abdiel
  and I both defined execbuf2 flags:
 
  #define I915_EXEC_RS (1  13) (Abdiel's code)
  #define I915_EXEC_OA (1  13) (my code)
 
  These obviously conflict.  One of the two will land, and the 
  second
  patch author will need to switch to (1  14) and resubmit.
 
  If we both decide to push to libdrm, we might get the order 
  backwards,
  or maybe one series won't get pushed at all (in this case, I'm 
  planning
  to drop my patch).  Waiting until one lands in the kernel avoids 
  that
  problem.  Normally, I believe we copy the kernel headers to 
  userspace
  and fix them up a bit.
 
  Dave may have other reasons; this is just the one I thought of.
 
  But mostly this, we've been stung by this exact thing happening
  before, and we made the process to stop it from happening again.

 Then in all honestly, commits to libdrm should be controlled by 
 either a
 single person or a small cabal... just like the kernel and the 
 xserver.
  We're clearly in an uncomfortable middle area where we have a 
 stringent
 set of restrictions but no way to actually enforce them.

 That doesn't sound like a bad idea at all. It obviously causes more 
 work
 for whoever will be the gatekeeper(s).

 It seems to me that libdrm is currently more of a free-for-all type 
 of
 project, and whoever merges some new feature required for a 
 particular X
 or Mesa driver cuts a new release so that the version number can be 
 used
 to track the dependency.

 I wonder if perhaps tying the libdrm releases more tightly to Linux
 kernel releases would help. Since there already is a requirement for 
 new
 kernel APIs to be merged before the libdrm equivalent can be merged,
 then having both release cycles in lockstep makes some sense.
   
Not sure about strictly tying it to kernel releases would be ideal.
Not *everything* in libdrm is about new kernel APIs.  It tends to be
the place for things needed both by xorg ddx and mesa driver, which I
suppose is why it ends up a bit of a free-for-all.
   
I didn't mean that every release would need to be tied to the Linux
kernel. But whenever a new Linux kernel release was made, relevant
changes from the public headers could be pulled into libdrm and a
release be made. I could even imagine a matching of version numbers.
libdrm releases could be numbered using the same major and minor as
Linux kernels that they support. Micro version numbers could be used
in intermediate releases.
   
   maybe an update-kernel-headers.sh script to grab the headers from
   drm-next and update libdrm wouldn't be a bad idea?
  
  Perhaps. But I think it could even be a manual step. It's not something
  that one person should be doing alone, but rather something that driver
  maintainers should be doing, since they know best what will be needed
  in a new version of libdrm

Re: [Mesa-dev] rules for merging patches to libdrm

[Thierry Reding]

On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote:
 On 11/09/2013 12:11 AM, Dave Airlie wrote:
  How does this interact with the rule that kernel interfaces require an
  open source userspace? Is here are the mesa/libdrm patches that use
  it sufficient to get the kernel interface merged?
 
  That's my understanding: open source userspace needs to exist, but it
  doesn't need to be merged upstream yet.
  
  Having an opensource userspace and having it committed to a final repo
  are different things, as Daniel said patches on the mesa-list were
  sufficient, they're was no hurry to merge them considering a kernel
  release with the code wasn't close, esp with a 3 month release window
  if the kernel merge window is close to that anyways.
  
  libdrm is easy to change and its releases are cheap. What problem does
  committing code that uses an in-progress kernel interface to libdrm
  cause? I guess I'm not understanding something.
 
  
  Releases are cheap, but ABI breaks aren't so you can't just go release
  a libdrm with an ABI for mesa then decide later it was a bad plan.
  
  Introducing new kernel API usually involves assigning numbers for things
  - a new ioctl number, new #defines for bitfield members, and so on.
 
  Multiple patches can be in flight at the same time.  For example, Abdiel
  and I both defined execbuf2 flags:
 
  #define I915_EXEC_RS (1  13) (Abdiel's code)
  #define I915_EXEC_OA (1  13) (my code)
 
  These obviously conflict.  One of the two will land, and the second
  patch author will need to switch to (1  14) and resubmit.
 
  If we both decide to push to libdrm, we might get the order backwards,
  or maybe one series won't get pushed at all (in this case, I'm planning
  to drop my patch).  Waiting until one lands in the kernel avoids that
  problem.  Normally, I believe we copy the kernel headers to userspace
  and fix them up a bit.
 
  Dave may have other reasons; this is just the one I thought of.
  
  But mostly this, we've been stung by this exact thing happening
  before, and we made the process to stop it from happening again.
 
 Then in all honestly, commits to libdrm should be controlled by either a
 single person or a small cabal... just like the kernel and the xserver.
  We're clearly in an uncomfortable middle area where we have a stringent
 set of restrictions but no way to actually enforce them.

That doesn't sound like a bad idea at all. It obviously causes more work
for whoever will be the gatekeeper(s).

It seems to me that libdrm is currently more of a free-for-all type of
project, and whoever merges some new feature required for a particular X
or Mesa driver cuts a new release so that the version number can be used
to track the dependency.

I wonder if perhaps tying the libdrm releases more tightly to Linux
kernel releases would help. Since there already is a requirement for new
kernel APIs to be merged before the libdrm equivalent can be merged,
then having both release cycles in lockstep makes some sense.

Thierry


pgpPYeCMOUxLk.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev