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.c
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
e 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).
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
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
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 su
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
>>> ioct
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 brea
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
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
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
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 ch
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
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
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
ed-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_scr
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 l
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.
>>
>> Si
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
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
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
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
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
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 DR
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
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
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
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 lo
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
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 +
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
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
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
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
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 fixin
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!
__
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
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 ---
e 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()
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
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
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
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 dele
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
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
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
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
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
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
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
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
51 matches
Mail list logo
