Am Dienstag, den 30.10.2018, 16:52 -0400 schrieb Ilia Mirkin:
[snip]
> > > }
> > > #endif
> > >
> > > + extensions->EXT_sRGB_write_control =
> > > + screen->is_format_supported(screen,
> > > PIPE_FORMAT_B8G8R8A8_SRGB,
> > > + PIPE_TEXTURE_2D, 0,
On 10/31/18 7:28 AM, Tapani Pälli wrote:
On 10/31/18 12:57 AM, Timothy Arceri wrote:
On 30/10/18 10:14 pm, Tapani Pälli wrote:
Hi;
On 10/30/18 1:28 AM, Timothy Arceri wrote:
On 29/10/18 10:05 pm, Vadim Shovkoplias wrote:
Hi Timothy,
Thanks for the review. Piglit patch is updated with th
Am Montag, den 29.10.2018, 17:13 + schrieb Eric Engestrom:
> Signed-off-by: Eric Engestrom
> ---
> src/gallium/drivers/r600/sb/sb_expr.cpp | 10 +-
> src/gallium/drivers/r600/sb/sb_if_conversion.cpp | 4 ++--
> src/gallium/drivers/r600/sb/sb_ir.h | 2 +-
> src/
Acked-by: Samuel Pitoiset
On 10/30/18 10:41 PM, Mauro Rossi wrote:
libmesa_git_sha1 whole static dependency is added to get git_sha1.h header
and avoid following building error:
external/mesa/src/amd/vulkan/radv_device.c:46:10:
fatal error: 'git_sha1.h' file not found
^
1 error gener
On Wed, 2018-10-31 at 13:22 +1100, Timothy Arceri wrote:
> On 31/10/18 1:23 am, Jason Ekstrand wrote:
> > Weird. I didn't expect this patch to have any impact whatsoever.
> > I
> > thought it was just moving around the way we emit stuff.
>
> I think I've spotted the problem. Iago does patch 1 he
https://bugs.freedesktop.org/show_bug.cgi?id=108610
Bug ID: 108610
Summary: build error on i386 - util/rounding.h:108: undefined
reference to `lrintf'
Product: Mesa
Version: git
Hardware: x86 (IA32)
OS: Linu
--default_library=static indeed solves the zlib and expat dependency so I
tweaked my build script to do just that, As for the LLVM linking problems I
think I finally understand what's going on. llvm-wrap option always links LLVM
dynamically and ignores or it is incompatible with -Dshared-llvm=f
On 2018-10-31 12:39 a.m., Gustaw Smolarczyk wrote:
> śr., 31 paź 2018 o 00:23 Marek Olšák napisał(a):
>> On Tue, Oct 30, 2018 at 7:11 PM Gustaw Smolarczyk
>> wrote:
>>> wt., 30 paź 2018 o 23:55 Marek Olšák napisał(a):
On Tue, Oct 30, 2018 at 6:32 PM Gustaw Smolarczyk
wrote:
> wt
https://bugs.freedesktop.org/show_bug.cgi?id=108508
--- Comment #17 from Ahmed Elsayed ---
(In reply to Vladimir from comment #16)
> renderdoccmd wine game.exe crashing too?
The stable version (1.1) doesn't crash but it doesn't show the objects effected
by VK_EXT_transform_feedback, so it doesn'
Hello,
Thanks a lot)
Regards,
Andrii.
On Tue, Oct 30, 2018 at 9:22 PM Jordan Justen
wrote:
> On 2018-10-26 01:06:52, andrey simiklit wrote:
> > Hi,
> >
> > Could you please help me with a push. I don't have a right for it :-)
> >
>
> I pushed these two patches. Thanks!
>
> e4e0fd5ffe1 i965/bat
https://bugs.freedesktop.org/show_bug.cgi?id=108610
--- Comment #1 from Sergii Romantsov ---
Hello, Fabio.
It looks like a duplicate of
https://bugs.freedesktop.org/show_bug.cgi?id=108560
And patch: https://patchwork.freedesktop.org/patch/259176/
--
You are receiving this mail because:
You are
On Tue, 30 Oct 2018 at 17:49, Eric Anholt wrote:
>
> Emil Velikov writes:
>
> > Hi Eric,
> >
> > On Thu, 25 Oct 2018 at 17:39, Eric Anholt wrote:
> >>
> >> This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with
> >> the new tinydrm driver I just submitted. If this series exte
On Tue, 30 Oct 2018 at 18:15, Rob Clark wrote:
>
> On Tue, Oct 30, 2018 at 1:34 PM Emil Velikov wrote:
> >
> > On Tue, 30 Oct 2018 at 17:19, Rob Clark wrote:
> > > On Tue, Oct 30, 2018 at 11:27 AM Emil Velikov
> > > wrote:
> >
> > > > > > NOTE: if bisecting a build error takes you hear, try a
On Mon, 29 Oct 2018 at 11:46, Juan A. Suarez Romero wrote:
>
> On Tue, 2018-10-16 at 15:12 -0500, Jason Ekstrand wrote:
> > This reverts commit 0fa9e6d7b304f6a8064ed78a4b9c557e1026e7e5. The real
> > issue appears to have been that HiZ ops don't like having WM thread
> > dispatch force-enabled. T
On Mon, 29 Oct 2018 at 19:11, Christian Gmeiner
wrote:
>
> This reverts commit 773d6ea6e715d207bda3a53a9dfc8acf686035b0.
>
> Since kernel 4.17 (drm/etnaviv: remove the need for a gpu-subsystem DT
> node) the etnaviv DRM driver doesn't have an associated DT node
> anymore. This is technically corre
Hi Tapani, Timothy,
I also did some testing on my SNB laptop and didn't noticed any issues. CI
also didn't show that issues.
Regards,
Vadym
ср, 31 окт. 2018 г. в 9:13, Tapani Pälli :
>
>
> On 10/31/18 7:28 AM, Tapani Pälli wrote:
> >
> >
> > On 10/31/18 12:57 AM, Timothy Arceri wrote:
> >> On
For now I have only enabled this for RADV we can do it
also for radeonsi also but we need to add a CAP for it.
vkpipeline-db results:
Totals from affected shaders:
SGPRS: 4104 -> 3728 (-9.16 %)
VGPRS: 3604 -> 3472 (-3.66 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private mem
Hello,
On Tue, Oct 30, 2018 at 9:14 PM Kenneth Graunke
wrote:
> On Friday, October 26, 2018 1:06:52 AM PDT andrey simiklit wrote:
> > Hi,
> >
> > Could you please help me with a push. I don't have a right for it :-)
> >
> > Thanks,
> > Andrii.
>
> Thanks for fixing these up!
>
> While we're here
Fixes: b4eb029062a ("radv: implement VK_EXT_transform_feedback")
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_private.h | 1 +
src/amd/vulkan/radv_query.c | 277 ++
2 files changed, 278 insertions(+)
diff --git a/src/amd/vulkan/radv_private.h b/src/a
https://bugs.freedesktop.org/show_bug.cgi?id=108508
--- Comment #18 from Samuel Pitoiset ---
Yes, please use apitrace if renderdoc crashes.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.__
Since commit "intel/compiler: Stop assuming the entrypoint is called
"main"" there is no need to force the entrypoint name to be "main".
---
src/mesa/main/glspirv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
index 98b7ea77348..04e46ba571e 1
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_query.c | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 33259773441..a033b3a7f44 100644
--- a/src/amd/vulkan/radv_query.c
+++
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 2 +-
src/amd/vulkan/radv_private.h| 5 ++---
src/amd/vulkan/radv_query.c | 3 ++-
src/amd/vulkan/si_cmd_buffer.c | 14 +-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/src/amd/vulka
Seems fine.
Reviewed-by: Samuel Pitoiset
On 10/31/18 3:58 AM, Dave Airlie wrote:
From: Dave Airlie
This is incorrect, the offset is into the buffer, and it's legal
to write
loc 0,0 -> buffer0, offset 0
loc 0,1 -> buffer1, offset 0
This fixes a bunch of piglits running on my zink xfb code o
nir_alu_type_get_type_size takes a type as parameter and we were
passing a bit-size instead, which did what we wanted by accident,
since a bit-size of zero matches nir_type_invalid, which has a
size of 0 too.
---
src/compiler/nir/nir_opt_constant_folding.c | 4 +---
1 file changed, 1 insertion(+),
From: Emil Velikov
Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom
---
.travis.yml | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 78e6d251ae4..1e0e8758bf5 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -92,6 +92,7 @@ matr
https://bugs.freedesktop.org/show_bug.cgi?id=100960
--- Comment #18 from Sergii Romantsov ---
Hello, Fabian.
At this moment i'm looking on possibility to workaround it only for Minecraft.
Could i ask for a help?:
1. To run Minecraft with mod
2. To get outputs of:
2.1 ps -fux
2.2 sudo grep i965_dr
From: Emil Velikov
Pretty much all of the scripts are python2+3 compatible.
Check and allow using python3, while adjusting the PYTHON2 refs.
Note:
- python3.4 is used as it's the earliest supported version
- python2 chosen prior to python3
v2: use python2 by default
Cc: Ilia Mirkin
Signed-o
This is still pending review, any takers?
Thanks
Iago
On Wed, 2018-10-17 at 12:05 +0200, Iago Toral Quiroga wrote:
> SIMD16 instructions need to have additional interferences to prevent
> source / destination hazards when the source and destination
> registers
> are off by one register.
>
> While
On Wednesday, 2018-10-31 11:22:41 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Pretty much all of the scripts are python2+3 compatible.
> Check and allow using python3, while adjusting the PYTHON2 refs.
>
> Note:
> - python3.4 is used as it's the earliest supported version
> - python2 c
Hello,
Sorry, one more point here.
Could I ask you to push it, because I don't have a push rights :-)
Thanks a lot,
Andrii.
On Fri, Oct 26, 2018 at 6:09 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> On 26/10/2018 15:29, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit
https://bugs.freedesktop.org/show_bug.cgi?id=108611
Bug ID: 108611
Summary: radv: LLVM 8.0 breaks lighting in Mass Effect
Andromeda
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108611
--- Comment #1 from Philip Rebohle ---
Created attachment 142301
--> https://bugs.freedesktop.org/attachment.cgi?id=142301&action=edit
Screenshot with broken rendering
--
You are receiving this mail because:
You are the QA Contact for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=108611
--- Comment #2 from Philip Rebohle ---
Created attachment 142302
--> https://bugs.freedesktop.org/attachment.cgi?id=142302&action=edit
Screenshot with correct rendering
--
You are receiving this mail because:
You are the QA Contact for the b
https://bugs.freedesktop.org/show_bug.cgi?id=106833
Tapani Pälli changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, 31 Oct 2018 at 11:29, Eric Engestrom wrote:
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -124,9 +124,7 @@ AC_PROG_GREP
> > AC_PROG_NM
> > AM_PROG_AS
> > AX_CHECK_GNU_MAKE
> > -AM_PATH_PYTHON([2.7],, [:])
> > -PYTHON2=$PYTHON
> > -AC_SUBST([PYTHON2])
> > +AM_PATH_PYTHON([2.7],,
The engine to which the batch was sent to is now set to the decoder context when
decoding the batch. This is needed so that we can distinguish between
instructions as the render and video pipe share some of the instruction opcodes.
v2: The engine is now in the decoder context and the batch decoder
These patches add an engine parameter to the instructions defined in the genxml
files so that they can be distinguished when sending them to different engines.
By default, an instruction is defined to be used by all engines and is defined
for a specific engine by adding the parameter "engine" to th
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen7.xml | 154 +++---
1 f
Preliminary work for adding handling of different pipes to gen_decoder. Each
instruction needs to have a definition describing which engine it is meant for.
If left undefined, by default, the instruction is defined for all engines.
v2: Changed to use the engine class definitions from UAPI
---
src
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen6.xml | 94 +++
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen5.xml | 44 +++
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen45.xml | 38 +++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen10.xml | 206 ++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen8.xml | 202 +++---
1 f
Removed the gen_engine enum and changed the involved functions to use the
drm_i915_gem_engine_class enum from UAPI instead.
---
src/intel/tools/aub_read.c | 22 +++---
src/intel/tools/aub_read.h | 11 +++
src/intel/tools/aubinator.c | 5 ++---
3 files changed, 16 inserti
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen4.xml | 36 ++--
1 file
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen75.xml | 184 ++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen9.xml | 208 +++---
1 f
Instructions meant for the render engine now have a definition specifying that
so that can differentiate instructions meant for different engines due to shared
opcodes.
v2: Divided into individual patches for each gen
---
src/intel/genxml/gen11.xml | 208 ++---
1 f
From: Emil Velikov
Currently the minimal version is 3.3 with 3.9 for r600+opencl.
We kept it as low, since transitioning to newer ones is pain on Windows.
With issues ranging from build problems, memory leaks and various other
small nitpicks throughout.
Currently we use 5.0.1 for our Appveyor t
From: Emil Velikov
As mentioned in earlier commit - all recent distros have it.
With the version bumped, we can drop all the ugly hacks we've been
carrying for years.
Signed-off-by: Emil Velikov
---
configure.ac | 85
1 file changed, 13 inse
From: Emil Velikov
We'll bump the number in the build systems shortly. Update the travis
file, first, to avoid intermittent failures.
This effectively removes LLVM 3.9 and 4.0 from the build matrix.
Cc: Juan A. Suarez Romero
Cc: Dylan Baker
Signed-off-by: Emil Velikov
---
Gents any idea how
Currently the minimal version is 3.3 with 3.9 for r600+opencl.
We kept it as low, since transitioning to newer ones is pain on Windows.
With issues ranging from build problems, memory leaks and various other
small nitpicks throughout.
Currently we use 5.0.1 for our Appveyor testing, so we
From: Emil Velikov
The option has been long superseded with LLVM_CONFIG.
Distributions have been using it for a couple of years now.
Signed-off-by: Emil Velikov
---
configure.ac | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index f
From: Emil Velikov
Mauro has a handful of branches for Android 8 (Oreo) onward.
Cc: Mauro Rossi
Cc: Rob Herring
---
AFAICS Mauro has branches for 5.0, 6.0 and 7.0. Using either one
requires manual intervention. Namely: change the HAVE_LLVM + libname
in this file.
Personally, would jump the 7.
From: Emil Velikov
Cc: Jose Fonseca
Cc: Brian Paul
Signed-off-by: Emil Velikov
---
scons/llvm.py | 95 +--
1 file changed, 8 insertions(+), 87 deletions(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index a84ad51d97a..2865fc5f1c0 100644
--- a/s
From: Emil Velikov
LLVM versions earlier than 5.0.1 are no longer supported.
Cc: Jan Vesely
Cc: Francisco Jerez
Cc: Aaron Watry
Signed-off-by: Emil Velikov
---
I guess some of compat.hpp can be cleaned-up, but I'd suggest sticking
with that as a follow-up.
---
.../clover/llvm/codegen/bitcod
From: Emil Velikov
The options allows you to specify custom location of clang and friends.
That may have been required for old and buggy llvm-config, which could
produce the wrong path.
This isn't the case with LLVM 5.0.1 at least, so we no longer need this
hack.
Signed-off-by: Emil Velikov
--
From: Emil Velikov
LLVM versions earlier than 5.0.1 are no longer supported.
Cc: Roland Scheidegger
Cc: Jose Fonseca
Signed-off-by: Emil Velikov
---
src/gallium/drivers/llvmpipe/lp_jit.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_jit.c
b/src/galli
From: Emil Velikov
With LLVM 5.0.1 the minimum required version, we can drop all the dead
code.
Cc: Roland Scheidegger
Cc: Jose Fonseca
Signed-off-by: Emil Velikov
---
Gents this is a quick and dirty grep job. A couple of places may need
the comments to be tweaked/dropped - I've annotated tho
From: Emil Velikov
LLVM versions earlier than 5.0.1 are no longer supported.
Cc: Alok Hota
Cc: Bruce Cherniak
Cc: George Kyriazis
Signed-off-by: Emil Velikov
---
Hi all,
I know the team does some back and forth import of the codebase
elsewhere. So if this patch causes grief let me know and
From: Emil Velikov
It was needed for a LLVM workaround that is no longer around.
Signed-off-by: Emil Velikov
---
configure.ac | 7 ---
1 file changed, 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 7a1ae058b5f..8f0557cef2b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75
On 10/30/18 7:11 PM, Erik Faye-Lund wrote:
In GLES, we currently either need an exact match with a local function,
or an exact match with a builtin.
However, if we add support for implicit conversions for GLES shaders,
we also need to fall back to a non-exact match in the case where there
were
Seems I screwed up with the engine for video and accidentally left *_RENDER as
the engine. Will follow up with v3.
On Wed, Oct 31, 2018 at 03:12:48PM +0200, Toni Lönnberg wrote:
> Removed the gen_engine enum and changed the involved functions to use the
> drm_i915_gem_engine_class enum from UAPI
LGTM, series is:
Reviewed-by: Tapani Pälli
On 10/30/18 7:11 PM, Erik Faye-Lund wrote:
EXT_shader_implicit_conversions is a useful extension that adds implicit
conversions to OpenGL ES 3.1. Since it's tested excensively in dEQP, and
Mesa already has support for implicit conversions, it seems rea
https://bugs.freedesktop.org/show_bug.cgi?id=108611
Samuel Pitoiset changed:
What|Removed |Added
Summary|radv: LLVM 8.0 breaks |[radv]
|lighting in
Removed the gen_engine enum and changed the involved functions to use the
drm_i915_gem_engine_class enum from UAPI instead.
v3: Wrong engine was being used for blocks in video ring
---
src/intel/tools/aub_read.c | 22 +++---
src/intel/tools/aub_read.h | 11 +++
src/intel
On Tue, 2018-10-30 at 16:38 -0700, Eric Anholt wrote:
> Eric Anholt writes:
>
> > The CTS requires a 565-no-depth-no-stencil config for ES 3.0, but at depth
> > 24 of X11 we wouldn't do so. We can satisfy that bad requirement using a
> > pbuffer-only visual with whatever other buffers the driver
https://bugs.freedesktop.org/show_bug.cgi?id=104302
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Toni,
I'm a bit curious where you're going with this. I started on a similar
project a couple of years ago:
https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/genxml-engines
Mine took a different (not necessarily better) approach of surrounding the
instructions in an tag. I'm not sure
Sorry I missed that one.
Reviewed-by: Jason Ekstrand
On Wed, Oct 31, 2018 at 5:57 AM Alejandro Piñeiro
wrote:
> Since commit "intel/compiler: Stop assuming the entrypoint is called
> "main"" there is no need to force the entrypoint name to be "main".
> ---
> src/mesa/main/glspirv.c | 1 -
> 1
Reviewed-by: Jason Ekstrand
Thanks for figuring this out. This probably explains some of the hurt I
was seeing with my series as well.
--Jason
On Tue, Oct 30, 2018 at 9:17 PM Timothy Arceri
wrote:
> From: Timothy Arceri
>
> We need to update the cursor before we check if the alu use is
> do
On Tue, Oct 30, 2018 at 9:17 PM Timothy Arceri
wrote:
> With the simplifications to this pass in a3b4cb34589e2f1a68 we
> can allow any alu instruction to be processed. For one this can
> potentially help with bcsels.
>
Do we want to? I believe that this patch is correct and I agree that we
now
https://bugs.freedesktop.org/show_bug.cgi?id=108611
Michel Dänzer changed:
What|Removed |Added
CC||nhaeh...@gmail.com
--
You are receivin
On 31/10/2018 14:20, Jason Ekstrand wrote:
Toni,
I'm a bit curious where you're going with this. I started on a
similar project a couple of years ago:
https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/genxml-engines
Mine took a different (not necessarily better) approach of surround
https://bugs.freedesktop.org/show_bug.cgi?id=108105
Samuel Pitoiset changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
Signed-off-by: Eric Engestrom
---
REVIEWERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/REVIEWERS b/REVIEWERS
index e61f4ba96934fea97837..a1b63b55503c2ff870f2 100644
--- a/REVIEWERS
+++ b/REVIEWERS
@@ -65,6 +65,7 @@ F: src/loader/
EGL
R: Eric Engestrom
F: src/egl/
+F: include/EGL/
Signed-off-by: Eric Engestrom
---
REVIEWERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/REVIEWERS b/REVIEWERS
index 4751c36d9db73453fed0..9024510d303fc647399b 100644
--- a/REVIEWERS
+++ b/REVIEWERS
@@ -134,3 +134,8 @@ F: src/gallium/drivers/freedreno/
GLX
R: Adam Jackson
F: src/
Cc: Emil Velikov
Signed-off-by: Eric Engestrom
---
REVIEWERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/REVIEWERS b/REVIEWERS
index a1b63b55503c2ff870f2..4751c36d9db73453fed0 100644
--- a/REVIEWERS
+++ b/REVIEWERS
@@ -64,6 +64,7 @@ F: src/loader/
EGL
R: Eric Engestrom
+R: Emil Veli
On Wed, 2018-10-31 at 15:46 +0200, Tapani Pälli wrote:
>
> On 10/30/18 7:11 PM, Erik Faye-Lund wrote:
> > In GLES, we currently either need an exact match with a local
> > function,
> > or an exact match with a builtin.
> >
> > However, if we add support for implicit conversions for GLES
> > shad
https://bugs.freedesktop.org/show_bug.cgi?id=106980
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> From: Emil Velikov
>
> LLVM versions earlier than 5.0.1 are no longer supported.
I'd prefer to keep llvm-3.9, since it's the last version that supports
images for r600, but I'd leave the final decision to Francisco.
Jan
>
> Cc: Jan Vese
I had to do a double (or triple) take on this logic as well. Part of
the subtlety is that the fallback only applies for ES when there's a
match but no exact match. Probably good to mention this.
On Wed, Oct 31, 2018 at 11:13 AM Erik Faye-Lund
wrote:
>
> On Wed, 2018-10-31 at 15:46 +0200, Tapani Pä
In GLSL versions 1.00 ES, 1.10 and 1.20, Mesa includes
some built-in functions which shouldn't be present in
that version, namely:
genIType abs(genIType x)
genIType sign(genIType x)
genIType min(genIType x, genIType y)
genIType min(genIType x, int y)
genIType max(genIType x, genITyp
When we debug media or 3d+media workloads, we'd like to be able to see what is
in the aub dumps for those workloads. At the moment the decoder can't
distinguish instructions which share the same opcode between the render and
video pipe, and thus aubinator outputs garbage on media instructions.
Quoting Liviu Prodea (2018-10-31 01:50:25)
> --default_library=static indeed solves the zlib and expat dependency so I
> tweaked my build script to do just that, As for the LLVM linking problems I
> think I finally understand what's going on. llvm-wrap option always links LLVM
> dynamically and ign
Quoting Emil Velikov (2018-10-31 04:22:41)
> From: Emil Velikov
>
> Pretty much all of the scripts are python2+3 compatible.
> Check and allow using python3, while adjusting the PYTHON2 refs.
>
> Note:
> - python3.4 is used as it's the earliest supported version
> - python2 chosen prior to pyt
On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> From: Emil Velikov
>
> The option has been long superseded with LLVM_CONFIG.
> Distributions have been using it for a couple of years now.
I've been using it in my configure setup. This might be a stupid
question; is the LLVM_CONFIG env va
On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> The option has been long superseded with LLVM_CONFIG.
>> Distributions have been using it for a couple of years now.
>
> I've been using it in my configure setup.
Same
Am 31.10.18 um 14:30 schrieb Emil Velikov:
> From: Emil Velikov
>
> With LLVM 5.0.1 the minimum required version, we can drop all the dead
> code.
>
> Cc: Roland Scheidegger
> Cc: Jose Fonseca
> Signed-off-by: Emil Velikov
> ---
> Gents this is a quick and dirty grep job. A couple of places m
https://bugs.freedesktop.org/show_bug.cgi?id=108160
--- Comment #1 from vadym ---
Patch: https://patchwork.freedesktop.org/patch/259519/
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.
On Wed, 2018-10-31 at 12:01 -0400, Ilia Mirkin wrote:
> I had to do a double (or triple) take on this logic as well. Part of
> the subtlety is that the fallback only applies for ES when there's a
> match but no exact match. Probably good to mention this.
Yeah, that makes sense. I thought I mention
gtest is an external project that is copied in this tree for technical
reasons, but isn't maintained by us, so its warnings are irrelevant.
Cc: Emil Velikov
Signed-off-by: Eric Engestrom
---
src/gtest/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gtest/meson.build b/src/gt
On Wed, 31 Oct 2018 at 14:54, Eric Engestrom wrote:
>
> Cc: Emil Velikov
> Signed-off-by: Eric Engestrom
Acked-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, 31 Oct 2018 at 15:57, Jan Vesely wrote:
>
> On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > LLVM versions earlier than 5.0.1 are no longer supported.
>
> I'd prefer to keep llvm-3.9, since it's the last version that supports
> images for r600, but I'd
On Wed, Oct 31, 2018 at 12:37 PM Erik Faye-Lund
wrote:
>
> On Wed, 2018-10-31 at 12:01 -0400, Ilia Mirkin wrote:
> > I had to do a double (or triple) take on this logic as well. Part of
> > the subtlety is that the fallback only applies for ES when there's a
> > match but no exact match. Probably
gtest doesn't generate any warnings, but this seems fine,
Reviewed-by: Dylan Baker
Quoting Eric Engestrom (2018-10-31 09:43:03)
> gtest is an external project that is copied in this tree for technical
> reasons, but isn't maintained by us, so its warnings are irrelevant.
>
> Cc: Emil Velikov
>
On Wed, 31 Oct 2018 at 16:24, Michel Dänzer wrote:
>
> On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> >> From: Emil Velikov
> >>
> >> The option has been long superseded with LLVM_CONFIG.
> >> Distributions have been using it for a couple o
On Wed, 31 Oct 2018 at 16:18, Dylan Baker wrote:
>
> Quoting Emil Velikov (2018-10-31 04:22:41)
> > From: Emil Velikov
> >
> > Pretty much all of the scripts are python2+3 compatible.
> > Check and allow using python3, while adjusting the PYTHON2 refs.
> >
> > Note:
> > - python3.4 is used as it
1 - 100 of 160 matches
Mail list logo
