Re: [Mesa-dev] [PATCH] gallium: add Tegra renderonly support

[Alexandre Courbot]

On 01/13/2017 11:20 PM, Grazvydas Ignotas wrote:
> just out of the interest, can this be used on Tegra X1 right now?
> If so, what would I need to get it to work (kernel, firmware, something else)?
> I'd be interested to run mesa on the Shield TV.

I recommend using my Mesa branch (https://github.com/Gnurou/mesa) for
minimum hassle, as it includes a few extra hacks for Tegra (not all of
which may be needed, but just to be on the safe side). Compile with the
following options:

https://github.com/NVIDIA/tegra-rootfs-scripts/blob/master/build-mesa

Also use the most recent kernel with CONFIG_DRM_TEGRA_STAGING set and
you should have a working system! No need to modify userspace apps with
this hack.

The required firmware for TX1 is already in linux-firmware, so if you
have it installed you should have everything that is required.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium: add Tegra renderonly support

[Alexandre Courbot]

From: Christian Gmeiner 

Based on the same model as the IMX driver, opens a Nouveau render device
in order to transparently provide acceleration on Tegra.

Signed-off-by: Christian Gmeiner 
[acour...@nvidia.com: port to latest branch, minor improvements]
Signed-off-by: Alexandre Courbot 
---
 configure.ac   |  9 ++-
 src/gallium/Makefile.am|  4 ++
 .../auxiliary/pipe-loader/pipe_loader_drm.c|  5 ++
 src/gallium/auxiliary/target-helpers/drm_helper.h  | 22 +++
 .../auxiliary/target-helpers/drm_helper_public.h   |  3 +
 src/gallium/drivers/nouveau/nouveau_buffer.c   |  3 +
 src/gallium/drivers/nouveau/nouveau_buffer.h   |  2 +
 src/gallium/drivers/nouveau/nouveau_screen.h   |  3 +
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  3 +
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c   | 18 +-
 src/gallium/drivers/tegra/Automake.inc |  9 +++
 src/gallium/drivers/tegra/Makefile.am  |  9 +++
 src/gallium/targets/dri/Makefile.am|  2 +
 src/gallium/targets/dri/target.c   | 11 
 .../winsys/nouveau/drm/nouveau_drm_public.h|  2 +
 .../winsys/nouveau/drm/nouveau_drm_winsys.c| 10 +++
 src/gallium/winsys/tegra/drm/Android.mk| 33 ++
 src/gallium/winsys/tegra/drm/Makefile.am   | 34 ++
 src/gallium/winsys/tegra/drm/Makefile.sources  |  3 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|  8 +++
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c| 74 ++
 src/mesa/drivers/dri/nouveau/nouveau_screen.h  |  1 +
 22 files changed, 265 insertions(+), 3 deletions(-)
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Android.mk
 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 bc92fb5535c1..4b90b65805e3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1234,7 +1234,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,virgl,etnaviv,imx"
+
"i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,vc4,virgl,etnaviv,imx,tegra"
 @<:@default=r300,r600,svga,swrast@:>@])],
 [with_gallium_drivers="$withval"],
 [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
@@ -2559,6 +2559,10 @@ if test -n "$with_gallium_drivers"; then
 require_libdrm "virgl"
 require_basic_egl "virgl"
 ;;
+xtegra)
+HAVE_GALLIUM_TEGRA=yes
+require_libdrm "tegra"
+;;
 *)
 AC_MSG_ERROR([Unknown Gallium driver: $driver])
 ;;
@@ -2643,6 +2647,7 @@ 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_ETNAVIV, test "x$HAVE_GALLIUM_ETNAVIV" = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_IMX, test "x$HAVE_GALLIUM_IMX" = 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_SWR, test "x$HAVE_GALLIUM_SWR" = xyes)
@@ -2800,6 +2805,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/drivers/imx/Makefile
src/gallium/drivers/vc4/Makefile
src/gallium/drivers/virgl/Makefile
+   src/gallium/drivers/tegra/Makefile
src/gallium/state_trackers/clover/Makefile
src/gallium/state_trackers/dri/Makefile
src/gallium/state_trackers/glx/xlib/Makefile
@@ -2844,6 +2850,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/winsys/vc4/drm/Makefile
src/gallium/winsys/virgl/drm/Makefile
src/gallium/winsys/virgl/vtest/Makefile
+   src/gallium/winsys/tegra/drm/Makefile
src/gbm/Makefile
src/gbm/main/gbm.pc
src/glx/Makefile
diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am
index f910f3187eb4..0f887d220d5b 100644
--- a/src/gallium/Makefile.am
+++ b/src/gallium/Makefile.am
@@ -100,6 +100,10 @@ if HAVE_GALLIUM_VIRGL
 SUBDIRS += drivers/virgl wi

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

[Alexandre Courbot]

On 12/24/2016 07:04 AM, Christian Gmeiner wrote:
> This a very lightweight library to add basic support for renderonly
> GPUs. A kms gallium driver must specify how a renderonly_scanout
> objects gets created. Also it must provide file handles to the used
> kms device and the used gpu device.
> 
> This could look like:
> struct renderonly ro = {
>.create_for_resource = renderonly_create_gpu_import_for_resource,
>.kms_fd = fd,
>.gpu_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC)
> };
> 
> The renderonly_scanout object exits for two reasons:
>  - Do any special treatment for a scanout resource like importing the
>GPU resource into the scanout hw.
>  - Make it easier for a gallium driver to detect if anything special
>needs to be done in flush_resource(..) like a resolve to linear.
> 
> A GPU gallium driver which gets used as renderonly GPU needs to be
> aware of the renderonly library.
> 
> This library will likely break android support and hopefully will get
> replaced with a better solution based on gbm2.
> 
> Changes from V1 -> V2:
>  - reworked the lifecycle of renderonly object (suggested by Nicolai Hähnle)
>  - killed the midlayer (suggested by Thierry Reding)
>  - made the API more explicit regarding gpu and kms fd's
>  - added some docs

Works fine with Tegra (see
https://github.com/Gnurou/mesa/tree/renderonly for the code, still hacky).

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

Re: [Mesa-dev] [PATCH 0/5] nvc0: better instruction pipelining for Maxwell GPUs

[Alexandre Courbot]

On 12/23/2016 08:15 AM, Samuel Pitoiset wrote:
> This series makes use of the scheduling control code in order to improve the
> instruction pipelining on Maxwell GPUs.

Tested this on Jetson TX1. The performance improvement on glmark2 was
only marginal, with terrain going from 7 to 10 fps at pstate 01 and from
29 to 33 fps at pstate 0d (probably due to some other non-shader related
bottleneck on this board?), but I have not noticed any issue.

Tested-by: Alexandre Courbot 
___
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

[Alexandre Courbot]

On Mon, Dec 19, 2016 at 10:19 PM, Thierry Reding
 wrote:
> On Mon, Dec 19, 2016 at 04:04:34PM +, Emil Velikov wrote:
>> On Monday, 19 December 2016, Thierry Reding 
>> 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.

No strong opinion, although I suppose basic functionality with some
assumptions (i.e. that we don't have a discrete GPU on the board) is
better than no functionality at all, and we can always improve Tegra
support incrementally. We are close enough to not requiring any
out-of-tree patches that I am ok with a temporary compromise.
___
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

[Alexandre Courbot]

Hi Emil,

On 12/09/2016 11:20 PM, Emil Velikov wrote:
> On 9 December 2016 at 13:20, Alexandre Courbot  wrote:
>> On 12/08/2016 04:16 PM, Alexandre Courbot wrote:
>>> On 11/30/2016 10:44 PM, 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.
>>>
>>> Since we have no idea when said better solution will be available, and
>>> the situation of render-only GPUs has been unsustainable for way too
>>> long, I really hope a solution like this one can be merged in the meantime.
>>>
>>> I have tried it after porting support for Tegra
>>> (https://github.com/austriancoder/mesa/commit/2c7354701ee21ca28f69f5d7588f1d497553b4bf)
>>> to this latest version. Here are a few issues I have met:
>>>
>>> First, setting the tiling works indeed just fine if we are using an
>>> ioctl for this. However my impression was that the preferred way of
>>> doing it was through FB modifiers, and we started moving Tegra to this
>>> scheme. Problem: the FB modifier is passed through a call to
>>> drmModeAddFB2WithModifiers(), which is called by the client program, not
>>> Mesa - which in this case leaves the program with the burden of figuring
>>> out what the modifier should be. So with FB modifiers the problem is
>>> still here.
>>>
>>> Another issue I have seen is that GLX does not seem to work with this.
>>> X/modesetting starts just fine, and GLamor also seems to initialize.
>>> However glxinfo freezes on a xshmfence_await() call, and all GLX
>>> programs fail as follow:
>>
>> Solved that issue by forcing is_different_gpu to true in
>> loader_dri3_drawable_init() (pretty hackish, looking for a better way).
>>
>> Also I had another issue with Wayland where EGL windows would be
>> displayed all black. I traced this to the fact that Wayland was trying
>> to share the buffer by calling the old FLINK ioctl on the rendernode
>> device, which is forbidden. Opening card1 instead of renderD128 did the
>> trick as a workaround, but I am surprised as I thought Wayland was using
>> DRI3 exclusively? I am not very familiar with neither Mesa nor Wayland
>> though, so my assumption may very well be incorrect.
>>
> Some of these issues is due to the hardcoded nature of the card/render
> node. I've had drmDevice API which could/should be extended and
> utilised here.
> Earlier versions were quite buggy, so make sure to use
> 677cd97dc4a930af508388713f5016baf664ed18 or later.

My libdrm was 2.4.74, so I think this patch is there.

> 
> Since from kernel there is no relation between the KMS and GPU device,
> one will need to apply some heuristics locally. At some point we might
> want to make things more systematic/configurable, but let's get it
> working first ;-)
> 
> Thus, please propose/add anything to drmDevice that will you think is
> enough to build some heuristics on.
> 
> With that sorted, the Wayland FLINK issues should go away.

Thanks for the hint. I will look into that.
___
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

[Alexandre Courbot]

Hi Daniel,

On 12/09/2016 11:13 PM, Daniel Stone wrote:
> Hi Alexandre,
> 
> On 9 December 2016 at 13:20, Alexandre Courbot  wrote:
>> On 12/08/2016 04:16 PM, Alexandre Courbot wrote:
>>> First, setting the tiling works indeed just fine if we are using an
>>> ioctl for this. However my impression was that the preferred way of
>>> doing it was through FB modifiers, and we started moving Tegra to this
>>> scheme. Problem: the FB modifier is passed through a call to
>>> drmModeAddFB2WithModifiers(), which is called by the client program, not
>>> Mesa - which in this case leaves the program with the burden of figuring
>>> out what the modifier should be. So with FB modifiers the problem is
>>> still here.
>>>
>>> Another issue I have seen is that GLX does not seem to work with this.
>>> X/modesetting starts just fine, and GLamor also seems to initialize.
>>> However glxinfo freezes on a xshmfence_await() call, and all GLX
>>> programs fail as follow:
>>
>> Solved that issue by forcing is_different_gpu to true in
>> loader_dri3_drawable_init() (pretty hackish, looking for a better way).
>>
>> Also I had another issue with Wayland where EGL windows would be
>> displayed all black. I traced this to the fact that Wayland was trying
>> to share the buffer by calling the old FLINK ioctl on the rendernode
>> device, which is forbidden. Opening card1 instead of renderD128 did the
>> trick as a workaround, but I am surprised as I thought Wayland was using
>> DRI3 exclusively? I am not very familiar with neither Mesa nor Wayland
>> though, so my assumption may very well be incorrect.
> 
> Wayland doesn't use DRI-anything; Mesa has its own interface for
> Wayland. I'm really surprised that you're seeing this behaviour
> though: if you search for WL_DRM_CAPABILITY_PRIME (i.e. send dmabufs
> rather than flink names) in src/egl/drivers/dri2/platform_wayland.c,
> you'll see that a) we always use it when available, and b) we refuse
> to initialise when the device is a rendernode and we don't have PRIME.
> So I'm not sure how this could ever happen ...

Interesting. I will try to get to the bottom of this as a way to improve
my (weak) understanding of Mesa.

> 
>> Anyway, with this patch and the corresponding Tegra support, I have a
>> working solution that can run unmodified Mesa applications using KMS,
>> EGL/Wayland and GLX backends on TK1 and TX1 platforms. Neat!
> 
> Cool! I assume this will work on Tegra124 more generally then - do you
> have a branch somewhere?

Yes, anything using Tegra124 or Tegra210 with working display drivers (a
few Chromebooks so far, and probably the Pixel C sometime soon) should
directly benefit from it.

I have pushed a branch (just Christian's initial branch + a port of his
first Tegra patch and my hacks to make Wayland and GLX work) here:
https://github.com/Gnurou/mesa/tree/renderonly

> 
>> Considering that we have been ressorting to hacking all the KMS
>> applications of interest to connect the render and display nodes
>> together with the right tiling settings for the last two years, I regard
>> this patch as a huge improvement for mobile graphics and would like to
>> strongly support it.
>>
>> My only remaining concern is that this scheme cannot support the case
>> where the tiling format is specified using FB modifiers, since this
>> requires drmModeAddFB2WithModifiers() to be called from the application.
>> So for Tegra we have to resort to a staging, not enabled by default
>> SET_TILING ioctl. Not ideal, but recompiling your kernel with an
>> additional config option is much less a hassle than patching every KMS
>> app under the sun.
>>
>> So while thoughts about how this last issue can be addressed are
>> welcome, I think this little lib can improve the life of many SoC users.
> 
> Check out Ben Widawsky's 'Renderbuffer Decompression (and GBM
> modifiers)' patchset. With this, as well as krh's pending GETPLANE2
> ioctl that will allow us to get a list of acceptable modifiers for
> display from KMS, we can trivially implement this in clients without
> the need for a backchannel ioctl:
> https://git.collabora.com/cgit/user/daniels/weston.git/commit/?h=wip/2016-11/gbm-planes-modifiers

That should make a good reading for the weekend. :) Thanks!

Alex.
___
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

[Alexandre Courbot]

On 12/08/2016 04:16 PM, Alexandre Courbot wrote:
> On 11/30/2016 10:44 PM, 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.
> 
> Since we have no idea when said better solution will be available, and
> the situation of render-only GPUs has been unsustainable for way too
> long, I really hope a solution like this one can be merged in the meantime.
> 
> I have tried it after porting support for Tegra
> (https://github.com/austriancoder/mesa/commit/2c7354701ee21ca28f69f5d7588f1d497553b4bf)
> to this latest version. Here are a few issues I have met:
> 
> First, setting the tiling works indeed just fine if we are using an
> ioctl for this. However my impression was that the preferred way of
> doing it was through FB modifiers, and we started moving Tegra to this
> scheme. Problem: the FB modifier is passed through a call to
> drmModeAddFB2WithModifiers(), which is called by the client program, not
> Mesa - which in this case leaves the program with the burden of figuring
> out what the modifier should be. So with FB modifiers the problem is
> still here.
> 
> Another issue I have seen is that GLX does not seem to work with this.
> X/modesetting starts just fine, and GLamor also seems to initialize.
> However glxinfo freezes on a xshmfence_await() call, and all GLX
> programs fail as follow:

Solved that issue by forcing is_different_gpu to true in
loader_dri3_drawable_init() (pretty hackish, looking for a better way).

Also I had another issue with Wayland where EGL windows would be
displayed all black. I traced this to the fact that Wayland was trying
to share the buffer by calling the old FLINK ioctl on the rendernode
device, which is forbidden. Opening card1 instead of renderD128 did the
trick as a workaround, but I am surprised as I thought Wayland was using
DRI3 exclusively? I am not very familiar with neither Mesa nor Wayland
though, so my assumption may very well be incorrect.

Anyway, with this patch and the corresponding Tegra support, I have a
working solution that can run unmodified Mesa applications using KMS,
EGL/Wayland and GLX backends on TK1 and TX1 platforms. Neat!

Considering that we have been ressorting to hacking all the KMS
applications of interest to connect the render and display nodes
together with the right tiling settings for the last two years, I regard
this patch as a huge improvement for mobile graphics and would like to
strongly support it.

My only remaining concern is that this scheme cannot support the case
where the tiling format is specified using FB modifiers, since this
requires drmModeAddFB2WithModifiers() to be called from the application.
So for Tegra we have to resort to a staging, not enabled by default
SET_TILING ioctl. Not ideal, but recompiling your kernel with an
additional config option is much less a hassle than patching every KMS
app under the sun.

So while thoughts about how this last issue can be addressed are
welcome, I think this little lib can improve the life of many SoC users.
___
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

[Alexandre Courbot]

On 11/30/2016 10:44 PM, 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.

Since we have no idea when said better solution will be available, and
the situation of render-only GPUs has been unsustainable for way too
long, I really hope a solution like this one can be merged in the meantime.

I have tried it after porting support for Tegra
(https://github.com/austriancoder/mesa/commit/2c7354701ee21ca28f69f5d7588f1d497553b4bf)
to this latest version. Here are a few issues I have met:

First, setting the tiling works indeed just fine if we are using an
ioctl for this. However my impression was that the preferred way of
doing it was through FB modifiers, and we started moving Tegra to this
scheme. Problem: the FB modifier is passed through a call to
drmModeAddFB2WithModifiers(), which is called by the client program, not
Mesa - which in this case leaves the program with the burden of figuring
out what the modifier should be. So with FB modifiers the problem is
still here.

Another issue I have seen is that GLX does not seem to work with this.
X/modesetting starts just fine, and GLamor also seems to initialize.
However glxinfo freezes on a xshmfence_await() call, and all GLX
programs fail as follow:

# glxgears
libGL error: MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  149 ()
  Minor opcode of failed request:  2
  Serial number of failed request:  37
  Current serial number in output stream:  38

Not sure if you are having these issues with Vivante as well?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 2/2] gallium: add tegra support

[Alexandre Courbot]

On Mon, Oct 12, 2015 at 12:09 AM, Christian Gmeiner
 wrote:
> This commit adds tegra support, which uses the renderonly driver
> library.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  configure.ac   | 19 +++-
>  src/gallium/Makefile.am|  6 +++
>  .../auxiliary/target-helpers/inline_drm_helper.h   | 29 
>  src/gallium/drivers/tegra/Automake.inc | 10 +
>  src/gallium/drivers/tegra/Makefile.am  |  9 
>  src/gallium/targets/dri/Makefile.am|  2 +
>  src/gallium/winsys/tegra/drm/Android.mk| 34 +++
>  src/gallium/winsys/tegra/drm/Makefile.am   | 33 ++
>  src/gallium/winsys/tegra/drm/Makefile.sources  |  3 ++
>  src/gallium/winsys/tegra/drm/tegra_drm_public.h| 31 +
>  src/gallium/winsys/tegra/drm/tegra_drm_winsys.c| 51 
> ++
>  11 files changed, 226 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/winsys/tegra/drm/Android.mk
>  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 ea485b1..9fb8244 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -75,6 +75,7 @@ LIBDRM_INTEL_REQUIRED=2.4.61
>  LIBDRM_NVVIEUX_REQUIRED=2.4.33
>  LIBDRM_NOUVEAU_REQUIRED=2.4.62
>  LIBDRM_FREEDRENO_REQUIRED=2.4.65
> +LIBDRM_TEGRA_REQUIRED=2.4.58
>  DRI2PROTO_REQUIRED=2.6
>  DRI3PROTO_REQUIRED=1.0
>  PRESENTPROTO_REQUIRED=1.0
> @@ -864,7 +865,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,svga,swrast,tegra,vc4"
>  @<:@default=r300,r600,svga,swrast@:>@])],
>  [with_gallium_drivers="$withval"],
>  [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
> @@ -2166,6 +2167,12 @@ if test -n "$with_gallium_drivers"; then
>  HAVE_GALLIUM_LLVMPIPE=yes
>  fi
>  ;;
> +xtegra)
> +HAVE_GALLIUM_TEGRA=yes
> +PKG_CHECK_MODULES([TEGRA], [libdrm_tegra >= 
> $LIBDRM_TEGRA_REQUIRED])
> +gallium_require_drm "tegra"
> +gallium_require_drm_loader
> +;;
>  xvc4)
>  HAVE_GALLIUM_VC4=yes
>  gallium_require_drm "vc4"
> @@ -2181,6 +2188,13 @@ if test -n "$with_gallium_drivers"; then
>  done
>  fi
>
> +dnl We need to validate some needed dependencies for renderonly drivers.
> +
> +if test "x$HAVE_GALLIUM_NOUVEAU" != xyes -a "x$HAVE_GALLIUM_TEGRA" == xyes  
> ; then
> +AC_ERROR([Building with tegra requires that nouveau])
> +fi
> +
> +
>  dnl Set LLVM_LIBS - This is done after the driver configuration so
>  dnl that drivers can add additional components to LLVM_COMPONENTS.
>  dnl Previously, gallium drivers were updating LLVM_LIBS directly
> @@ -2245,6 +2259,7 @@ AM_CONDITIONAL(HAVE_GALLIUM_FREEDRENO, test 
> "x$HAVE_GALLIUM_FREEDRENO" = 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$HAVE_GALLIUM_VC4" = xyes)
> +AM_CONDITIONAL(HAVE_GALLIUM_TEGRA, test "x$HAVE_GALLIUM_TEGRA" = xyes)
>
>  AM_CONDITIONAL(HAVE_GALLIUM_STATIC_TARGETS, test 
> "x$enable_shared_pipe_drivers" = xno)
>
> @@ -2364,6 +2379,7 @@ AC_CONFIG_FILES([Makefile
> src/gallium/drivers/renderonly/Makefile
> src/gallium/drivers/softpipe/Makefile
> src/gallium/drivers/svga/Makefile
> +   src/gallium/drivers/tegra/Makefile
> src/gallium/drivers/trace/Makefile
> src/gallium/drivers/vc4/Makefile
> src/gallium/state_trackers/clover/Makefile
> @@ -2406,6 +2422,7 @@ AC_CONFIG_FILES([Makefile
> src/gallium/winsys/sw/wrapper/Makefile
> src/gallium/winsys/sw/xlib/Makefile
> src/gallium/winsys/vc4/drm/Makefile
> +   src/gallium/winsys/tegra/drm/Makefile
> src/gbm/Makefile
> src/gbm/main/gbm.pc
> src/glsl/Makefile
> diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am
> index a7c3606..7278300 100644
> --- a/src/gallium/Makefile.am
> +++ b/src/gallium/Makefile.am
> @@ -82,6 +82,12 @@ if HAVE_GALLIUM_VC4
>  SUBDIRS += drivers/vc4 winsys/vc4/drm
>  endif
>
> +## tegra
> +if HAVE_GALLI

[Mesa-dev] [PATCH] nvc0: tune PREFER_BLIT_BASED_TEXTURE_TRANSFER capability

[Alexandre Courbot]

Prefer blit-based texture transfers only if the chip has dedicated VRAM
since it would translate to a copy into the same memory on shared-memory
chips.

Signed-off-by: Alexandre Courbot 
Reported-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 95e246b98669..1a8ce3cd68da 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -120,6 +120,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
   return PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50;
case PIPE_CAP_ENDIANNESS:
   return PIPE_ENDIAN_LITTLE;
+   case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
+  return nouveau_screen(pscreen)->vram_domain & NOUVEAU_BO_VRAM ? 1 : 0;
 
/* supported caps */
case PIPE_CAP_TEXTURE_MIRROR_CLAMP:
@@ -163,7 +165,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_USER_CONSTANT_BUFFERS:
case PIPE_CAP_USER_INDEX_BUFFERS:
case PIPE_CAP_USER_VERTEX_BUFFERS:
-   case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
case PIPE_CAP_TEXTURE_QUERY_LOD:
case PIPE_CAP_SAMPLE_SHADING:
case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
-- 
2.4.4

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

Re: [Mesa-dev] [PATCH] nouveau: rename var name for nouveau_vieux to avoid conflict with nouveau

[Alexandre Courbot]

On 07/01/2015 04:49 PM, Ilia Mirkin wrote:

We want to require different versions for nouveau and nouveau_vieux.
autoconf will only check for NOUVEAU once if both drivers are enabled,
meaning both version checks don't get executed. Rename the nouveau_vieux
one to NVVIEUX to avoid the issue.


Tested-by: Alexandre Courbot 

Confirmed that configure properly fails on libdrm < 2.4.62 if both the 
DRI and Gallium drivers are compiled.




Signed-off-by: Ilia Mirkin 
---
  configure.ac | 2 +-
  src/mesa/drivers/dri/nouveau/Makefile.am | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index af61aa2..60d180d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1421,7 +1421,7 @@ if test -n "$with_dri_drivers"; then
  ;;
  xnouveau)
  HAVE_NOUVEAU_DRI=yes;
-PKG_CHECK_MODULES([NOUVEAU], [libdrm_nouveau >= 
$LIBDRM_NVVIEUX_REQUIRED])
+PKG_CHECK_MODULES([NVVIEUX], [libdrm_nouveau >= 
$LIBDRM_NVVIEUX_REQUIRED])
  ;;
  xradeon)
  HAVE_RADEON_DRI=yes;
diff --git a/src/mesa/drivers/dri/nouveau/Makefile.am 
b/src/mesa/drivers/dri/nouveau/Makefile.am
index 61af95a..01e34a8 100644
--- a/src/mesa/drivers/dri/nouveau/Makefile.am
+++ b/src/mesa/drivers/dri/nouveau/Makefile.am
@@ -38,8 +38,8 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/mesa/drivers/dri/common \
$(DEFINES) \
$(VISIBILITY_CFLAGS) \
-   $(NOUVEAU_CFLAGS)
+   $(NVVIEUX_CFLAGS)

  noinst_LTLIBRARIES = libnouveau_dri.la
  libnouveau_dri_la_SOURCES = $(NOUVEAU_C_FILES)
-libnouveau_dri_la_LIBADD = $(NOUVEAU_LIBS)
+libnouveau_dri_la_LIBADD = $(NVVIEUX_LIBS)



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

[Mesa-dev] [PATCH v2] nvc0: create screen fence objects with coherent attribute

[Alexandre Courbot]

This is required on non-coherent architectures to ensure the value of
the fence is correct at all times. Failure to do this results in the
display freezing for a few seconds every now and then on Tegra.

The NOUVEAU_BO_COHERENT is a no-op for coherent architectures, so behavior
on x86 should not be affected by this patch.

Also bump the required libdrm version to 2.4.62, which introduced this
flag.

Signed-off-by: Alexandre Courbot 
Reviewed-by: Martin Peres 
---
 configure.ac   | 2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 8 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index af61aa2018ce..f555fbc520af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -70,7 +70,7 @@ LIBDRM_REQUIRED=2.4.38
 LIBDRM_RADEON_REQUIRED=2.4.56
 LIBDRM_INTEL_REQUIRED=2.4.60
 LIBDRM_NVVIEUX_REQUIRED=2.4.33
-LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
+LIBDRM_NOUVEAU_REQUIRED=2.4.62
 LIBDRM_FREEDRENO_REQUIRED=2.4.57
 DRI2PROTO_REQUIRED=2.6
 DRI3PROTO_REQUIRED=1.0
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 4c53106289ce..95e246b98669 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -614,6 +614,7 @@ nvc0_screen_create(struct nouveau_device *dev)
struct nouveau_pushbuf *push;
uint64_t value;
uint32_t obj_class;
+   uint32_t flags;
int ret;
unsigned i;
 
@@ -669,8 +670,11 @@ nvc0_screen_create(struct nouveau_device *dev)
screen->base.base.get_video_param = nouveau_vp3_screen_get_video_param;
screen->base.base.is_video_format_supported = 
nouveau_vp3_screen_video_supported;
 
-   ret = nouveau_bo_new(dev, NOUVEAU_BO_GART | NOUVEAU_BO_MAP, 0, 4096, NULL,
-&screen->fence.bo);
+   flags = NOUVEAU_BO_GART | NOUVEAU_BO_MAP;
+   if (dev->drm_version >= 0x01000202)
+  flags |= NOUVEAU_BO_COHERENT;
+
+   ret = nouveau_bo_new(dev, flags, 0, 4096, NULL, &screen->fence.bo);
if (ret)
   goto fail;
nouveau_bo_map(screen->fence.bo, 0, NULL);
-- 
2.4.4

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

[Mesa-dev] [PATCH v4 1/2] nouveau: support for custom VRAM domains

[Alexandre Courbot]

Some GPUs (e.g. GK20A, GM20B) do not embed VRAM of their own and use
the system memory as a backend instead. For such systems, allocating
objects in VRAM results in errors since the kernel will not allow
VRAM objects allocations.

This patch adds a vram_domain member to struct nouveau_screen that can
optionally be initialized to an alternative domain to use for VRAM
allocations. If left untouched, NOUVEAU_BO_VRAM will be used for
systems that embed VRAM, and NOUVEAU_BO_GART will be used for VRAM-less
systems.

Code that uses GPU objects is then expected to use the NV_VRAM_DOMAIN()
macro in place of NOUVEAU_BO_VRAM to ensure correct behavior on
VRAM-less chips.

Signed-off-by: Alexandre Courbot 
Reviewed-by: Ilia Mirkin 
Reviewed-by: Martin Peres 
---
 src/gallium/drivers/nouveau/nouveau_screen.c | 10 ++
 src/gallium/drivers/nouveau/nouveau_screen.h |  4 
 2 files changed, 14 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index b4f1413fd8ba..c6e5074db195 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -164,6 +164,16 @@ nouveau_screen_init(struct nouveau_screen *screen, struct 
nouveau_device *dev)
size = sizeof(nvc0_data);
}
 
+   /*
+* Set default VRAM domain if not overridden
+*/
+   if (!screen->vram_domain) {
+   if (dev->vram_size > 0)
+   screen->vram_domain = NOUVEAU_BO_VRAM;
+   else
+   screen->vram_domain = NOUVEAU_BO_GART;
+   }
+
ret = nouveau_object_new(&dev->object, 0, NOUVEAU_FIFO_CHANNEL_CLASS,
 data, size, &screen->channel);
if (ret)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h 
b/src/gallium/drivers/nouveau/nouveau_screen.h
index cf06f7e88aa0..30041b271c94 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.h
+++ b/src/gallium/drivers/nouveau/nouveau_screen.h
@@ -51,6 +51,8 @@ struct nouveau_screen {
 
boolean hint_buf_keep_sysmem_copy;
 
+   unsigned vram_domain;
+
struct {
unsigned profiles_checked;
unsigned profiles_present;
@@ -94,6 +96,8 @@ struct nouveau_screen {
 #endif
 };
 
+#define NV_VRAM_DOMAIN(screen) ((screen)->vram_domain)
+
 #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
 # define NOUVEAU_DRV_STAT(s, n, v) do { \
   (s)->stats.named.n += (v);   \
-- 
2.4.4

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

[Mesa-dev] [PATCH v4 2/2] nvc0: use NV_VRAM_DOMAIN() macro

[Alexandre Courbot]

Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not have dedicated video memory.

Signed-off-by: Alexandre Courbot 
Reviewed-by: Ilia Mirkin 
Reviewed-by: Martin Peres 
---
 src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 +++---
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17 +++--
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
 11 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 32fa65c8a51c..09cdbb53ecb7 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -658,13 +658,13 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
   switch (buffer->base.usage) {
   case PIPE_USAGE_DEFAULT:
   case PIPE_USAGE_IMMUTABLE:
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
  break;
   case PIPE_USAGE_DYNAMIC:
  /* For most apps, we'd have to do staging transfers to avoid sync
   * with this usage, and GART -> GART copies would be suboptimal.
   */
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
  break;
   case PIPE_USAGE_STAGING:
   case PIPE_USAGE_STREAM:
@@ -676,7 +676,7 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
   }
} else {
   if (buffer->base.bind & screen->vidmem_bindings)
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
   else
   if (buffer->base.bind & screen->sysmem_bindings)
  buffer->domain = NOUVEAU_BO_GART;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c 
b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
index 10cebb17eee3..f15d8f3ecb69 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
@@ -377,7 +377,7 @@ nv50_miptree_create(struct pipe_screen *pscreen,
if (!bo_config.nv50.memtype && (pt->bind & PIPE_BIND_SHARED))
   mt->base.domain = NOUVEAU_BO_GART;
else
-  mt->base.domain = NOUVEAU_BO_VRAM;
+  mt->base.domain = NV_VRAM_DOMAIN(nouveau_screen(pscreen));
 
bo_flags = mt->base.domain | NOUVEAU_BO_NOSNOOP;
if (mt->base.base.bind & (PIPE_BIND_CURSOR | PIPE_BIND_DISPLAY_TARGET))
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
index ad287a2af6b6..56fc83d3679f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
@@ -57,7 +57,7 @@ nvc0_screen_compute_setup(struct nvc0_screen *screen,
   return ret;
}
 
-   ret = nouveau_bo_new(dev, NOUVEAU_BO_VRAM, 0, 1 << 12, NULL,
+   ret = nouveau_bo_new(dev, NV_VRAM_DOMAIN(&screen->base), 0, 1 << 12, NULL,
 &screen->parm);
if (ret)
   return ret;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index 7904984f5037..a35c3f661423 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -329,7 +329,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
 
/* add permanently resident buffers to bufctxts */
 
-   flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RD;
+   flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RD;
 
BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->text);
BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->uniform_bo);
@@ -340,7 +340,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
   BCTX_REFN_bo(nvc0->bufctx_cp, CP_SCREEN, flags, screen->parm);
}
 
-   flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RDWR;
+   flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RDWR;
 
if (screen->poly_cache)
   BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->poly_cache);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index fc75fc6a4a17..3875bbf4ca4d 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -302,7 +302,7 @@ nvc0_miptree_create(

[Mesa-dev] [PATCH v4 0/2] nouveau: support for custom VRAM domains

[Alexandre Courbot]

New (hopefully good to merge) revision of this patchset that prevents
VRAM objects from being allocated on VRAM-less systems like Tegra's
GK20A and GM20B. This is required for Mesa to work on such systems.

Changes since v3:
- Fixed change that would make a comment ambiguous
- Added Reviewed-by tags

Alexandre Courbot (2):
  nouveau: support for custom VRAM domains
  nvc0: use NV_VRAM_DOMAIN() macro

 src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 +++---
 src/gallium/drivers/nouveau/nouveau_screen.c   | 10 ++
 src/gallium/drivers/nouveau/nouveau_screen.h   |  4 
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17 +++--
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
 13 files changed, 41 insertions(+), 22 deletions(-)

-- 
2.4.4

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

Re: [Mesa-dev] [Nouveau] [PATCH v3 0/2] nouveau: support for custom VRAM domains

[Alexandre Courbot]

On Fri, Jun 19, 2015 at 9:38 PM, Ben Skeggs  wrote:
> On 19 June 2015 at 21:51, Martin Peres  wrote:
>> On 19/06/2015 13:02, Alexandre Courbot wrote:
>>>
>>> New revision of this patchset that prevents VRAM objects from being
>>> allocated on VRAM-less systems like Tegra. This is required for Mesa
>>> to work on such systems.
>>>
>>> Changes since v2:
>>> - Use vram_size to detect systems without VRAM and set the correct
>>>domain instead of expecting each chip to set its domain explicitly.
>>
>>
>> This question may have been asked a ton of times, but what is the difference
>> with the nvac (Ion)?
>>
>> Would the nvac have some reserved memory for its usage by the bios which
>> would then be used as "VRAM"?
> PFB on the dGPU IGPs has facilities to fake VRAM from an area of
> "stolen" system memory reserved by the SBIOS.  GK20A/GM20B do not do
> this, and require direct (or, via a mmu, whatever) access to system
> memory.

Exactly. While dGPU do actually carve out a range of system memory to
be exclusively used as "fake" VRAM, Tegra GPUs have access to the
whole system memory which is shared with the other IPs of the SoC,
which requires a different management strategy. Hence the choice to
simply wipe out the concept of VRAM and use everything as system
memory.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/2] nvc0: use NV_VRAM_DOMAIN() macro

[Alexandre Courbot]

On Fri, Jun 19, 2015 at 10:55 PM, Ilia Mirkin  wrote:
> On Fri, Jun 19, 2015 at 6:02 AM, Alexandre Courbot  
> wrote:
>> Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
>> VRAM domains for chips that do not have dedicated video memory.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 ++
>>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  2 +-
>>  src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
>>  src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
>>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
>>  src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
>>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17 
>> +++--
>>  src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
>>  src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
>>  src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
>>  src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
>>  11 files changed, 26 insertions(+), 23 deletions(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
>> b/src/gallium/drivers/nouveau/nouveau_buffer.c
>> index 32fa65c8a51c..bb7676cffbc0 100644
>> --- a/src/gallium/drivers/nouveau/nouveau_buffer.c
>> +++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
>> @@ -658,13 +658,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
>>switch (buffer->base.usage) {
>>case PIPE_USAGE_DEFAULT:
>>case PIPE_USAGE_IMMUTABLE:
>> - buffer->domain = NOUVEAU_BO_VRAM;
>> - break;
>>case PIPE_USAGE_DYNAMIC:
>>   /* For most apps, we'd have to do staging transfers to avoid sync
>>* with this usage, and GART -> GART copies would be suboptimal.
>>*/
>
> This comment only applies to USAGE_DYNAMIC. With the removal of the
> hunk above, that makes it seem like it applies to all 3. Just keep
> both hunks and update both of them.
>
> Other than that this patch seems straightforward enough, with the
> above fixed, the series is
>
> Reviewed-by: Ilia Mirkin 

Will fix that and resend. Thanks for the review!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 2/2] nvc0: use NV_VRAM_DOMAIN() macro

[Alexandre Courbot]

Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not have dedicated video memory.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 ++
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17 +++--
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
 11 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 32fa65c8a51c..bb7676cffbc0 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -658,13 +658,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
   switch (buffer->base.usage) {
   case PIPE_USAGE_DEFAULT:
   case PIPE_USAGE_IMMUTABLE:
- buffer->domain = NOUVEAU_BO_VRAM;
- break;
   case PIPE_USAGE_DYNAMIC:
  /* For most apps, we'd have to do staging transfers to avoid sync
   * with this usage, and GART -> GART copies would be suboptimal.
   */
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
  break;
   case PIPE_USAGE_STAGING:
   case PIPE_USAGE_STREAM:
@@ -676,7 +674,7 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
   }
} else {
   if (buffer->base.bind & screen->vidmem_bindings)
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
   else
   if (buffer->base.bind & screen->sysmem_bindings)
  buffer->domain = NOUVEAU_BO_GART;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c 
b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
index 10cebb17eee3..f15d8f3ecb69 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
@@ -377,7 +377,7 @@ nv50_miptree_create(struct pipe_screen *pscreen,
if (!bo_config.nv50.memtype && (pt->bind & PIPE_BIND_SHARED))
   mt->base.domain = NOUVEAU_BO_GART;
else
-  mt->base.domain = NOUVEAU_BO_VRAM;
+  mt->base.domain = NV_VRAM_DOMAIN(nouveau_screen(pscreen));
 
bo_flags = mt->base.domain | NOUVEAU_BO_NOSNOOP;
if (mt->base.base.bind & (PIPE_BIND_CURSOR | PIPE_BIND_DISPLAY_TARGET))
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
index ad287a2af6b6..56fc83d3679f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
@@ -57,7 +57,7 @@ nvc0_screen_compute_setup(struct nvc0_screen *screen,
   return ret;
}
 
-   ret = nouveau_bo_new(dev, NOUVEAU_BO_VRAM, 0, 1 << 12, NULL,
+   ret = nouveau_bo_new(dev, NV_VRAM_DOMAIN(&screen->base), 0, 1 << 12, NULL,
 &screen->parm);
if (ret)
   return ret;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index 7904984f5037..a35c3f661423 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -329,7 +329,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
 
/* add permanently resident buffers to bufctxts */
 
-   flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RD;
+   flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RD;
 
BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->text);
BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->uniform_bo);
@@ -340,7 +340,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
   BCTX_REFN_bo(nvc0->bufctx_cp, CP_SCREEN, flags, screen->parm);
}
 
-   flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RDWR;
+   flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RDWR;
 
if (screen->poly_cache)
   BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->poly_cache);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
index fc75fc6a4a17..3875bbf4ca4d 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
@@ -302,7 +302,7 @@ nvc0_miptree_create(struct pipe_screen *pscreen,
if (!bo_config.nvc0.memtype && (pt->usage == PIPE_USAGE_STAGING || pt

[Mesa-dev] [PATCH v3 0/2] nouveau: support for custom VRAM domains

[Alexandre Courbot]

New revision of this patchset that prevents VRAM objects from being
allocated on VRAM-less systems like Tegra. This is required for Mesa
to work on such systems.

Changes since v2:
- Use vram_size to detect systems without VRAM and set the correct
  domain instead of expecting each chip to set its domain explicitly.

Alexandre Courbot (2):
  nouveau: support for custom VRAM domains
  nvc0: use NV_VRAM_DOMAIN() macro

 src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 ++
 src/gallium/drivers/nouveau/nouveau_screen.c   | 10 ++
 src/gallium/drivers/nouveau/nouveau_screen.h   |  4 
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 17 +++--
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
 13 files changed, 40 insertions(+), 23 deletions(-)

-- 
2.4.4

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

[Mesa-dev] [PATCH v3 1/2] nouveau: support for custom VRAM domains

[Alexandre Courbot]

Some GPUs (e.g. GK20A, GM20B) do not embed VRAM of their own and use
the system memory as a backend instead. For such systems, allocating
objects in VRAM results in errors since the kernel will not allow
VRAM objects allocations.

This patch adds a vram_domain member to struct nouveau_screen that can
optionally be initialized to an alternative domain to use for VRAM
allocations. If left untouched, NOUVEAU_BO_VRAM will be used for
systems that embed VRAM, and NOUVEAU_BO_GART will be used for VRAM-less
systems.

Code that uses GPU objects is then expected to use the NV_VRAM_DOMAIN()
macro in place of NOUVEAU_BO_VRAM to ensure correct behavior on
VRAM-less chips.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nouveau_screen.c | 10 ++
 src/gallium/drivers/nouveau/nouveau_screen.h |  4 
 2 files changed, 14 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index b4f1413fd8ba..c6e5074db195 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -164,6 +164,16 @@ nouveau_screen_init(struct nouveau_screen *screen, struct 
nouveau_device *dev)
size = sizeof(nvc0_data);
}
 
+   /*
+* Set default VRAM domain if not overridden
+*/
+   if (!screen->vram_domain) {
+   if (dev->vram_size > 0)
+   screen->vram_domain = NOUVEAU_BO_VRAM;
+   else
+   screen->vram_domain = NOUVEAU_BO_GART;
+   }
+
ret = nouveau_object_new(&dev->object, 0, NOUVEAU_FIFO_CHANNEL_CLASS,
 data, size, &screen->channel);
if (ret)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h 
b/src/gallium/drivers/nouveau/nouveau_screen.h
index cf06f7e88aa0..30041b271c94 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.h
+++ b/src/gallium/drivers/nouveau/nouveau_screen.h
@@ -51,6 +51,8 @@ struct nouveau_screen {
 
boolean hint_buf_keep_sysmem_copy;
 
+   unsigned vram_domain;
+
struct {
unsigned profiles_checked;
unsigned profiles_present;
@@ -94,6 +96,8 @@ struct nouveau_screen {
 #endif
 };
 
+#define NV_VRAM_DOMAIN(screen) ((screen)->vram_domain)
+
 #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
 # define NOUVEAU_DRV_STAT(s, n, v) do { \
   (s)->stats.named.n += (v);   \
-- 
2.4.4

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

[Mesa-dev] [PATCH] nvc0: create screen fence objects with coherent attribute

[Alexandre Courbot]

This is required on non-coherent architectures to ensure the value of
the fence is correct at all times. Failure to do this results in the
display freezing for a few seconds every now and then on Tegra.

The NOUVEAU_BO_COHERENT is a no-op for coherent architectures, so behavior
on x86 should not be affected by this patch.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 5936d05a5b93..307cf5f9cd75 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -610,6 +610,7 @@ nvc0_screen_create(struct nouveau_device *dev)
struct nouveau_pushbuf *push;
uint64_t value;
uint32_t obj_class;
+   uint32_t flags;
int ret;
unsigned i;
 
@@ -660,8 +661,11 @@ nvc0_screen_create(struct nouveau_device *dev)
screen->base.base.get_video_param = nouveau_vp3_screen_get_video_param;
screen->base.base.is_video_format_supported = 
nouveau_vp3_screen_video_supported;
 
-   ret = nouveau_bo_new(dev, NOUVEAU_BO_GART | NOUVEAU_BO_MAP, 0, 4096, NULL,
-&screen->fence.bo);
+   flags = NOUVEAU_BO_GART | NOUVEAU_BO_MAP;
+   if (dev->drm_version >= 0x01000202)
+  flags |= NOUVEAU_BO_COHERENT;
+
+   ret = nouveau_bo_new(dev, flags, 0, 4096, NULL, &screen->fence.bo);
if (ret)
   goto fail;
nouveau_bo_map(screen->fence.bo, 0, NULL);
-- 
2.4.4

___
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

[Alexandre Courbot]

On Fri, Nov 28, 2014 at 5:48 PM, Thierry Reding
 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.
___
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

[Alexandre Courbot]

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?

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

Re: [Mesa-dev] Performance regression on Tegra/GK20A since commit 363b53f00069

[Alexandre Courbot]

Hi Pekka,

On 11/20/2014 08:41 PM, Pekka Paalanen wrote:

On Thu, 20 Nov 2014 18:24:34 +0900
Alexandre Courbot  wrote:


Hi Pekka,

On 11/19/2014 04:34 PM, Pekka Paalanen wrote:

On Wed, 19 Nov 2014 15:32:38 +0900
Alexandre Courbot  wrote:


Some more information: CPU usage of the EGL app (glmark2 here) is much
higher when this patch is applied, which I presume is what triggers the
frame skips.

On 11/19/2014 03:05 PM, Alexandre Courbot wrote:

Hi guys,

I am seeing a severe performance regression (lots frame drops when
running EGL apps in Weston) on Tegra/GK20A since the following commit:

commit 363b53f00069af718f64cf047f19ad5681a8bf6d
Author: Marek Olšák 
Date:   Sat Nov 1 14:31:09 2014 +0100

   egl: remove egl_gallium from the loader

Reverting said commit on top of master brings the expected performance
back. I am not knowledgeable enough about Mesa to speculate about the
reason, but could we try to investigate why this happens and how we
could fix this?


Hi,

that sounds like you used to get egl_gallium as the EGL driver, and
after that patch you get egl_dri2. These two have separate Wayland
platform implementations (and probably all other platforms as well?). I
think that might be a lead for investigation. EGL debug environment
variable (EGL_LOG_LEVEL=debug) should confirm which EGL driver gets
loaded. You can force the EGL driver with e.g. EGL_DRIVER=egl_dri2.


You are spot on, EGL_LOG_LEVEL revealed that I was using the egl_gallium
driver while this patch makes Wayland applications use egl_dri2. If I
set EGL_DRIVER=egl_gallium things go back to the expected behavior.



Note, that there are two different EGL platforms in play: DRM/GBM for
Weston, and Wayland for the app. Have you confirmed the problem is in
the app side? That is, does Weston itself run smoothly?


Weston seems to be fine, and since setting EGL_DRIVER=egl_gallium after
starting it brings things back to the previous behavior I believe we can
consider it is not part of this problem.


Agreed.


You say "frame drops", how do you see that? Only on screen, or also in
the app performance profile? How's the average framerate for the app?


Looking at it again this is actually quite interesting. The misbehaving
app is glmark2, and what happens is that despite working nicely
otherwise, a given frame sometimes remain displayed for up to half a
second. Now looking at the framerates reported by glmark2, I noticed
that while they are capped at 60fps when using the gallium driver, the
numbers are much higher when using dri2 (which is nice!). Excepted when
these "stuck frames" happen, then the reported framerate drops
dramatically, indicating that the app itself is also blocked by this.


I have a hunch (wl_buffer.release not delivered in time, and client
side EGL running out of available buffers), but confirming that would
require a Wayland protocol dump up to such hickup. You could try to get
one by setting the enviroment variable WAYLAND_DEBUG=client for
glmark2. It will be a flood, especially if glmark2 succeeds in running
at uncapped framerates. The trace will come to stderr, so you want to
redirect that to file. You need to find out where in the trace the
hickup happened. The timestamps are in milliseconds. I could then take
a look (will need the whole trace).

At this point, I think it would be best to open a bug report against
Mesa, and continue there. Such freezes obviously should not happen on
either EGL driver. Please add me to CC on the bug.


Thanks, I have opened a bug against Mesa and added you to the CC list:

https://bugs.freedesktop.org/show_bug.cgi?id=86690

I will try to attach the WAYLAND_DEBUG trace you suggested to it.

Cheers,
Alex.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Performance regression on Tegra/GK20A since commit 363b53f00069

[Alexandre Courbot]

Hi Pekka,

On 11/19/2014 04:34 PM, Pekka Paalanen wrote:

On Wed, 19 Nov 2014 15:32:38 +0900
Alexandre Courbot  wrote:


Some more information: CPU usage of the EGL app (glmark2 here) is much
higher when this patch is applied, which I presume is what triggers the
frame skips.

On 11/19/2014 03:05 PM, Alexandre Courbot wrote:

Hi guys,

I am seeing a severe performance regression (lots frame drops when
running EGL apps in Weston) on Tegra/GK20A since the following commit:

commit 363b53f00069af718f64cf047f19ad5681a8bf6d
Author: Marek Olšák 
Date:   Sat Nov 1 14:31:09 2014 +0100

  egl: remove egl_gallium from the loader

Reverting said commit on top of master brings the expected performance
back. I am not knowledgeable enough about Mesa to speculate about the
reason, but could we try to investigate why this happens and how we
could fix this?


Hi,

that sounds like you used to get egl_gallium as the EGL driver, and
after that patch you get egl_dri2. These two have separate Wayland
platform implementations (and probably all other platforms as well?). I
think that might be a lead for investigation. EGL debug environment
variable (EGL_LOG_LEVEL=debug) should confirm which EGL driver gets
loaded. You can force the EGL driver with e.g. EGL_DRIVER=egl_dri2.


You are spot on, EGL_LOG_LEVEL revealed that I was using the egl_gallium 
driver while this patch makes Wayland applications use egl_dri2. If I 
set EGL_DRIVER=egl_gallium things go back to the expected behavior.




Note, that there are two different EGL platforms in play: DRM/GBM for
Weston, and Wayland for the app. Have you confirmed the problem is in
the app side? That is, does Weston itself run smoothly?


Weston seems to be fine, and since setting EGL_DRIVER=egl_gallium after 
starting it brings things back to the previous behavior I believe we can 
consider it is not part of this problem.




FYI, I've been slowly working on https://github.com/ppaalanen/wesgr but
the Weston patches are not upstream yet, and I'm in the process of
updating them currently. I hope this tool might give some indication
whether the skips/stalls happen in Weston or not.

You say "frame drops", how do you see that? Only on screen, or also in
the app performance profile? How's the average framerate for the app?


Looking at it again this is actually quite interesting. The misbehaving 
app is glmark2, and what happens is that despite working nicely 
otherwise, a given frame sometimes remain displayed for up to half a 
second. Now looking at the framerates reported by glmark2, I noticed 
that while they are capped at 60fps when using the gallium driver, the 
numbers are much higher when using dri2 (which is nice!). Excepted when 
these "stuck frames" happen, then the reported framerate drops 
dramatically, indicating that the app itself is also blocked by this.


Interestingly, if I run weston-simple-egl with dri2, the framerate is 
again capped at 60fps, so this may be something specific to glmark2.


Also, and I cannot explain why, but if there is other activity happening 
in Weston (e.g. another egl application, even another instance of 
glmark2 itself), the issue seems to not manifest itself.


Just for my education, is the egl_gallium driver going to be removed? 
What are egl_gallium and egl_dri2 doing differently?


Thanks,
Alex.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Performance regression on Tegra/GK20A since commit 363b53f00069

[Alexandre Courbot]

Some more information: CPU usage of the EGL app (glmark2 here) is much 
higher when this patch is applied, which I presume is what triggers the 
frame skips.


On 11/19/2014 03:05 PM, Alexandre Courbot wrote:

Hi guys,

I am seeing a severe performance regression (lots frame drops when
running EGL apps in Weston) on Tegra/GK20A since the following commit:

commit 363b53f00069af718f64cf047f19ad5681a8bf6d
Author: Marek Olšák 
Date:   Sat Nov 1 14:31:09 2014 +0100

 egl: remove egl_gallium from the loader

Reverting said commit on top of master brings the expected performance
back. I am not knowledgeable enough about Mesa to speculate about the
reason, but could we try to investigate why this happens and how we
could fix this?

Thanks,
Alex.


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

[Mesa-dev] Performance regression on Tegra/GK20A since commit 363b53f00069

[Alexandre Courbot]

Hi guys,

I am seeing a severe performance regression (lots frame drops when 
running EGL apps in Weston) on Tegra/GK20A since the following commit:


commit 363b53f00069af718f64cf047f19ad5681a8bf6d
Author: Marek Olšák 
Date:   Sat Nov 1 14:31:09 2014 +0100

egl: remove egl_gallium from the loader

Reverting said commit on top of master brings the expected performance 
back. I am not knowledgeable enough about Mesa to speculate about the 
reason, but could we try to investigate why this happens and how we 
could fix this?


Thanks,
Alex.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] nvc0: use NV_VRAM_DOMAIN() macro

[Alexandre Courbot]

On 11/19/2014 02:49 PM, Ilia Mirkin wrote:

On Wed, Nov 19, 2014 at 12:41 AM, Alexandre Courbot  wrote:

Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not use dedicated video memory.

Signed-off-by: Alexandre Courbot 
---
  src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 ++
  src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  4 ++--
  src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 12 ++--
  src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
  src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
  src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
  11 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 49ff100c4ece..4c21691ee671 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -658,13 +658,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
switch (buffer->base.usage) {
case PIPE_USAGE_DEFAULT:
case PIPE_USAGE_IMMUTABLE:
- buffer->domain = NOUVEAU_BO_VRAM;
- break;
case PIPE_USAGE_DYNAMIC:
   /* For most apps, we'd have to do staging transfers to avoid sync
* with this usage, and GART -> GART copies would be suboptimal.
*/
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
   break;
case PIPE_USAGE_STAGING:
case PIPE_USAGE_STREAM:
@@ -676,7 +674,7 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
}
 } else {
if (buffer->base.bind & screen->vidmem_bindings)
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
else
if (buffer->base.bind & screen->sysmem_bindings)
   buffer->domain = NOUVEAU_BO_GART;


Both of these changes should be unnecessary if vidmem_bindings is
cleared out, right?


For our particular case (vram_domain == NOUVEAU_BO_GART), that's 
correct. However NV_VRAM_DOMAIN could be a any combination of 
NOUVEAU_BO_*, so we can imagine a future scenario where 
(buffer->base.bind & screen->vidmem_bindings) == 1 but NV_VRAM_DOMAIN() 
will return something different from NOUVEAU_BO_VRAM. For this reason it 
seems consistent to use this macro here as well.

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

[Mesa-dev] [PATCH v2 0/3] nouveau: support for custom VRAM domains

[Alexandre Courbot]

This series is to allow NVIDIA chips with shared memory to operate more
efficiently (and to operate at all once we disable VRAM from the kernel
driver) by allowing nouveau_screen to specify a domain to use for objects
originally allocated into VRAM. If the domain is not overridden, the default
NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be
used in place of NOUVEAU_BO_VRAM when allocating objects, so the right
domain for the chip is used.

Doing so greatly simplifies the equation of memory management on shared-
memory devices, since we don't have to simulate non-existent VRAM memory.
In that respect it seems to be the right thing to do, and all things taken
is not very intrusive.

Tested on GK20A with Wayland and several EGL clients running, and working
fine.

Changes since v1:
- When using GART as the VRAM domain, move all vidmem bindings to sysmem and
  set vidmem_bindings to 0.

Alexandre Courbot (3):
  nouveau: support for custom VRAM domains
  nvc0: use NV_VRAM_DOMAIN() macro
  gk20a: use NOUVEAU_BO_GART as VRAM domain

 src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 ++---
 src/gallium/drivers/nouveau/nouveau_screen.c   |  6 +
 src/gallium/drivers/nouveau/nouveau_screen.h   |  4 
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 +++
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 27 +-
 .../drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
 .../drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
 13 files changed, 47 insertions(+), 24 deletions(-)

-- 
2.1.3

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

[Mesa-dev] [PATCH v2 1/3] nouveau: support for custom VRAM domains

[Alexandre Courbot]

Some NVIDIA chips (e.g. GK20A) do not embed VRAM of their own and have
complete shared access to system memory. For these systems, allocating
objects in VRAM might lead to unneeded copies and sub-optimal memory
management. It will also lead to errors if the kernel does not allow
VRAM objects allocations.

This patch adds a vram_domain member to struct nouveau_screen that can
optionally be initialized to an alternative domain to use for VRAM
allocations (most likely, NOUVEAU_BO_GART to allocate everything in
system memory). If not initialized, the default NOUVEAU_BO_VRAM domain
is used.

Code that allocates GPU objects is then expected to use the
NV_VRAM_DOMAIN() macro in place of NOUVEAU_BO_VRAM to ensure correct
behavior on VRAM-less chips.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nouveau_screen.c | 6 ++
 src/gallium/drivers/nouveau/nouveau_screen.h | 4 
 2 files changed, 10 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index 517978d88588..e4598c3fd24f 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -158,6 +158,12 @@ nouveau_screen_init(struct nouveau_screen *screen, struct 
nouveau_device *dev)
size = sizeof(nvc0_data);
}
 
+   /*
+* Set default VRAM domain if not overridden
+*/
+   if (!screen->vram_domain)
+   screen->vram_domain = NOUVEAU_BO_VRAM;
+
ret = nouveau_object_new(&dev->object, 0, NOUVEAU_FIFO_CHANNEL_CLASS,
 data, size, &screen->channel);
if (ret)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h 
b/src/gallium/drivers/nouveau/nouveau_screen.h
index cf06f7e88aa0..30041b271c94 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.h
+++ b/src/gallium/drivers/nouveau/nouveau_screen.h
@@ -51,6 +51,8 @@ struct nouveau_screen {
 
boolean hint_buf_keep_sysmem_copy;
 
+   unsigned vram_domain;
+
struct {
unsigned profiles_checked;
unsigned profiles_present;
@@ -94,6 +96,8 @@ struct nouveau_screen {
 #endif
 };
 
+#define NV_VRAM_DOMAIN(screen) ((screen)->vram_domain)
+
 #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
 # define NOUVEAU_DRV_STAT(s, n, v) do { \
   (s)->stats.named.n += (v);   \
-- 
2.1.3

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

[Mesa-dev] [PATCH v2 2/3] nvc0: use NV_VRAM_DOMAIN() macro

[Alexandre Courbot]

Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not use dedicated video memory.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 ++
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 12 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
 11 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 49ff100c4ece..4c21691ee671 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -658,13 +658,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
   switch (buffer->base.usage) {
   case PIPE_USAGE_DEFAULT:
   case PIPE_USAGE_IMMUTABLE:
- buffer->domain = NOUVEAU_BO_VRAM;
- break;
   case PIPE_USAGE_DYNAMIC:
  /* For most apps, we'd have to do staging transfers to avoid sync
   * with this usage, and GART -> GART copies would be suboptimal.
   */
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
  break;
   case PIPE_USAGE_STAGING:
   case PIPE_USAGE_STREAM:
@@ -676,7 +674,7 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
   }
} else {
   if (buffer->base.bind & screen->vidmem_bindings)
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
   else
   if (buffer->base.bind & screen->sysmem_bindings)
  buffer->domain = NOUVEAU_BO_GART;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c 
b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
index 1aacaec89acf..ddff508c475c 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
@@ -359,7 +359,7 @@ nv50_miptree_create(struct pipe_screen *pscreen,
if (!bo_config.nv50.memtype && (pt->bind & PIPE_BIND_SHARED))
   mt->base.domain = NOUVEAU_BO_GART;
else
-  mt->base.domain = NOUVEAU_BO_VRAM;
+  mt->base.domain = NV_VRAM_DOMAIN(nouveau_screen(pscreen));
 
bo_flags = mt->base.domain | NOUVEAU_BO_NOSNOOP;
if (mt->base.base.bind & (PIPE_BIND_CURSOR | PIPE_BIND_DISPLAY_TARGET))
@@ -401,7 +401,7 @@ nv50_miptree_from_handle(struct pipe_screen *pscreen,
   FREE(mt);
   return NULL;
}
-   mt->base.domain = NOUVEAU_BO_VRAM;
+   mt->base.domain = NV_VRAM_DOMAIN(nouveau_screen(pscreen));
mt->base.address = mt->base.bo->offset;
 
mt->base.base = *templ;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
index ad287a2af6b6..56fc83d3679f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
@@ -57,7 +57,7 @@ nvc0_screen_compute_setup(struct nvc0_screen *screen,
   return ret;
}
 
-   ret = nouveau_bo_new(dev, NOUVEAU_BO_VRAM, 0, 1 << 12, NULL,
+   ret = nouveau_bo_new(dev, NV_VRAM_DOMAIN(&screen->base), 0, 1 << 12, NULL,
 &screen->parm);
if (ret)
   return ret;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index b33a6731a1c0..a0189f528e6f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -322,7 +322,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
 
/* add permanently resident buffers to bufctxts */
 
-   flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RD;
+   flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RD;
 
BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->text);
BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->uniform_bo);
@@ -333,7 +333,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
   BCTX_REFN_bo(nvc0->bufctx_cp, CP_SCREEN, flags, screen->parm);
}
 
-   flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RDWR;
+   flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RDWR;
 
if (screen->poly_cache)
   BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->poly_cache);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptre

[Mesa-dev] [PATCH v2 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain

[Alexandre Courbot]

GK20A does not have dedicated VRAM, therefore allocating in VRAM can be
sub-optimal and sometimes even harmful. Set its VRAM domain to
NOUVEAU_BO_GART so all objects are allocated in system memory.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 506165d179de..b3f462ade11c 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -617,6 +617,16 @@ nvc0_screen_create(struct nouveau_device *dev)
   return NULL;
pscreen = &screen->base.base;
 
+   /* Recognize chipsets with no VRAM */
+   switch (dev->chipset) {
+   /* GK20A */
+   case 0xea:
+  screen->base.vram_domain = NOUVEAU_BO_GART;
+  break;
+   default:
+  break;
+   }
+
ret = nouveau_screen_init(&screen->base, dev);
if (ret) {
   nvc0_screen_destroy(pscreen);
@@ -633,6 +643,11 @@ nvc0_screen_create(struct nouveau_device *dev)
screen->base.sysmem_bindings |=
   PIPE_BIND_VERTEX_BUFFER | PIPE_BIND_INDEX_BUFFER;
 
+   if (screen->base.vram_domain & NOUVEAU_BO_GART) {
+  screen->base.sysmem_bindings |= screen->base.vidmem_bindings;
+  screen->base.vidmem_bindings = 0;
+   }
+
pscreen->destroy = nvc0_screen_destroy;
pscreen->context_create = nvc0_create;
pscreen->is_format_supported = nvc0_screen_is_format_supported;
-- 
2.1.3

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

Re: [Mesa-dev] [PATCH 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain

[Alexandre Courbot]

On 10/30/2014 12:29 AM, Ilia Mirkin wrote:

On Mon, Oct 27, 2014 at 6:34 AM, Alexandre Courbot  wrote:

GK20A does not have dedicated VRAM, therefore allocating in VRAM can be
sub-optimal and sometimes even harmful. Set its VRAM domain to
NOUVEAU_BO_GART so all objects are allocated in system memory.

Signed-off-by: Alexandre Courbot 
---
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index ac5823e4a8d5..ad143cd9a140 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -620,6 +620,16 @@ nvc0_screen_create(struct nouveau_device *dev)
return NULL;
 pscreen = &screen->base.base;

+   /* Recognize chipsets with no VRAM */
+   switch (dev->chipset) {
+   /* GK20A */
+   case 0xea:
+  screen->base.vram_domain = NOUVEAU_BO_GART;


I think you also want to set vidmem_bindings = 0... although
potentially after the |= that's done below. Although I guess that
constbuf + command args buf need to be |='d into the sysmem_bindings
for this to work out well. That said, we don't really handle explicit
migration well right now, and those PIPE_BIND_* are *incredibly*
misleading and don't actually necessarily reflect the current usage.
[I have some patches to improve the situation, but you don't really
have to worry about that.]


In the light of that it could be that the vram_domain member I am 
introducing is completely useless - if we set NV_VRAM_DOMAIN to be the 
following:


#define NV_VRAM_DOMAIN(screen) ((screen)->vidmem_bindings == 0 ? 
NOUVEAU_BO_GART : NOUVEAU_BO_VRAM)


then I suspect we can just live without it. I tested quickly and it 
seems to work. Ilia, do you agree? Or could we imagine having GPUs with 
VRAM for which none of the PIPE_BIND_* targets should reside in VRAM?


Also thinking, prior to setting vidmem_bindings to 0, shouldn't we also 
do a "sysmem_bindings |= vidmem_bindings" to make sure all the set 
bindings are tracked somewhere?

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

Re: [Mesa-dev] [PATCH] nvc0: remove unused nvc0_screen::mm_VRAM_fe0

[Alexandre Courbot]

Ping, how about this guy?

On Mon, Oct 27, 2014 at 7:36 PM, Alexandre Courbot  wrote:
> This member is declared, allocated and destroyed, but doesn't seem to be
> used or referenced anywhere in the code.
>
> Signed-off-by: Alexandre Courbot 
> ---
> Resending after fixing typo in email address - apologies for the 
> inconvenience.
>
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ---
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 2 --
>  2 files changed, 5 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> index a7581f286cfc..61b381693224 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
> @@ -407,8 +407,6 @@ nvc0_screen_destroy(struct pipe_screen *pscreen)
>
> FREE(screen->tic.entries);
>
> -   nouveau_mm_destroy(screen->mm_VRAM_fe0);
> -
> nouveau_object_del(&screen->eng3d);
> nouveau_object_del(&screen->eng2d);
> nouveau_object_del(&screen->m2mf);
> @@ -1027,7 +1025,6 @@ nvc0_screen_create(struct nouveau_device *dev)
>
> mm_config.nvc0.tile_mode = 0;
> mm_config.nvc0.memtype = 0xfe0;
> -   screen->mm_VRAM_fe0 = nouveau_mm_create(dev, NOUVEAU_BO_VRAM, &mm_config);
>
> if (!nvc0_blitter_create(screen))
>goto fail;
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
> index 4802057f70ee..8a1991f52eb4 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
> @@ -73,8 +73,6 @@ struct nvc0_screen {
>boolean mp_counters_enabled;
> } pm;
>
> -   struct nouveau_mman *mm_VRAM_fe0;
> -
> struct nouveau_object *eng3d; /* sqrt(1/2)|kepler> + sqrt(1/2)|fermi> */
> struct nouveau_object *eng2d;
> struct nouveau_object *m2mf;
> --
> 2.1.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nvc0: remove unused nvc0_screen::mm_VRAM_fe0

[Alexandre Courbot]

On 11/12/2014 03:07 PM, Ilia Mirkin wrote:

LG. I had this same patch locally I think... I came up with it after I
went looking at the various VRAM usage after you were asking questions
about it.


Good, I'm dropping this version then, and assume yours will get merged soon.

Thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain

[Alexandre Courbot]

On 10/30/2014 12:29 AM, Ilia Mirkin wrote:

On Mon, Oct 27, 2014 at 6:34 AM, Alexandre Courbot  wrote:

GK20A does not have dedicated VRAM, therefore allocating in VRAM can be
sub-optimal and sometimes even harmful. Set its VRAM domain to
NOUVEAU_BO_GART so all objects are allocated in system memory.

Signed-off-by: Alexandre Courbot 
---
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index ac5823e4a8d5..ad143cd9a140 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -620,6 +620,16 @@ nvc0_screen_create(struct nouveau_device *dev)
return NULL;
 pscreen = &screen->base.base;

+   /* Recognize chipsets with no VRAM */
+   switch (dev->chipset) {
+   /* GK20A */
+   case 0xea:
+  screen->base.vram_domain = NOUVEAU_BO_GART;


I think you also want to set vidmem_bindings = 0... although
potentially after the |= that's done below. Although I guess that
constbuf + command args buf need to be |='d into the sysmem_bindings
for this to work out well.


Thanks for pointing this out ; I didn't know about vidmem_bindings to be 
honest. Will update and resend.


Apart from this detail, are you ok with the changes brought by these 
patches?


Cheers,
Alex.

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

[Mesa-dev] [PATCH] nvc0: remove unused nvc0_screen::mm_VRAM_fe0

[Alexandre Courbot]

This member is declared, allocated and destroyed, but doesn't seem to be
used or referenced anywhere in the code.

Signed-off-by: Alexandre Courbot 
---
Resending after fixing typo in email address - apologies for the inconvenience.

 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 2 --
 2 files changed, 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index a7581f286cfc..61b381693224 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -407,8 +407,6 @@ nvc0_screen_destroy(struct pipe_screen *pscreen)
 
FREE(screen->tic.entries);
 
-   nouveau_mm_destroy(screen->mm_VRAM_fe0);
-
nouveau_object_del(&screen->eng3d);
nouveau_object_del(&screen->eng2d);
nouveau_object_del(&screen->m2mf);
@@ -1027,7 +1025,6 @@ nvc0_screen_create(struct nouveau_device *dev)
 
mm_config.nvc0.tile_mode = 0;
mm_config.nvc0.memtype = 0xfe0;
-   screen->mm_VRAM_fe0 = nouveau_mm_create(dev, NOUVEAU_BO_VRAM, &mm_config);
 
if (!nvc0_blitter_create(screen))
   goto fail;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
index 4802057f70ee..8a1991f52eb4 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
@@ -73,8 +73,6 @@ struct nvc0_screen {
   boolean mp_counters_enabled;
} pm;
 
-   struct nouveau_mman *mm_VRAM_fe0;
-
struct nouveau_object *eng3d; /* sqrt(1/2)|kepler> + sqrt(1/2)|fermi> */
struct nouveau_object *eng2d;
struct nouveau_object *m2mf;
-- 
2.1.2

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

[Mesa-dev] [PATCH 0/3] nouveau: support for custom VRAM domains

[Alexandre Courbot]

This series is to allow NVIDIA chips with shared memory to operate more
efficiently (and to operate at all once we disable VRAM from the kernel
driver) by allowing nouveau_screen to specify a domain to use for objects
originally allocated into VRAM. If the domain is not overridden, the default
NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be
used in place of NOUVEAU_BO_VRAM when allocating objects, so the right
domain for the chip is used.

Doing so greatly simplifies the equation of memory management on shared-
memory devices, since we don't have to simulate non-existent VRAM memory.
In that respect it seems to be the right thing to do, and all things taken
is not very intrusive.

Tested on GK20A with Wayland and several EGL clients running, and working
fine.

Alexandre Courbot (3):
  nouveau: support for custom VRAM domains
  nvc0: use NV_VRAM_DOMAIN() macro
  gk20a: use NOUVEAU_BO_GART as VRAM domain

 src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 ++
 src/gallium/drivers/nouveau/nouveau_screen.c   |  6 ++
 src/gallium/drivers/nouveau/nouveau_screen.h   |  4 
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 22 --
 .../drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
 .../drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
 13 files changed, 42 insertions(+), 24 deletions(-)

-- 
2.1.2

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

[Mesa-dev] [PATCH 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain

[Alexandre Courbot]

GK20A does not have dedicated VRAM, therefore allocating in VRAM can be
sub-optimal and sometimes even harmful. Set its VRAM domain to
NOUVEAU_BO_GART so all objects are allocated in system memory.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index ac5823e4a8d5..ad143cd9a140 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -620,6 +620,16 @@ nvc0_screen_create(struct nouveau_device *dev)
   return NULL;
pscreen = &screen->base.base;
 
+   /* Recognize chipsets with no VRAM */
+   switch (dev->chipset) {
+   /* GK20A */
+   case 0xea:
+  screen->base.vram_domain = NOUVEAU_BO_GART;
+  break;
+   default:
+  break;
+   }
+
ret = nouveau_screen_init(&screen->base, dev);
if (ret) {
   nvc0_screen_destroy(pscreen);
-- 
2.1.2

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

[Mesa-dev] [PATCH 1/3] nouveau: support for custom VRAM domains

[Alexandre Courbot]

Some NVIDIA chips (e.g. GK20A) do not embed VRAM of their own and have
complete shared access to system memory. For these systems, allocating
objects in VRAM might lead to unneeded copies and sub-optimal memory
management. It will also lead to errors if the kernel does not allow
VRAM objects allocations.

This patch adds a vram_domain member to struct nouveau_screen that can
optionally be initialized to an alternative domain to use for VRAM
allocations (most likely, NOUVEAU_BO_GART to allocate everything in
system memory). If not initialized, the default NOUVEAU_BO_VRAM domain
is used.

Code that allocates GPU objects is then expected to use the
NV_VRAM_DOMAIN() macro in place of NOUVEAU_BO_VRAM to ensure correct
behavior on VRAM-less chips.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nouveau_screen.c | 6 ++
 src/gallium/drivers/nouveau/nouveau_screen.h | 4 
 2 files changed, 10 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c 
b/src/gallium/drivers/nouveau/nouveau_screen.c
index 517978d88588..e4598c3fd24f 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -158,6 +158,12 @@ nouveau_screen_init(struct nouveau_screen *screen, struct 
nouveau_device *dev)
size = sizeof(nvc0_data);
}
 
+   /*
+* Set default VRAM domain if not overridden
+*/
+   if (!screen->vram_domain)
+   screen->vram_domain = NOUVEAU_BO_VRAM;
+
ret = nouveau_object_new(&dev->object, 0, NOUVEAU_FIFO_CHANNEL_CLASS,
 data, size, &screen->channel);
if (ret)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.h 
b/src/gallium/drivers/nouveau/nouveau_screen.h
index cf06f7e88aa0..30041b271c94 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.h
+++ b/src/gallium/drivers/nouveau/nouveau_screen.h
@@ -51,6 +51,8 @@ struct nouveau_screen {
 
boolean hint_buf_keep_sysmem_copy;
 
+   unsigned vram_domain;
+
struct {
unsigned profiles_checked;
unsigned profiles_present;
@@ -94,6 +96,8 @@ struct nouveau_screen {
 #endif
 };
 
+#define NV_VRAM_DOMAIN(screen) ((screen)->vram_domain)
+
 #ifdef NOUVEAU_ENABLE_DRIVER_STATISTICS
 # define NOUVEAU_DRV_STAT(s, n, v) do { \
   (s)->stats.named.n += (v);   \
-- 
2.1.2

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

[Mesa-dev] [PATCH 2/3] nvc0: use NV_VRAM_DOMAIN() macro

[Alexandre Courbot]

Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not use dedicated video memory.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nouveau_buffer.c   |  6 ++
 src/gallium/drivers/nouveau/nv50/nv50_miptree.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c|  4 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c|  8 
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 12 ++--
 src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c   |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c |  2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_tex.c|  2 +-
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c|  2 +-
 11 files changed, 22 insertions(+), 24 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c 
b/src/gallium/drivers/nouveau/nouveau_buffer.c
index 49ff100c4ece..4c21691ee671 100644
--- a/src/gallium/drivers/nouveau/nouveau_buffer.c
+++ b/src/gallium/drivers/nouveau/nouveau_buffer.c
@@ -658,13 +658,11 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
   switch (buffer->base.usage) {
   case PIPE_USAGE_DEFAULT:
   case PIPE_USAGE_IMMUTABLE:
- buffer->domain = NOUVEAU_BO_VRAM;
- break;
   case PIPE_USAGE_DYNAMIC:
  /* For most apps, we'd have to do staging transfers to avoid sync
   * with this usage, and GART -> GART copies would be suboptimal.
   */
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
  break;
   case PIPE_USAGE_STAGING:
   case PIPE_USAGE_STREAM:
@@ -676,7 +674,7 @@ nouveau_buffer_create(struct pipe_screen *pscreen,
   }
} else {
   if (buffer->base.bind & screen->vidmem_bindings)
- buffer->domain = NOUVEAU_BO_VRAM;
+ buffer->domain = NV_VRAM_DOMAIN(screen);
   else
   if (buffer->base.bind & screen->sysmem_bindings)
  buffer->domain = NOUVEAU_BO_GART;
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c 
b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
index 1aacaec89acf..ddff508c475c 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
@@ -359,7 +359,7 @@ nv50_miptree_create(struct pipe_screen *pscreen,
if (!bo_config.nv50.memtype && (pt->bind & PIPE_BIND_SHARED))
   mt->base.domain = NOUVEAU_BO_GART;
else
-  mt->base.domain = NOUVEAU_BO_VRAM;
+  mt->base.domain = NV_VRAM_DOMAIN(nouveau_screen(pscreen));
 
bo_flags = mt->base.domain | NOUVEAU_BO_NOSNOOP;
if (mt->base.base.bind & (PIPE_BIND_CURSOR | PIPE_BIND_DISPLAY_TARGET))
@@ -401,7 +401,7 @@ nv50_miptree_from_handle(struct pipe_screen *pscreen,
   FREE(mt);
   return NULL;
}
-   mt->base.domain = NOUVEAU_BO_VRAM;
+   mt->base.domain = NV_VRAM_DOMAIN(nouveau_screen(pscreen));
mt->base.address = mt->base.bo->offset;
 
mt->base.base = *templ;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
index ad287a2af6b6..56fc83d3679f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
@@ -57,7 +57,7 @@ nvc0_screen_compute_setup(struct nvc0_screen *screen,
   return ret;
}
 
-   ret = nouveau_bo_new(dev, NOUVEAU_BO_VRAM, 0, 1 << 12, NULL,
+   ret = nouveau_bo_new(dev, NV_VRAM_DOMAIN(&screen->base), 0, 1 << 12, NULL,
 &screen->parm);
if (ret)
   return ret;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index b33a6731a1c0..a0189f528e6f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -322,7 +322,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
 
/* add permanently resident buffers to bufctxts */
 
-   flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RD;
+   flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RD;
 
BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->text);
BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->uniform_bo);
@@ -333,7 +333,7 @@ nvc0_create(struct pipe_screen *pscreen, void *priv)
   BCTX_REFN_bo(nvc0->bufctx_cp, CP_SCREEN, flags, screen->parm);
}
 
-   flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_RDWR;
+   flags = NV_VRAM_DOMAIN(&screen->base) | NOUVEAU_BO_RDWR;
 
if (screen->poly_cache)
   BCTX_REFN_bo(nvc0->bufctx_3d, SCREEN, flags, screen->poly_cache);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_miptre

[Mesa-dev] [PATCH] nvc0: remove unused nvc0_screen::mm_VRAM_fe0

[Alexandre Courbot]

This member is declared, allocated and destroyed, but doesn't seem to be
used or referenced anywhere in the code.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 2 --
 2 files changed, 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index a7581f286cfc..61b381693224 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -407,8 +407,6 @@ nvc0_screen_destroy(struct pipe_screen *pscreen)
 
FREE(screen->tic.entries);
 
-   nouveau_mm_destroy(screen->mm_VRAM_fe0);
-
nouveau_object_del(&screen->eng3d);
nouveau_object_del(&screen->eng2d);
nouveau_object_del(&screen->m2mf);
@@ -1027,7 +1025,6 @@ nvc0_screen_create(struct nouveau_device *dev)
 
mm_config.nvc0.tile_mode = 0;
mm_config.nvc0.memtype = 0xfe0;
-   screen->mm_VRAM_fe0 = nouveau_mm_create(dev, NOUVEAU_BO_VRAM, &mm_config);
 
if (!nvc0_blitter_create(screen))
   goto fail;
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
index 4802057f70ee..8a1991f52eb4 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.h
@@ -73,8 +73,6 @@ struct nvc0_screen {
   boolean mp_counters_enabled;
} pm;
 
-   struct nouveau_mman *mm_VRAM_fe0;
-
struct nouveau_object *eng3d; /* sqrt(1/2)|kepler> + sqrt(1/2)|fermi> */
struct nouveau_object *eng2d;
struct nouveau_object *m2mf;
-- 
2.1.2

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

[Mesa-dev] [PATCH v2 0/2] nvc0: support for GK20A (Tegra K1)

[Alexandre Courbot]

The following 2 patches make it possible to run Mesa programs on GK20A
(Tegra K1).

GK20A is very similar to GK104, but uses a new (backward-compatible) 3D class
as well as the same ISA as GK110 (SM35). Taking these differences into account
is sufficient to successfully render simple off-screen buffers.

Changes since v1:
- Update TargetNVC0::getFileSize() to return the right number of GPR
- Remove definition for unneeded NVISA_GK110_CHIPSET
- Use consistent comparison scheme in nv50_ir_emit_nvc0.cpp

Alexandre Courbot (2):
  nvc0: add GK20A 3D class
  nvc0: use SM35 ISA with GK20A

 src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h  |  2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp |  2 +-
 .../drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp   | 15 ++-
 src/gallium/drivers/nouveau/nv_object.xml.h   |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c|  9 -
 5 files changed, 21 insertions(+), 8 deletions(-)

-- 
1.9.3

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

[Mesa-dev] [PATCH v2 1/2] nvc0: add GK20A 3D class

[Alexandre Courbot]

GK20A is mostly compatible with GK104, but features a new 3D
class. Add it to the relevant header and use it when GK20A is
detected.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nv_object.xml.h| 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 9 -
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv_object.xml.h 
b/src/gallium/drivers/nouveau/nv_object.xml.h
index 4c93e6564838..0a0e187dc028 100644
--- a/src/gallium/drivers/nouveau/nv_object.xml.h
+++ b/src/gallium/drivers/nouveau/nv_object.xml.h
@@ -190,6 +190,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #define NVC8_3D_CLASS  0x9297
 #define NVE4_3D_CLASS  0xa097
 #define NVF0_3D_CLASS  0xa197
+#define NVEA_3D_CLASS  0xa297
 #define GM107_3D_CLASS 0xb097
 #define NV50_2D_CLASS  0x502d
 #define NVC0_2D_CLASS  0x902d
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index cccfe2bba23d..95e5ef81cd79 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -702,7 +702,14 @@ nvc0_screen_create(struct nouveau_device *dev)
   obj_class = NVF0_3D_CLASS;
   break;
case 0xe0:
-  obj_class = NVE4_3D_CLASS;
+  switch (dev->chipset) {
+  case 0xea:
+ obj_class = NVEA_3D_CLASS;
+ break;
+  default:
+ obj_class = NVE4_3D_CLASS;
+ break;
+  }
   break;
case 0xd0:
   obj_class = NVC8_3D_CLASS;
-- 
1.9.3

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

[Mesa-dev] [PATCH v2 2/2] nvc0: use SM35 ISA with GK20A

[Alexandre Courbot]

GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use
the GK110 path when this chip is detected.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h  |  2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp |  2 +-
 .../drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp   | 15 ++-
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
index bbb89d97932e..f829aac0bcc2 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
@@ -91,7 +91,7 @@ struct nv50_ir_prog_symbol
 #define NVISA_GF100_CHIPSET_C0 0xc0
 #define NVISA_GF100_CHIPSET_D0 0xd0
 #define NVISA_GK104_CHIPSET0xe0
-#define NVISA_GK110_CHIPSET0xf0
+#define NVISA_GK20A_CHIPSET0xea
 #define NVISA_GM107_CHIPSET0x110
 
 struct nv50_ir_prog_info
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index b1f76cf80432..f69e6a183e19 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -3027,7 +3027,7 @@ TargetNVC0::createCodeEmitterNVC0(Program::Type type)
 CodeEmitter *
 TargetNVC0::getCodeEmitter(Program::Type type)
 {
-   if (chipset >= NVISA_GK110_CHIPSET)
+   if (chipset >= NVISA_GK20A_CHIPSET)
   return createCodeEmitterGK110(type);
return createCodeEmitterNVC0(type);
 }
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
index 064e7a2c63f9..963b6e47ddfc 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
@@ -49,9 +49,12 @@ TargetNVC0::getBuiltinCode(const uint32_t **code, uint32_t 
*size) const
 {
switch (chipset & ~0xf) {
case 0xe0:
-  *code = (const uint32_t *)&gk104_builtin_code[0];
-  *size = sizeof(gk104_builtin_code);
-  break;
+  if (chipset < NVISA_GK20A_CHIPSET) {
+ *code = (const uint32_t *)&gk104_builtin_code[0];
+ *size = sizeof(gk104_builtin_code);
+ break;
+  }
+  /* fall-through for GK20A */
case 0xf0:
case 0x100:
   *code = (const uint32_t *)&gk110_builtin_code[0];
@@ -71,7 +74,9 @@ TargetNVC0::getBuiltinOffset(int builtin) const
 
switch (chipset & ~0xf) {
case 0xe0:
-  return gk104_builtin_offsets[builtin];
+  if (chipset < NVISA_GK20A_CHIPSET)
+ return gk104_builtin_offsets[builtin];
+  /* fall-through for GK20A */
case 0xf0:
case 0x100:
   return gk110_builtin_offsets[builtin];
@@ -235,7 +240,7 @@ TargetNVC0::getFileSize(DataFile file) const
 {
switch (file) {
case FILE_NULL:  return 0;
-   case FILE_GPR:   return (chipset >= NVISA_GK110_CHIPSET) ? 255 : 63;
+   case FILE_GPR:   return (chipset >= NVISA_GK20A_CHIPSET) ? 255 : 63;
case FILE_PREDICATE: return 7;
case FILE_FLAGS: return 1;
case FILE_ADDRESS:   return 0;
-- 
1.9.3

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

Re: [Mesa-dev] [PATCH 2/2] nvc0: use SM35 ISA with GK20A

[Alexandre Courbot]

On 05/27/2014 02:26 PM, Ilia Mirkin wrote:

On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot  wrote:

GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use
the GK110 path when this chip is detected.

Signed-off-by: Alexandre Courbot 
---
  src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h|  1 +
  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp   |  2 +-
  src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp | 13 +
  3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
index bbb89d97932e..aab857ee7e4f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
@@ -91,6 +91,7 @@ struct nv50_ir_prog_symbol
  #define NVISA_GF100_CHIPSET_C0 0xc0
  #define NVISA_GF100_CHIPSET_D0 0xd0
  #define NVISA_GK104_CHIPSET0xe0
+#define NVISA_GK20A_CHIPSET0xea
  #define NVISA_GK110_CHIPSET0xf0
  #define NVISA_GM107_CHIPSET0x110

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index b1f76cf80432..f69e6a183e19 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -3027,7 +3027,7 @@ TargetNVC0::createCodeEmitterNVC0(Program::Type type)
  CodeEmitter *
  TargetNVC0::getCodeEmitter(Program::Type type)
  {
-   if (chipset >= NVISA_GK110_CHIPSET)
+   if (chipset >= NVISA_GK20A_CHIPSET)
return createCodeEmitterGK110(type);
 return createCodeEmitterNVC0(type);
  }


As mentioned on IRC, you also need to update TargetNVC0::getFileSize
to return 255 GPRs, since that value is presumably ISA-specific. You
could, at that point, get rid of the GK110_CHIPSET define.


Will do.


Eventually
all that stuff needs to be nuked and replaced with an 'isa' property.
But you don't have to do that.


diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
index 064e7a2c63f9..8212bfd9555e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
@@ -49,9 +49,12 @@ TargetNVC0::getBuiltinCode(const uint32_t **code, uint32_t 
*size) const
  {
 switch (chipset & ~0xf) {
 case 0xe0:
-  *code = (const uint32_t *)&gk104_builtin_code[0];
-  *size = sizeof(gk104_builtin_code);
-  break;
+  if (chipset != NVISA_GK20A_CHIPSET) {


You change the code emitter if chipset >= GK20A. Might as well be
consistent here and below.


Sure.

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

Re: [Mesa-dev] [PATCH 1/2] nvc0: add GK20A 3D class

[Alexandre Courbot]

On 05/27/2014 02:29 PM, Ilia Mirkin wrote:

On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot  wrote:

GK20A is mostly compatible with GK104, but features a new 3D
class. Add it to the relevant header and use it when GK20A is
detected.

Signed-off-by: Alexandre Courbot 
---
  src/gallium/drivers/nouveau/nv_object.xml.h| 1 +
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 9 -
  2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv_object.xml.h 
b/src/gallium/drivers/nouveau/nv_object.xml.h
index 4c93e6564838..0a0e187dc028 100644
--- a/src/gallium/drivers/nouveau/nv_object.xml.h
+++ b/src/gallium/drivers/nouveau/nv_object.xml.h
@@ -190,6 +190,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
  #define NVC8_3D_CLASS  0x9297
  #define NVE4_3D_CLASS  0xa097
  #define NVF0_3D_CLASS  0xa197
+#define NVEA_3D_CLASS  0xa297
  #define GM107_3D_CLASS 0xb097
  #define NV50_2D_CLASS  0x502d
  #define NVC0_2D_CLASS  0x902d
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index cccfe2bba23d..95e5ef81cd79 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -702,7 +702,14 @@ nvc0_screen_create(struct nouveau_device *dev)
obj_class = NVF0_3D_CLASS;
break;
 case 0xe0:
-  obj_class = NVE4_3D_CLASS;
+  switch (dev->chipset) {
+  case 0xea:
+ obj_class = NVEA_3D_CLASS;


Again, would be nice to be consistent with the way you set the ISA...
perhaps change this to a >= as well? But I guess the two could be
disconnected. Up to you, just thought I'd bring it up.


Right below we have the following being done:

 switch (dev->chipset) {
  case 0xc8:
 obj_class = NVC8_3D_CLASS;
 break;
  case 0xc1:
 obj_class = NVC1_3D_CLASS;
 break;
  default:
 obj_class = NVC0_3D_CLASS;
 break;
  }

Shouldn't we try to be consistent with this more local example instead?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] nvc0: add GK20A 3D class

[Alexandre Courbot]

GK20A is mostly compatible with GK104, but features a new 3D
class. Add it to the relevant header and use it when GK20A is
detected.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/nv_object.xml.h| 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 9 -
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv_object.xml.h 
b/src/gallium/drivers/nouveau/nv_object.xml.h
index 4c93e6564838..0a0e187dc028 100644
--- a/src/gallium/drivers/nouveau/nv_object.xml.h
+++ b/src/gallium/drivers/nouveau/nv_object.xml.h
@@ -190,6 +190,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #define NVC8_3D_CLASS  0x9297
 #define NVE4_3D_CLASS  0xa097
 #define NVF0_3D_CLASS  0xa197
+#define NVEA_3D_CLASS  0xa297
 #define GM107_3D_CLASS 0xb097
 #define NV50_2D_CLASS  0x502d
 #define NVC0_2D_CLASS  0x902d
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index cccfe2bba23d..95e5ef81cd79 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -702,7 +702,14 @@ nvc0_screen_create(struct nouveau_device *dev)
   obj_class = NVF0_3D_CLASS;
   break;
case 0xe0:
-  obj_class = NVE4_3D_CLASS;
+  switch (dev->chipset) {
+  case 0xea:
+ obj_class = NVEA_3D_CLASS;
+ break;
+  default:
+ obj_class = NVE4_3D_CLASS;
+ break;
+  }
   break;
case 0xd0:
   obj_class = NVC8_3D_CLASS;
-- 
1.9.3

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

[Mesa-dev] [PATCH 0/2] nvc0: support for GK20A (Tegra K1)

[Alexandre Courbot]

The following 2 patches make it possible to run Mesa programs on GK20A
(Tegra K1).

GK20A is very similar to GK104, but uses a new (backward-compatible) 3D class
as well as the same ISA as GK110 (SM35). Taking these differences into account
is sufficient to successfully render simple off-screen buffers.

Alexandre Courbot (2):
  nvc0: add GK20A 3D class
  nvc0: use SM35 ISA with GK20A

 src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h|  1 +
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp   |  2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp | 13 +
 src/gallium/drivers/nouveau/nv_object.xml.h |  1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c  |  9 -
 5 files changed, 20 insertions(+), 6 deletions(-)

-- 
1.9.3

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

[Mesa-dev] [PATCH 2/2] nvc0: use SM35 ISA with GK20A

[Alexandre Courbot]

GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use
the GK110 path when this chip is detected.

Signed-off-by: Alexandre Courbot 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h|  1 +
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp   |  2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp | 13 +
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
index bbb89d97932e..aab857ee7e4f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
@@ -91,6 +91,7 @@ struct nv50_ir_prog_symbol
 #define NVISA_GF100_CHIPSET_C0 0xc0
 #define NVISA_GF100_CHIPSET_D0 0xd0
 #define NVISA_GK104_CHIPSET0xe0
+#define NVISA_GK20A_CHIPSET0xea
 #define NVISA_GK110_CHIPSET0xf0
 #define NVISA_GM107_CHIPSET0x110
 
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index b1f76cf80432..f69e6a183e19 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -3027,7 +3027,7 @@ TargetNVC0::createCodeEmitterNVC0(Program::Type type)
 CodeEmitter *
 TargetNVC0::getCodeEmitter(Program::Type type)
 {
-   if (chipset >= NVISA_GK110_CHIPSET)
+   if (chipset >= NVISA_GK20A_CHIPSET)
   return createCodeEmitterGK110(type);
return createCodeEmitterNVC0(type);
 }
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
index 064e7a2c63f9..8212bfd9555e 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nvc0.cpp
@@ -49,9 +49,12 @@ TargetNVC0::getBuiltinCode(const uint32_t **code, uint32_t 
*size) const
 {
switch (chipset & ~0xf) {
case 0xe0:
-  *code = (const uint32_t *)&gk104_builtin_code[0];
-  *size = sizeof(gk104_builtin_code);
-  break;
+  if (chipset != NVISA_GK20A_CHIPSET) {
+ *code = (const uint32_t *)&gk104_builtin_code[0];
+ *size = sizeof(gk104_builtin_code);
+ break;
+  }
+  /* fall-through for GK20A */
case 0xf0:
case 0x100:
   *code = (const uint32_t *)&gk110_builtin_code[0];
@@ -71,7 +74,9 @@ TargetNVC0::getBuiltinOffset(int builtin) const
 
switch (chipset & ~0xf) {
case 0xe0:
-  return gk104_builtin_offsets[builtin];
+  if (chipset != NVISA_GK20A_CHIPSET)
+ return gk104_builtin_offsets[builtin];
+  /* fall-through for GK20A */
case 0xf0:
case 0x100:
   return gk110_builtin_offsets[builtin];
-- 
1.9.3

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