own thread pool in CreateThreadPool
in swr/rasterizer/core/api.cpp
Is there a way to have a single “static” thread-pool shared across all contexts
?
Thank you
Alexandre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https
On 16 May 2018, at 14:34, Cherniak, Bruce wrote:
>
>>
>> On May 14, 2018, at 8:59 AM, Alexandre > <mailto:alexandre.gauthier-foic...@inria.fr>> wrote:
>>
>> Hello,
>>
>> Sorry for the inconvenience if this message is not appropriate for thi
hread-pool), see
https://github.com/halide/Halide/issues/129
<https://github.com/halide/Halide/issues/129>
- AMD HIP or NVIDIA Cuda (the latter can only run on Nvidia which we don’t want
to be tied to)
In the meantime, I will try to play around with the number of threads, while
wa
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
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
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
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
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
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
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
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
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
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
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
You are right, I missed that one. I'll send a v2 to fix it.
Alexandre Demers
On 2015-02-25 01:36, Ilia Mirkin wrote:
On Wed, Feb 25, 2015 at 1:34 AM, Alexandre Demers
wrote:
Lets define R600_MAX_VIEWPORTS instead of using 16 here and there
in the code when looping through viewport
Hi everyone,
I'd like to know if someone is working on Geometry shader instancing
for radeonsi or if there is already a work in progress somewhere I
would have missed. I might be interested in giving it a try and then
on GL_ARB_viewport_array.
Cheers.
Alexandre D
Then you can count me as working on ARB_viewport_array.
Alexandre Demers
On 2015-02-25 14:25, Marek Olšák wrote:
Nobody is working on ARB_gpu_shader5 for radeonsi.
Marek
On Wed, Feb 25, 2015 at 6:41 PM, Ilia Mirkin wrote:
On Wed, Feb 25, 2015 at 11:24 AM, Alexandre Demers
wrote:
Hi
Signed-off-by: Alexandre Demers
---
src/gallium/drivers/radeon/radeon_uvd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index fb1491a..81fba95 100644
--- a/src/gallium/drivers
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 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
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
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 Matt,
I saw your commit 5ec140c1 pass by and I think there is a typo in it.
You use "HAVE_FUNC_ATTRIBUTE_VISIBIITY" thrice in the patch and I
suspect there is a missing "L" to form "HAVE_FUNC_ATTRIBUTE_VISIBILITY"
instead.
dered
completed by a dev if it is truly complete.
I know, I can find it by other means, but why not just make sure we are
updating the doc at the right moment?
My two cents as a tester...
--
Alexandre Demers
___
mesa-dev mailing list
mes
On 10/18/2013 06:19 PM, Ian Romanick wrote:
On 10/18/2013 11:31 AM, Alexandre Demers wrote:
Hi,
I was looking at the latest commits and some comments here and there. Is
it me or is docs/GL3.txt not up to date?
I don't know of you're up to date or not, but GL3.txt almost surely is no
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index c269f19..a56e7fe 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -71,7 +71,7 @@ Base vertex offset(GL_ARB_draw_elements_base_vertex) DONE
(i965, r300, r600, sw
Frag shader coor
I don't have commit rights. I'd appreciate if someone could commit it
for me.
Also, I think it should be a candidat for 9.2 branch.
Alexandre Demers
On 10/20/2013 01:56 PM, Marek Olšák wrote:
Reviewed-by: Marek Olšák
Marek
On Sun, Oct 20, 2013 at 7:48 PM, Alexandre Dem
/LT_005fINIT.html
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=50754
Signed-off-by: Alexandre Demers
Tested-by: Tapani Palli
---
configure.ac | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index fb16338..d41595d 100644
--- a
Signed-off-by: Alexandre Demers
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index faf1485..98efa43 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1603,7 +1603,7 @@ fi
AC_ARG_WITH([egl-driver-dir],
[AS_HELP_STRING
Making default OMX installation folder follows the same pattern as
other state trackers / libs. Fixes bug 80615.
Signed-off-by: Alexandre Demers
---
configure.ac | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 98efa43..a684390
This patch fixes bug 71543 where libudev.so.0 and libudev.so.1 are in
conflict. With this patch, I was able to launch Garry's Mod (which
previously would crash before showing anything).
So you can add
Tested-by: Alexandre Demers
--
Alexandre D
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
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
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
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
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 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
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
scope for now.
Also, about the patch itself, even if only some cards were reported to be
problematic, why would we limit it to "ws->gen == DRV_SI"? Any cards
reporting a wrong value should be treated the same way by mapping its value
from 12 to 8, no?
My late two cents here.
Alexan
On Tue, 9 Feb 2016 at 12:47 Marek Olšák wrote:
> On Tue, Feb 9, 2016 at 6:17 PM, Alexandre Demers
> wrote:
> >> +/* The kernel returns 12 for some cards for an unknown
> >> reason.
> >> + * I thought this
On Tue, 9 Feb 2016 at 15:17 Alex Deucher wrote:
> On Tue, Feb 9, 2016 at 12:47 PM, Marek Olšák wrote:
> > On Tue, Feb 9, 2016 at 6:17 PM, Alexandre Demers
> > wrote:
> >>> +/* The kernel returns 12 for some cards for an unknown
> >>> reason.
&
Signed-off-by: Alexandre Demers
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 49c310c..aab81f9 100644
On Tue, 9 Feb 2016 at 22:38 Michel Dänzer wrote:
> On 10.02.2016 10:11, Alexandre Demers wrote:
> > Signed-off-by: Alexandre Demers
> > ---
> > src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
>
On 2016-02-10 05:14, Marek Olšák wrote:
On Wed, Feb 10, 2016 at 2:11 AM, Alexandre Demers
wrote:
Signed-off-by: Alexandre Demers
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm
v2: Clarify the relation between num_tiles_pipes and GB_TILE_MODE and the fix
needed for Tahiti as suggested by Marek.
Signed-off-by: Alexandre Demers
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium
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
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
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
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
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 ---
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
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!
__
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 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
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
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
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 +
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
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
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 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
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
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
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
Fix typo in comment introduced by 70dc8a
Signed-off-by: Alexandre Demers
---
src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
index
a lot on that matter. Then again, I'll let you know if needed.
Alexandre Demers
On 2015-03-04 21:45, Alexandre Demers wrote:
Then you can count me as working on ARB_viewport_array.
Alexandre Demers
On 2015-02-25 14:25, Marek Olšák wrote:
Nobody is working on ARB_gpu_shader5 for radeonsi.
e a bitmask saying which "slots" are dirty. (same
>principle as resource slots)
>
>The "emit" functions should only set dirty viewports/scissors registers.
>
>Marek
>
>
>
>On Thu, Mar 26, 2015 at 10:18 PM, Alexandre Demers
> wrote:
>> Update on
Hi Glenn,
I've tried applying your patch on the latest mesa code and it could not
be applied properly. Could you rebase your patch? I would be happy to
test it on Cayman for you once done.
Cheers.
--
Alexandre Demers
___
mesa-dev mailing
y first without the
patch.
--
Alexandre Demers
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
17474/1871617514/18755
spec
15903/1710615943/17145
glsl-1.50
3059/31063060/3106
execution
1628/16721629/1672
built-in-functions
1485/14871486/1487
gs-atan-vec2
passfail
Add this to my results with Tesseract and it is definitively an improvement.
Alexandre Demers
On 05/09/14 1
Sorry for the delay, I've been away for work and with not much free time
lately.
I'll have a look at it as soon as possible.
Alexandre Demers
On 10/09/14 06:16 AM, Glenn Kennard wrote:
On Sat, 06 Sep 2014 04:00:01 +0200, Alexandre Demers
wrote:
Thanks Marek, you were right.
So,
splay/piglit/generated_tests/spec/glsl-1.50/execution/built-in-functions/gs-atan-vec4.shader_test
-auto
PIGLIT: {"result": "pass" }
I assume the test ran correctly, but not in the context of the piglit
run, am I right?
Alexandre Demers
On 15/09/14 01:15 AM, Alexandre Demers w
Fixes linking error in libOSmesa when using libunwind.
Signed-off-by: Alexandre Demers
---
src/gallium/targets/osmesa/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/targets/osmesa/Makefile.am
b/src/gallium/targets/osmesa/Makefile.am
index
llium/auxiliary/util/u_debug_stack.c:120: undefined reference to
`_ULx86_64_step'
collect2: error: ld returned 1 exit status
v2 : Fixes title and adds the original error it is fixing.
Signed-off-by: Alexandre Demers
---
src/gallium/targets/osmesa/Makefile.am | 3 ++-
1 file changed, 2 i
Yes, please do.
Alexandre Demers
On Fri, May 26, 2017, 10:17 Brian Paul wrote:
> On 05/25/2017 09:09 PM, Alexandre Demers wrote:
> > Fixes linking error in libOSmesa when using libunwind.
> >
> > CXXLDlibOSMesa.la
> > src/gallium/auxiliary/.libs/libgallium.a(u_
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
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
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).
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
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
You can add my tested-by to the patch.
--
Alexandre Demers
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
I've been trying all day to sync sources from anongit.freedesktop.org
(dri and mesa) and it always ends up by a time out. Is there a problem
with the server or the address?
Cheers,
--
Alexandre Demers
___
mesa-dev mailing list
mes
ere Android
and killing old drivers.
Did you try putting the CFLAGS and LDFLAGS under configure.ac to see if
they would work there? Maybe they could be defined in your "if"
statements. I don't have LLVM 3 on my setup right now, but I may try it
soon.
May I suggest to fix that one also since there is a missing dependency
on d3dx state tracker?
https://bugs.freedesktop.org/show_bug.cgi?id=33938
Cheers,
--
Alexandre Demers
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
before.
Cheers,
--
Alexandre Demers
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,I've been following the development of mesa and gallium for some time now.
Each time a developer talks about the gallium i915/945 driver, it's always in
an "almost done" state... However, even now, it doesn't support everything the
dri driver does (glxinfo shows less extensions and so on fo
lot simpler to
compare the results.
I attached the patch.
Cheers,
--
Alexandre Demers
diff --git a/src/xdemos/glxinfo.c b/src/xdemos/glxinfo.c
index e4ff3d5..d0903c0 100644
--- a/src/xdemos/glxinfo.c
+++ b/src/xdemos/glxinfo.c
@@ -114,7 +114,6 @@ print_extension_list(const char *ext)
{
On 11-01-20 03:52 PM, Brian Paul wrote:
On 01/20/2011 12:35 PM, Alexandre Demers wrote:
Hi,
I'd like to propose a patch against glxinfo. Instead of separating the
extensions by a comma, it creates a new line. It's visually easier to
read through the extensions. Also, when doing a di
y see garbage
(automatic screenshots from the application are all black). If I don't
use the flag, the extension is disabled and RendererFeatTest works as
usual (still as some issues compared to another driver like i915 though
like no background and crippled text).
--
Alexan
94 matches
Mail list logo
