Patch adds support and capability to match with new surface attribute,
component type. Currently no configs with floating point type are exposed.
With this change, following dEQP test starts to pass:
dEQP-EGL.functional.choose_config.color_component_type_ext.dont_care
dEQP-EGL.functional.ch
On 2017-11-08 17:26:47, Timothy Arceri wrote:
> Reviewed-by: Timothy Arceri
>
> Mark may want to consider adding some of the once a day type CI runs for
> this. For example running the test suite for two consecutive runs on the
> same build so that the second run uses the shader cache and also
Hi Ilia, are you okay with this version of the patch?
Iago
On Tue, 2017-11-07 at 10:50 +0100, Iago Toral Quiroga wrote:
> Regarding location aliasing requirements, the OpenGL spec says:
>
> "Further, when location aliasing, the aliases sharing the location
> must have the same underlying nu
Mesa supports either 0 or 1 formats. If 1 format is supported, it is
GL_PROGRAM_BINARY_FORMAT_MESA as defined in the
GL_MESA_program_binary_formats extension spec.
Signed-off-by: Jordan Justen
---
src/mesa/main/get.c | 9 +
src/mesa/main/get_hash_params.py | 2 +-
2 files ch
Signed-off-by: Jordan Justen
---
src/mesa/main/dd.h| 4
src/mesa/main/shaderapi.c | 38 +-
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index c20d8b80e1d..b46f2693b83 100644
--- a/src/mes
Signed-off-by: Jordan Justen
---
src/mesa/main/dd.h| 4
src/mesa/main/shaderapi.c | 17 +++--
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 91eff55f84d..c20d8b80e1d 100644
--- a/src/mesa/main/dd.h
+++ b/src/
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_link.cpp | 9 ++---
src/mesa/drivers/dri/i965/brw_program.c | 12
src/mesa/drivers/dri/i965/brw_program.h | 3 +++
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_link.
Signed-off-by: Jordan Justen
---
src/mesa/main/get_hash_params.py | 2 +-
src/mesa/main/mtypes.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index acd5cd1f011..8c6193d761f 100644
--- a/src/mes
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_disk_cache.c | 31 --
src/mesa/drivers/dri/i965/brw_program.c| 16 +++
src/mesa/drivers/dri/i965/brw_program.h| 4
3 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/
It appears that we include the shader cache sources into libglsl
regardless.
The Meson build already does this.
Signed-off-by: Jordan Justen
---
src/compiler/Android.glsl.mk | 3 +--
src/compiler/Makefile.glsl.am | 3 +--
src/compiler/Makefile.sources | 6 ++
3 files changed, 4 insertions(
This will allow us to use the program serialization to implement
ARB_get_program_binary.
Signed-off-by: Jordan Justen
---
src/compiler/Makefile.sources |2 +
src/compiler/glsl/meson.build |2 +
src/compiler/glsl/serialize.cpp| 1238
src/
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_program.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index 39308f306df..809766574f8 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
Signed-off-by: Jordan Justen
---
src/util/Makefile.sources | 2 +
src/util/meson.build | 2 +
src/util/program_binary.c | 322 ++
src/util/program_binary.h | 91 +
4 files changed, 417 insertions(+)
create mode 100644 src/util/pro
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_program.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index 798b7d24dd6..f795fc1dbc3 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b
Signed-off-by: Jordan Justen
---
src/mesa/main/dd.h| 12
src/mesa/main/shaderapi.c | 8 +++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index da03b2e8b94..91eff55f84d 100644
--- a/src/mesa/main/dd.h
+++ b/src/me
The GL_ARB_get_program_binary extension spec says:
"If ProgramBinary fails to load a binary, no error is generated, but
any information about a previous link or load of that program object
is lost."
Signed-off-by: Jordan Justen
---
src/mesa/main/shaderapi.c | 2 ++
1 file changed, 2 insert
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_context.c| 9 ++
src/mesa/drivers/dri/i965/brw_context.h| 16 ++
src/mesa/drivers/dri/i965/brw_program_binary.c | 200 +
src/mesa/drive
The ARB_get_program_binary extension requires that uniform values in a
program be restored to their initial value just after linking.
This patch saves off the initial values just after linking. When the
program is restored by glProgramBinary, we can use this to copy the
initial value of uniforms i
Similar idea to Tim's "spec: MESA_program_binary", but simplified and
written to support both ARB_get_program_binary and
OES_get_program_binary.
Signed-off-by: Jordan Justen
Cc: Ian Romanick
Cc: Timothy Arceri
---
docs/specs/MESA_program_binary_formats.txt | 59 ++
Signed-off-by: Jordan Justen
---
include/GL/gl.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/GL/gl.h b/include/GL/gl.h
index 5b284802885..6ae8088f6cb 100644
--- a/include/GL/gl.h
+++ b/include/GL/gl.h
@@ -2101,6 +2101,14 @@ typedef void (APIENTRYP
PFNGLEGLIMAGETARGETRENDE
git://people.freedesktop.org/~jljusten/mesa i965-get-program-binary-v1
This series adds i965 support for ARB_get_program_binary with greater
than 0 supported formats. Today we support this extension, but
advertise support for 0 formats. This series allows i965 to advertise
support for 1 format.
T
On 11/08/2017 08:16 PM, Marek Olšák wrote:
From: Marek Olšák
For lower CPU cache usage. All enums fit within 2 bytes.
gl_context = 152400 -> 136824 bytes
Wow.
vbo_context = 22696 -> 21520 bytes
---
src/mesa/drivers/dri/nouveau/nv04_state_frag.c | 4 +-
src/mesa/drivers/dri/nouveau/nv1
From: Dave Airlie
This isn't needed in r600 anymore.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_query.c | 46 ++-
src/gallium/drivers/r600/r600_query.h | 4 ---
2 files changed, 13 insertions(+), 37 deletions(-)
diff --git a/src/gallium/drive
From: Aravindan Muthukumar
Reducing Bucket index calculation to O(1).
This algorithm calculates the index using matrix method.
Matrix arrangement is as below:
Assuming PAGE_SIZE is 4096.
1*4096 2*40963*40964*4096
5*4096 6*40967*40968*4096
10*409
On 9 November 2017 at 11:54, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds support for creating the hw atomic tgsi from
> the glsl codepaths.
>
> v2: drop the atomic index and move to backend.
> v3: drop buffer decls. (Marek)
> v4: fix off by one (Gert)
Found a bug in my fix for this one,
> On 11/06/2017 08:30 PM, aravindan.muthuku...@intel.com wrote:
> > From: Aravindan Muthukumar
> >
> > Now the complexity has been reduced to O(1)
> >
> > Algorithm calculates the index using matrix method.
> > Matrix arrangement is as below:
> > Assuming PAGE_SIZE is 4096.
> >
> > 1*409
On 11/08/2017 08:12 PM, Brian Paul wrote:
On 11/08/2017 06:28 PM, Ian Romanick wrote:
Any thoughts about my data using __attribute__((__packed__))?
Sorry, I didn't have time to dig into it. I took a look this evening.
I think the ENUM_8BIT idea will work for GCC and MSVC but only for C++
sou
From: Marek Olšák
we don't use dma_data in this codepath.
---
src/gallium/drivers/radeon/r600_buffer_common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index cdcd37b..2e
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 5 +
src/gallium/drivers/radeon/r600_pipe_common.h | 2 --
src/gallium/drivers/radeonsi/si_pipe.c | 3 ---
3 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_c
From: Marek Olšák
160 -> 136 bytes
---
src/gallium/drivers/radeon/r600_pipe_common.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 6b0a743..61560ac
From: Marek Olšák
1752 -> 1736 bytes
---
src/gallium/drivers/radeon/r600_pipe_common.h | 53 +--
1 file changed, 26 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 43b11262..
From: Marek Olšák
For lower CPU cache usage. All enums fit within 2 bytes.
gl_context = 152400 -> 136824 bytes
vbo_context = 22696 -> 21520 bytes
---
src/mesa/drivers/dri/nouveau/nv04_state_frag.c | 4 +-
src/mesa/drivers/dri/nouveau/nv10_state_frag.c | 4 +-
src/mesa/main/glheader.h
From: Marek Olšák
216 -> 160 bytes
---
src/gallium/drivers/radeon/r600_pipe_common.h | 37 ---
src/gallium/drivers/radeon/r600_texture.c | 3 ---
2 files changed, 11 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gal
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 2 --
src/gallium/drivers/radeon/r600_pipe_common.c | 2 --
src/gallium/drivers/radeon/r600_pipe_common.h | 1 -
3 files changed, 5 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/galliu
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.h | 2 --
src/gallium/drivers/radeon/r600_texture.c | 7 ---
2 files changed, 9 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 47306c6..48501
https://bugs.freedesktop.org/show_bug.cgi?id=103586
--- Comment #10 from Dave Gilbert ---
I believe I'm still seeing this:
dg@hath:~/ocl2$ clinfo
Number of platforms 1
Platform Name Clover
Platform Vendor
On 11/08/2017 06:28 PM, Ian Romanick wrote:
Any thoughts about my data using __attribute__((__packed__))?
Sorry, I didn't have time to dig into it. I took a look this evening.
I think the ENUM_8BIT idea will work for GCC and MSVC but only for C++
sources. MSVC doesn't like the sized enum sy
FWIW I'd really appreciate it if someone could shed some light on that
mystery bit there...
Roland
Am 09.11.2017 um 03:58 schrieb srol...@vmware.com:
> From: Roland Scheidegger
>
> I don't know what this bit really does. The docs are somewhere between
> misleading and wrong however, as at least
All on Juniper.
But anyway, I've got another solution, with the only drawback that I
don't really know what it does due to docs being lackluster/misleading
there :-).
But that would let us keep the ieee opcodes. And while I don't know what
it does, I suspect it's a better idea regardless ;-). hw s
Am 08.11.2017 um 07:18 schrieb Ilia Mirkin:
> tgsi_rsq appears to ignore the passed-in op and always puts in
> ALU_OP1_RECIPSQRT_CLAMPED anyways. It also sticks an absolute value on
> the RSQ() argument. This only happens for eg, not cayman. (Probably
> why only the rcp_clamped change appeared to b
From: Roland Scheidegger
I believe this is the safe thing to do, especially ever since the driver
actually generates NaNs for muls too.
Albeit since the radeon ISA docs are inaccurate/wrong there, I'm not
entirely sure what the non-dx10 versions do, but (as required by dx10)
the dx10 versions sho
From: Roland Scheidegger
Float rts were always set as unorm instead of float.
Not sure of the consequences, but at least it looks like the blend clamp
would have been enabled, which is against the rules (only eg really bothered
to even attempt to specify this correctly, r600 always used clamp any
From: Roland Scheidegger
I don't know what this bit really does. The docs are somewhere between
misleading and wrong however, as at least the newer ones (that bit exists with
GCN as well) imply all NaNs would get converted to zeros, which is definitely
NOT the case (and that would not be dx10 com
From: Roland Scheidegger
r600 used the clamped version for rcp, whereas both evergreen and cayman
used the ieee version. I don't know why that discrepancy exists (it does so
since day 1) but there does not seem to be a valid reason for this, so make
it consistent. This seems now safer than before
Just some naming trivia, not a proper review:
On Wed, Nov 8, 2017 at 8:54 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds support for a hw atomic counters to TGSI.
>
> A new register file for storing atomic counters is added,
> along with a new atomic counter semantic, along with docs
>
From: Dave Airlie
This adds a new atom that calls the new driver API to
bind buffers containing hw atomics.
v2: fixup bindings for sparse buffers. (mareko/nha)
don't bind buffer atomics when hw atomics are enabled.
use NewAtomicBuffer (mareko)
Signed-off-by: Dave Airlie
---
src/mesa/state_tra
From: Dave Airlie
This adds support for the evergreen/cayman atomic counters.
These are implemented using GDS append/consume counters. The values
for each counter are loaded before drawing and saved after each draw
using special CP packets.
v2: move hw atomic assignment into driver.
v3: fix mes
From: Dave Airlie
Signed-off-by: Dave Airlie
---
docs/features.txt | 6 +++---
docs/relnotes/17.4.0.html | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/docs/features.txt b/docs/features.txt
index 10ccf9d..86d07ba 100644
--- a/docs/features.txt
+++ b/docs/features.
From: Dave Airlie
HW atomics need to use caps to set some limits, and some
other limits may also need limiting.
This fixes things up to work for evergreen hw, it may need
more changes in the future if other hw wants to use this path.
v1.1: fix indent.
Reviewed-by: Nicolai Hähnle
Reviewed-by:
From: Dave Airlie
This API binds atomic buffers for all bound shaders (as per the
GL semantics).
This is needed to support cross shader hw atomic counters.
Reviewed-by: Nicolai Hähnle
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/gallium/docs/source/context.rst | 8
From: Dave Airlie
This adds support for creating the hw atomic tgsi from
the glsl codepaths.
v2: drop the atomic index and move to backend.
v3: drop buffer decls. (Marek)
v4: fix off by one (Gert)
Reviewed-by: Nicolai Hähnle
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/mesa/s
From: Dave Airlie
This adds support for a hw atomic counters to TGSI.
A new register file for storing atomic counters is added,
along with a new atomic counter semantic, along with docs
for both.
v2: drop semantic, move hw counter to backend,
Ilia pointed out SSO would have busted my plan, and
From: Dave Airlie
This is needed for the GLSL->TGSI translation for hw atomic counters.
Reviewed-by: Nicolai Hähnle
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/mesa/main/mtypes.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes
Hopefully last pass, a few fixes in here, patch 5 is the only
outstanding non-reviewed one, I think I've fixed the sparse
buffer binding in it well enough, there is also fix for Gert's
off-by one.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedeskt
From: Dave Airlie
This looks like an evergreen specific feature, but with atomic
counters AMD have hw specific counters they use instead of operating
on buffers directly. These are separate to the buffer atomics,
so require different limits and code paths.
I've left the CAP for atomic type exten
On 11/08/2017 09:08 AM, Erik Faye-Lund wrote:
> On Wed, Nov 8, 2017 at 1:07 AM, Brian Paul wrote:
>> Use the proper enum types for various variables. Makes life in gdb
>> a little nicer. Note that the size of enum bitfields must be one
>> larger so the high bit is always zero (for MSVC).
>
> Yo
Any thoughts about my data using __attribute__((__packed__))?
On 11/07/2017 04:07 PM, Brian Paul wrote:
> Declare glsl_type::sampled_type as glsl_base_type as we do for the
> base_type field. And make base_type a bitfield to save a few bytes.
>
> Update glsl_type constructor to take glsl_base_ty
Reviewed-by: Timothy Arceri
Mark may want to consider adding some of the once a day type CI runs for
this. For example running the test suite for two consecutive runs on the
same build so that the second run uses the shader cache and also a
second run the uses MESA_GLSL=cache_fb to force test
On 7 November 2017 at 20:45, Gert Wollny wrote:
> Am Dienstag, den 07.11.2017, 16:30 +1000 schrieb Dave Airlie:
>> This is the 3rd submission of the gallium/r600 hw atomic counter
>> support.
>>
>> This is fixes some rebase artifacts, removes the BUFFER decls from
>> the TGSI, and fixes some indir
Reviewed-by: Bas Nieuwenhuizen
On Thu, Nov 9, 2017 at 2:12 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This is derived from tgsi/radeonsi code from the GLSL intrinsics.
>
> This should pre-fix radv for the upcoming spirv patches.
>
> v2: actually use wait_cnt, sleep deprived dad time! (Bas)
From: Dave Airlie
This is derived from tgsi/radeonsi code from the GLSL intrinsics.
This should pre-fix radv for the upcoming spirv patches.
v2: actually use wait_cnt, sleep deprived dad time! (Bas)
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 32 +
On Thu, Nov 9, 2017 at 2:04 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This is derived from tgsi/radeonsi code from the GLSL intrinsics.
>
> This should pre-fix radv for the upcoming spirv patches.
>
> Signed-off-by: Dave Airlie
> ---
> src/amd/common/ac_nir_to_llvm.c | 32 +
From: Dave Airlie
This is derived from tgsi/radeonsi code from the GLSL intrinsics.
This should pre-fix radv for the upcoming spirv patches.
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
d
f9d5a7add42af5a2e4410526d1480a08f41317ae along with
a16dc04ad51c32e5c7d136e4dd6273d983385d3f appears to have fixed the one
known regression with shader cache. (Deus Ex instability.)
We should enable the shader cache by default to stabilize it before
the next major Mesa release.
Signed-off-by: Jor
State validation is performed during clear and draw calls. Validation
during clear was still accessing vertex buffer state. When the currently
set vertex buffers are client arrays, this could lead to accessing freed
memory. Such is the case with the VMD application.
Previously, vertex buffer va
https://bugs.freedesktop.org/show_bug.cgi?id=102891
--- Comment #6 from Dave Airlie ---
Did someone already try RADV_DEBUG=zerovram to see if it helps?
The trace replays badly on amdgpu-pro which suggests the bad stuff is in ram
before recording.
--
You are receiving this mail because:
You are
Ah yes you are right, my mistake. I will update the patch after some more
testing. Thx.
On 8 November 2017 at 17:21, Chris Wilson wrote:
> Quoting Julien Isorce (2017-11-08 16:55:05)
> > v2: add early return if (flag & MAP_INTERNAL_MASK)
> >
> > Already implemented for Gallium drivers.
> >
> > U
On Wed, Nov 8, 2017 at 3:42 PM, Chad Versace
wrote:
> On Wed 08 Nov 2017, Jason Ekstrand wrote:
> > On Wed, Nov 8, 2017 at 1:40 PM, Chad Versace <[1]
> chadvers...@chromium.org>
> > wrote:
> >
> > On Tue 07 Nov 2017, Dylan Baker wrote:
> > > Quoting Eric Engestrom (2017-11-07 07:25:53)
>
On Wed 08 Nov 2017, Jason Ekstrand wrote:
> On Wed, Nov 8, 2017 at 1:40 PM, Chad Versace <[1]chadvers...@chromium.org>
> wrote:
>
> On Tue 07 Nov 2017, Dylan Baker wrote:
> > Quoting Eric Engestrom (2017-11-07 07:25:53)
> > > On Wednesday, 2017-11-01 13:49:03 -0700, Chad Versace wrote:
Hello list,
The candidate for the Mesa 17.2.5 is now available. Currently we have:
- 30 queued
- 16 nominated (outstanding)
- and 3 rejected patches
In the current queue we have:
In Mesa Core a GL error related to the ARB_ES3_1_compatibility spec
noticed with the GFXBench 5 Aztec Ruins has b
The setTexBuffer2 hook from GLX is used to implement glxBindTexImageEXT
which has tighter restrictions than just "it's shared". In particular,
it says that any rendering to the image while it is bound causes the
contents to become undefined.
The GLX_EXT_texture_from_pixmap extension provides us w
The old code made a new miptree that referenced the same BO as the
renderbuffer and just trusted in the memory aliasing to work. There are
only two ways in which the new miptree is liable to differ from the one
in the renderbuffer and neither of them matter:
1) It may have a different target. T
Cc: "17.3"
---
src/mesa/drivers/dri/i965/intel_tex_image.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index c52992a..28800f6 100644
--- a/src/mesa/drivers/dri/i96
This function is used to determine when we need to re-allocate a
miptree. Since we do nothing different in miptree allocation for
sRGB vs. linear, loosening this should be safe and may lead to less
copying and reallocating in some odd cases.
Cc: "17.3"
Cc: Kenneth Graunke
---
src/mesa/drivers/
Dylan Baker writes:
> [ Unknown signature status ]
> Quoting Eric Anholt (2017-11-08 14:14:57)
>> ---
>> meson.build | 5 +++--
>> src/gallium/drivers/vc4/meson.build | 13 +
>> 2 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/meson.build
On 09/11/17 09:14, Eric Anholt wrote:
Timothy Arceri noted that vc4 didn't seem to have the NEON stuff
hooked up, so I worked on getting vc4 cross builds working for me
finally. I haven't tested the result on HW quite yet.
I can now build vc4 with asm enable with this series so:
Tested-by: Ti
https://bugs.freedesktop.org/show_bug.cgi?id=103586
--- Comment #9 from Dave Gilbert ---
(In reply to Jan Vesely from comment #8)
> (In reply to Dave Gilbert from comment #6)
> > (In reply to Jan Vesely from comment #5)
> > > (In reply to Dave Gilbert from comment #4)
> > > > Created attachment 1
Adam Jackson writes:
> This should be safe as these backends already support the EGL version of
> this extension. DRI1 is not affected because it does not support
> GLX_ARB_create_context anyway. DRI-Windows is not prepared to implement
> this as there's no equivalent WGL extension, and wglCreate
On Wed, Nov 8, 2017 at 4:13 AM, Nicolai Hähnle wrote:
> On 08.11.2017 09:53, Michel Dänzer wrote:
>>
>> On 07/11/17 10:58 PM, Marek Olšák wrote:
>>>
>>> On Tue, Nov 7, 2017 at 9:01 PM, Nicolai Hähnle
>>> wrote:
On 07.11.2017 18:35, Michel Dänzer wrote:
>
>
> On 07/11/17 06:2
Nicolai Hähnle writes:
> On 08.11.2017 09:53, Michel Dänzer wrote:
>> On 07/11/17 10:58 PM, Marek Olšák wrote:
>>> On Tue, Nov 7, 2017 at 9:01 PM, Nicolai Hähnle wrote:
On 07.11.2017 18:35, Michel Dänzer wrote:
>
> On 07/11/17 06:28 PM, Marek Olšák wrote:
>>
>> Hi,
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=103586
--- Comment #8 from Jan Vesely ---
(In reply to Dave Gilbert from comment #6)
> (In reply to Jan Vesely from comment #5)
> > (In reply to Dave Gilbert from comment #4)
> > > Created attachment 135313 [details]
> > > foo.link-0.ll
> > >
> > > Th
Quoting Eric Anholt (2017-11-08 14:14:57)
> ---
> meson.build | 5 +++--
> src/gallium/drivers/vc4/meson.build | 13 +
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0118c9a7c5ef..189c9be5b59c 100644
> --
It was fixed in 5c2ff5773a707519f6a773126f201c4e1e8a42d7.
---
meson.build | 1 -
1 file changed, 1 deletion(-)
diff --git a/meson.build b/meson.build
index 117ed7c087f4..0118c9a7c5ef 100644
--- a/meson.build
+++ b/meson.build
@@ -691,7 +691,6 @@ if with_glvnd
pre_args += '-DUSE_LIBGLVND=1'
en
Timothy Arceri noted that vc4 didn't seem to have the NEON stuff
hooked up, so I worked on getting vc4 cross builds working for me
finally. I haven't tested the result on HW quite yet.
Eric Anholt (4):
meson: Leave dep_llvm empty if !with_llvm
meson: Drop stale comment about making valgrind c
The gallium auxiliary build would link against llvm, for the gallivm code
that it didn't build. This broke the build on my armhf cross, where
libLLVM-3.9.so is not multiarch and thus points to x86-64 libs.
---
meson.build | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/
---
meson.build | 5 +++--
src/gallium/drivers/vc4/meson.build | 13 +
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 0118c9a7c5ef..189c9be5b59c 100644
--- a/meson.build
+++ b/meson.build
@@ -485,8 +485,9 @@ endi
Somehow on my cross build the -pthread is getting lost. All the other
deps seem to work out fine.
---
src/gallium/targets/dri/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/targets/dri/meson.build
b/src/gallium/targets/dri/meson.build
index 0ce088e1aca6..c591b75d0379
Hi Emil,
Emil Velikov writes:
> On 27 October 2017 at 05:54, Harish Krupo wrote:
>> Hi Eric,
>>
>> Eric Engestrom writes:
>>
>>> On Monday, 2017-10-23 16:20:54 +0530, Harish Krupo wrote:
This passes 33/37 deqp tests related to partial_update, 4 are not
supported. Tests not supported:
Quoting Eric Engestrom (2017-11-08 12:38:26)
>
>
> On 8 November 2017 19:32:22 GMT, Dylan Baker wrote:
> > Quoting Eric Engestrom (2017-11-08 04:21:41)
> > > On Wednesday, 2017-11-01 11:58:16 -0700, Dylan Baker wrote:
> > > > Meson has up until this point set it's version in the root
> > meson.b
On Wed, Nov 8, 2017 at 1:40 PM, Chad Versace
wrote:
> On Tue 07 Nov 2017, Dylan Baker wrote:
> > Quoting Eric Engestrom (2017-11-07 07:25:53)
> > > On Wednesday, 2017-11-01 13:49:03 -0700, Chad Versace wrote:
> > > > I tested this in a setup where the builddir was outside of the
> srcdir.
> > > >
On Tue 07 Nov 2017, Jason Ekstrand wrote:
> All of the pre-work patches have been reviewed by myself and Lionel. I've
> also
> read through the rest of the series and things look pretty good to me. I did
> make some scattered comments but they shouldn't be a big deal.
>
> My primary concern wit
Hi Emil,
Emil Velikov writes:
> Hi Harish,
>
> This seems to have fallen through the cracks, right?
Thanks for bringing this up again :)
> Keep in mind that I've not checked all the existing code paths - just
> skimming through the patch itself.
>
> s/Adding support for EXT_sRGB for Opengl ES/m
On Tue 07 Nov 2017, Dylan Baker wrote:
> Quoting Eric Engestrom (2017-11-07 07:25:53)
> > On Wednesday, 2017-11-01 13:49:03 -0700, Chad Versace wrote:
> > > I tested this in a setup where the builddir was outside of the srcdir.
> > > ---
> > > src/intel/vulkan/meson.build | 12
> > >
Dylan Baker writes:
> Signed-off-by: Dylan Baker
> ---
> meson.build | 16 +++---
> src/gallium/meson.build | 11 +++-
> src/gallium/state_trackers/glx/xlib/meson.build | 27 ++
> src/gallium/targets/libgl-xlib/meson.build
https://bugs.freedesktop.org/show_bug.cgi?id=103586
--- Comment #7 from Jan Vesely ---
Created attachment 135318
--> https://bugs.freedesktop.org/attachment.cgi?id=135318&action=edit
annotated asm dump
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=103586
--- Comment #6 from Dave Gilbert ---
(In reply to Jan Vesely from comment #5)
> (In reply to Dave Gilbert from comment #4)
> > Created attachment 135313 [details]
> > foo.link-0.ll
> >
> > That's all 3 of the debug files it produced.
> > (I was
https://bugs.freedesktop.org/show_bug.cgi?id=103586
--- Comment #5 from Jan Vesely ---
(In reply to Dave Gilbert from comment #4)
> Created attachment 135313 [details]
> foo.link-0.ll
>
> That's all 3 of the debug files it produced.
> (I wasn't sure which were the llvm and which the isa dumps; I
On 8 November 2017 19:32:22 GMT, Dylan Baker wrote:
> Quoting Eric Engestrom (2017-11-08 04:21:41)
> > On Wednesday, 2017-11-01 11:58:16 -0700, Dylan Baker wrote:
> > > Meson has up until this point set it's version in the root
> meson.build
> > > script. While there are other build systems them
Am 08.11.2017 um 19:08 schrieb boyuan.zh...@amd.com:
From: Boyuan Zhang
Add a new header file for vcn encode interface
Signed-off-by: Boyuan Zhang
Only briefly skimmed over it, but what I saw looks mostly sane.
Maybe nice to have is to have the code for encoding of the SPS/PPS and
slice h
Quoting Ian Romanick (2017-11-08 11:05:24)
> On 11/08/2017 10:59 AM, Ian Romanick wrote:
> > Is there a way to get a list of options before having any success? I
> > want to disable using LLVM, but I can't get the list of options to do so
> > because I don't have libelf (required for LLVM... which
1 - 100 of 177 matches
Mail list logo