From: Nicolai Hähnle
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103128
Fixes: cad959d90145 ("gallium: add LDEXP TGSI instruction and corresponding
cap")
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
cannot be built without it (Because of LLVM). As far as I can tell the GLSL
compiler and the Intel Compiler are the only C++ code in mesa not using C++11.
Quoting Kai Wasserbäch (2017-11-15 08:45:30)
> Doesn't the
Quoting Ilia Mirkin (2017-11-15 09:52:06)
> On Wed, Nov 15, 2017 at 12:47 PM, Dylan Baker wrote:
> > Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
> > cannot be built without it (Because of LLVM). As far as I can tell the GLSL
> > compiler and
On 15.11.2017 17:45, Kai Wasserbäch wrote:
Doesn't the meson.build file need the same change?
I don't really know Meson, but the master build file looks to me like
Meson always builds with C++11.
Cheers,
Nicolai
Nicolai Hähnle wrote on 15.11.2017 12:55:
From: Nicolai Hähnle
Quoting Nicolai Hähnle (2017-11-15 06:35:49)
> From: Nicolai Hähnle
>
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
>
> Cc: Jon Turney
> Cc: Rob Herring
> Cc: Alexander von Gluck IV
>
https://bugs.freedesktop.org/show_bug.cgi?id=103128
--- Comment #2 from Nicolai Hähnle ---
https://patchwork.freedesktop.org/patch/188544/ fixes this for me.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
"Mun, Gwan-gyeong" writes:
> Hi all,
>
> I am sorry that I didn't have enough discussion about why new window
> system code is needed for Tizen on mesa.
>
> This is a brief architecture of Tizen Window System.
>
>
>
On Tue, 2017-11-14 at 11:28 -0800, Matt Turner wrote:
> On Tue, Nov 14, 2017 at 6:37 AM, Emil Velikov
> wrote:
> > The fourth release candidate for Mesa 17.3.0 is now available.
> >
> > As per the issue tracker [1] we still have a number of outstanding bugs
> >
Quoting Jon Turney (2017-11-15 02:52:29)
> I'm not sure of the reason for this. I don't see anything like this in
> configure.ac
I hadn't had a chance to test other platforms, and I wasn't sure about Windows
and Haiku. Some of the BSD's also stiil use pthread-stubs, and I don't think
those get
Hi Wladimir,
Am Mittwoch, den 15.11.2017, 18:03 +0100 schrieb Wladimir J. van der Laan:
> A recent commit (see below) fixed flat shading but at the same time
> broke the use of point sprites with multiple varyings. This resulted in
> particle systems rendering wrongly.
>
> The reason for this is
Reviewed-by: Dylan Baker
Quoting Rafael Antognolli (2017-11-15 09:32:47)
> Xorg (and possibly other things) depend on this variable to find the
> path to DRI drivers.
>
> Signed-off-by: Rafael Antognolli
> Cc: Dylan Baker
On Wed, Nov 15, 2017 at 12:47 PM, Dylan Baker wrote:
> Nope. meson builds all C++ code as C++11 because so much of mesa's C++ code
> cannot be built without it (Because of LLVM). As far as I can tell the GLSL
> compiler and the Intel Compiler are the only C++ code in mesa not
> Sorry for noticing before, but this breaks glmark2 texture. I didn't
> yet dig into the issue but it's definitely caused by this commit.
>
> To reproduce, simply run
> glmark2-es2-drm -b texture:texture-filter=mipmap
That's weird, as that neither uses point sprites nor flat shading.
I'll have
On 2017-11-14 07:37:27, Emil Velikov wrote:
> On 10 November 2017 at 23:39, Jordan Justen wrote:
> > On 2017-11-10 08:19:38, Emil Velikov wrote:
> >> On 7 November 2017 at 11:54, Emil Velikov wrote:
> >> > From: Emil Velikov
On 15 November 2017 at 19:30, Jordan Justen wrote:
> On 2017-11-14 07:37:27, Emil Velikov wrote:
>> On 10 November 2017 at 23:39, Jordan Justen
>> wrote:
>> > On 2017-11-10 08:19:38, Emil Velikov wrote:
>> >> On 7 November 2017 at 11:54,
Reviewed-by: Brian Paul
On 11/15/2017 11:35 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Bugzilla:
On 15/11/2017 14:35, Nicolai Hähnle wrote:
From: Nicolai Hähnle
v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
Cc: Jon Turney
Cc: Rob Herring
Cc: Alexander von Gluck IV
Bugzilla:
Hi Mesa-Devel,
Today we're happy to announce that we're making the LunarG driver
testing system available to the Mesa development community. We've been
using this system internally for quite some time, but we've recently
done some more work so the results could also be publicly available for
the
From: Nicolai Hähnle
Tested with Travis and Appveyor.
v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
v3: use check_functions in Scons (Eric)
Cc: Rob Herring
Cc: Alexander von Gluck IV
Bugzilla:
On Wednesday, 2017-11-15 16:51:29 +, Kai Wasserbäch wrote:
> I'm still good with this, thanks for reapplying!
To be clear, is that an ack, or an r-b? :P
>
> Eric Engestrom wrote on 14.11.2017 18:26:
> > This is a revert of Marek's 2cb9ab53dd3ae6850a26 revert.
> > It was needed to revert the
On 15 November 2017 at 04:40, Jason Ekstrand wrote:
> This commit significantly reworks the way prime support works and lets
> us pull it even further into radv. The old mechanism required the
> specific WSI layer to be aware of the linear shadow copy that has to be
> done
From: Dave Airlie
We ignore layout currently, not sure what would be correct to pass.
(this is based on Jason's last wsi rfc)
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_meta.h | 4
src/amd/vulkan/radv_meta_copy.c | 20
On 2017-11-15 08:35, Nicolai Hähnle wrote:
From: Nicolai Hähnle
v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
Cc: Jon Turney
Cc: Rob Herring
Cc: Alexander von Gluck IV
Bugzilla:
This should make scons work correctly on every platform, so:
Reviewed-by: Dylan Baker
Quoting Nicolai Hähnle (2017-11-15 12:58:12)
> From: Nicolai Hähnle
>
> Tested with Travis and Appveyor.
>
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons
https://bugs.freedesktop.org/show_bug.cgi?id=100151
--- Comment #12 from Pradeep Yadav ---
As I mentioned while filing this defect that Mesa's classic software rasterizer
has no such black window issue. So we have potential temporary solution for our
customers who are
From: Dave Airlie
This just seems cleaner, and we may expand this in future.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_wsi.c | 3 ++-
src/intel/vulkan/anv_wsi.c | 3 ++-
src/vulkan/wsi/wsi_common.h | 4 +---
From: Dave Airlie
This just uses the vulkan api to get the fd from the memory.
Signed-off-by: Dave Airlie
---
src/amd/vulkan/radv_wsi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/amd/vulkan/radv_wsi.c
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> Resources only need a resolve-to-itself if their TS is valid for any
> level, not just if it happens to be allocated.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
This looks at prog->*. You don't get to do that unless you listen to
BRW_NEW_*_PROGRAM, which is a superset of the cases where
BRW_NEW_*_PROG_DATA is flagged.
---
src/mesa/drivers/dri/i965/gen7_l3_state.c | 5 +
1 file changed, 5 insertions(+)
diff --git
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> Sampler TS introduces yet another format enumeration for
> renderable+textureable formats. Introduce it into the etnaviv_format
> table as another column.
>
> Signed-off-by: Wladimir J. van der Laan
2017-11-14 10:21 GMT+01:00 Wladimir J. van der Laan :
> This is to make sure that the TS is properly flushed to memory before
> rendering to a new surface starts.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Christian Gmeiner
On Wed, Nov 15, 2017 at 5:49 PM, Nanley Chery wrote:
> On Wed, Nov 15, 2017 at 12:08:58PM -0500, Ilia Mirkin wrote:
>> On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
>> wrote:
>> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
>> >
>> >
On Wednesday, 2017-11-15 20:59:18 +, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Tested with Travis and Appveyor.
>
> v2: add HAVE_TIMESPEC_GET for non-Windows Scons builds
> v3: use check_functions in Scons (Eric)
>
> Cc: Rob Herring
> Cc:
On Wed, Nov 15, 2017 at 12:08:58PM -0500, Ilia Mirkin wrote:
> On Wed, Nov 15, 2017 at 11:54 AM, Juan A. Suarez Romero
> wrote:
> > From section 8.7, page 179 of OpenGL ES 3.2 spec:
> >
> > An INVALID_OPERATION error is generated by CompressedTexImage3D
> > if
Hi,
I do not know if anyone has noticed or if it is deliberate, but the meson
builds have that assert()'s are active but the autotools release builds have
that assert() is inactive.
-Kevin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Build mesa 6164 completed
Commit 059d25a06d by Samuel Pitoiset on 11/14/2017 4:27 PM:
radv: add the vertex buffers BO to the list at bind time\n\nThis should reduce the overhead of adding a BO to the current\nlist, especially when the list is huge. Also, when
https://bugs.freedesktop.org/show_bug.cgi?id=102122
Vinson Lee changed:
What|Removed |Added
Blocks||103491
Referenced
https://bugs.freedesktop.org/show_bug.cgi?id=103128
Vinson Lee changed:
What|Removed |Added
Blocks||103491
Referenced
Am Mittwoch, den 15.11.2017, 11:28 +1000 schrieb Dave Airlie:
>
> I'll likely apply this as well at some point, that test however hangs
> my cayman with or without my patch (and your patch doesn't do
> anything on cayman).
BTW: valgrind showed that there was some problem in sb in the parser
Hi Dave,
Am Dienstag, 14. November 2017, 23:28:38 CET schrieb Dave Airlie:
> From: Dave Airlie
>
> A lot of cubemap array piglits fail, port the texture type
> picking code from radeonsi which seems to fix most of them.
>
> For images I will port the rest of the code.
>
>
Pre-load all the LDS values who's range is accessed more than once.
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_shader.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
Cache values that are loaded more then once, or where various components
are loaded at separate places. This saves repeated calculation of the offsets.
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_shader.c | 211 +
1 file
Some offsets used for the LDS access are recalculated quite regularly.
Since tesselation shaders are not optimized by the SB manually pre-evaluate
some offsets to speed up this type of shader.
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_shader.c | 253
- fix a number of -Wsign-compare warnings
- fix two warnings for -Woverride-init because TGSI_OPCODE_CEIL == 83, and
the according field was defined two times.
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_shader.c | 67 ++
Use the destination write mask to determine which values are really to be
read from LDS and load only these.
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_shader.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff
Instead of calculating creating the code for calculating a base offset
and then to caclucate the component offfsets, calculate this offset
for all components directly. This saves one instruction group.
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_shader.c |
Dear all,
since on r600 the tesselation shaders don't go through the sb-optimizer I
though it might help to improve performance by applying some optimizations
to the created assembly. The patches are experimental but to a point where
I think some input from you could be helpful.
This patch
I have just seen that I have had an epic brain lapse on this.
The code is pretty clear, the correct value of count should be ann_count - i.
This is because:
a. The value of ann_count is the value of the array size BEFORE the insert;
this is clear from the code within the if (offset + ..)
https://bugs.freedesktop.org/show_bug.cgi?id=103699
--- Comment #8 from Tapani Pälli ---
(also please try again with latest mesa)
--
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
For checking that bitfields are large enough to hold the largest
expected value.
v2: move into existing util/macros.h header where STATIC_ASSERT() lives.
---
src/util/macros.h | 16
1 file changed, 16 insertions(+)
diff --git a/src/util/macros.h b/src/util/macros.h
index
This was left out of c980a3aa3133
---
src/mesa/state_tracker/st_program.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index 97b2e1234b..dc81a17289 100644
---
Quoting Timothy Arceri (2017-11-15 16:16:10)
> This was left out of c980a3aa3133
> ---
> src/mesa/state_tracker/st_program.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_program.c
> b/src/mesa/state_tracker/st_program.c
> index
On 16/11/17 00:22, Eduardo Lima Mitev wrote:
This will be used by the linker code to dfferentiate between
programs made out of SPIR-V or GLSL shaders.
So far everywhere this is used it seems you could just do something like:
if (shProg->_LinkedShaders[stage]->spirv_data)
... spriv stuff
These are all either done already, or are autotools specific. The
misspelled gallium G3DVL is the autotools specific bit, meson is
handling that via build_by_default.
Signed-off-by: Dylan Baker
---
meson.build | 15 ---
1 file changed, 15 deletions(-)
diff
This patch allows building asm for x86 on x86_64 platforms, when the
operating system is the same. Previously cross compile always turned off
assembly. This allows using a cross file to cross compile x86 binaries
on x86_64 with asm.
This could probably be relaxed further thanks to meson's
This patch checks for an and then enables sse4.1 optimizations if the
host machine will be x86/x86_64.
Signed-off-by: Dylan Baker
---
meson.build | 27 ++-
src/mesa/meson.build | 14 +++---
2 files changed, 37 insertions(+), 4
This function is required for both the Intel "Anvil" vulkan driver and
the i965 GL driver. Error out if either of those is enabled but this
function isn't found.
Signed-off-by: Dylan Baker
---
meson.build | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
https://bugs.freedesktop.org/show_bug.cgi?id=103412
Brian Paul changed:
What|Removed |Added
Resolution|--- |FIXED
Folks,
If you have feedback or questions, you can mail them to i...@lunarg.com
Karen Ghavam
CEO and Engineering Director
LunarG, Inc. - 3D Graphics Software Innovations
ka...@lunarg.com
970-988-9043
On Wed, Nov 15, 2017 at 1:32 PM, Pierre-Loup A. Griffais <
pgriff...@valvesoftware.com> wrote:
On 16/11/17 00:22, Eduardo Lima Mitev wrote:
From: Nicolai Hähnle
---
src/mesa/main/mtypes.h| 1 +
src/mesa/main/shaderapi.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 1c953b83155..cfc763f043e
https://bugs.freedesktop.org/show_bug.cgi?id=103757
--- Comment #10 from Pekka Paalanen ---
(In reply to Michael Olbrich from comment #9)
> (In reply to Pekka Paalanen from comment #1)
> > Any reason you cannot use EGL_KHR_platform_wayland?
>
> It's not my code. It's
https://bugs.freedesktop.org/show_bug.cgi?id=103699
--- Comment #11 from Tapani Pälli ---
Created attachment 135512
--> https://bugs.freedesktop.org/attachment.cgi?id=135512=edit
test case
Could you please compile and run this test application and attach what is
prints? Does
We currently handle this by lowering it to a uniform for gen8+ but
the SPIR-V path generates this as a system value, so handle that
case as well.
---
src/mesa/drivers/dri/i965/brw_tcs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c
This intrinsic is produced to load SYSTEM_VALUE_VERTICES_IN, which is
generated to load gl_PatchVerticesIn in the SPIR-V path for both
Vulkan and OpenGL.
---
src/compiler/nir/nir_gather_info.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/nir/nir_gather_info.c
On Wed, Nov 15, 2017 at 5:10 PM, Dylan Baker wrote:
> This patch checks for an and then enables sse4.1 optimizations if the
> host machine will be x86/x86_64.
There's some stack realignment stuff that probably needs to stay, but
depending on what gcc version we require we
https://bugs.freedesktop.org/show_bug.cgi?id=103586
--- Comment #14 from Jan Vesely ---
(In reply to Dave Gilbert from comment #12)
>
> It doesn't seem to help, if I add:
> --- a/ocl.cpp
> +++ b/ocl.cpp
> @@ -74,6 +74,7 @@ static int got_dev(cl::Platform ,
> std::vector
https://bugs.freedesktop.org/show_bug.cgi?id=103128
Nicolai Hähnle changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=103674
Nicolai Hähnle changed:
What|Removed |Added
Status|NEW |RESOLVED
while timespec_get() is supposed to hide OS differences, compatibility doesn't
cover old OSes (like CentOS 6) where timespec_get() does not exist.
Fall back to using os_get_time_nano(), but separate out the functionality
that populates struct timespec, so it can also be called from
On Tuesday, 2017-11-14 17:57:38 -0800, Dylan Baker wrote:
> I think "suffix" would be better for the title "name". Also, library ->
> libraries.
>
> With that changed:
> Reviewed-by: Dylan Baker
Reviewed-by: Eric Engestrom
>
> Quoting Vinson
I could post a remark on AppVeyor's forums, but it sounds from the logs the
issue could be on our (freedesktop.org's) side.
I've reconfigured AppVeyor to use
https://anongit.freedesktop.org/git/mesa/mesa.git/ instead of
git://anongit.freedesktop.org/mesa/mesa . Perhaps fewer things can go
I'm not sure of the reason for this. I don't see anything like this in
configure.ac
In include/c11/threads.h the cases are:
1) building for Windows -> threads_win32.h
2) HAVE_PTHREAD -> threads_posix.h
3) Not supported on this platform
So not defining HAVE_PTHREAD for anything not Windows just
On 14.11.2017 06:18, Dave Airlie wrote:
From: Dave Airlie
If the TCS doesn't read back the outputs, no need to store them
to LDS in the first place. (except for tess factors).
This seems to give about 50fps (3290->3330) with tessellation demo.
I haven't tested if it
On 15/11/17 22:06, Nicolai Hähnle wrote:
On 10.11.2017 04:13, Timothy Arceri wrote:
The support is still WIP but the patches as starting to pile
up so thought I'd see if I could land these before continuing.
Thanks for working on this!
Whats missing?
Vega support for gs_vtx_offset
On 14.11.2017 06:18, Dave Airlie wrote:
From: Dave Airlie
This is to be used for TCS optimisations on radv.
---
src/compiler/nir/nir_gather_info.c | 29 ++---
src/compiler/shader_info.h | 2 ++
2 files changed, 24 insertions(+), 7
On 15.11.2017 12:30, Jon Turney wrote:
On 15/11/2017 11:21, Nicolai Hähnle wrote:
On 13.11.2017 23:55, Rob Herring wrote:
On Fri, Nov 10, 2017 at 12:39 PM, Jon Turney
wrote:
On 10/11/2017 15:42, Nicolai Hähnle wrote:
On 10.11.2017 14:00, Jon Turney wrote:
On
Am Mittwoch, den 15.11.2017, 10:11 +1000 schrieb Dave Airlie:
>
> It's not 100% on piglits, but it's quite close, and better than fglrx
> does, so I'd probably prefer to land it before doing too much more
> destructive hacking on it!
I ran the piglits shader set on barts - no regressions, and
On 10.11.2017 04:13, Timothy Arceri wrote:
The support is still WIP but the patches as starting to pile
up so thought I'd see if I could land these before continuing.
Thanks for working on this!
Whats missing?
Vega support for gs_vtx_offset handling (see patch 3), I don't
have one yet for
On 15/11/17 21:56, Nicolai Hähnle wrote:
On 10.11.2017 04:13, Timothy Arceri wrote:
---
src/amd/common/ac_nir_to_llvm.c | 24
-
src/amd/common/ac_shader_abi.h | 7 ++
src/gallium/drivers/radeonsi/si_shader.c | 1 +
This allows to update them with only one memcpy().
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_descriptor_set.c | 9 +
src/amd/vulkan/radv_image.c | 5 +
src/amd/vulkan/radv_private.h| 6 ++
3 files changed, 8 insertions(+),
On 13.11.2017 23:55, Rob Herring wrote:
On Fri, Nov 10, 2017 at 12:39 PM, Jon Turney
wrote:
On 10/11/2017 15:42, Nicolai Hähnle wrote:
On 10.11.2017 14:00, Jon Turney wrote:
On 09/11/2017 21:41, Nicolai Hähnle wrote:
Sorry for the mess.
I'm going to
v2: make use of existing si_tgsi_emit_epilogue()
---
src/gallium/drivers/radeonsi/si_shader.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index
https://bugs.freedesktop.org/show_bug.cgi?id=103658
--- Comment #3 from Nicolai Hähnle ---
Created attachment 135484
--> https://bugs.freedesktop.org/attachment.cgi?id=135484=edit
build addrlib with C++11
Does the attached patch help?
--
You are receiving this mail
From: Nicolai Hähnle
It is required for LLVM anyway.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
---
src/amd/Makefile.addrlib.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: Nicolai Hähnle
Cc: Jon Turney
Cc: Rob Herring
Cc: Alexander von Gluck IV
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103674
Fixes: f1a364878431 ("threads: update for late C11
From: Nicolai Hähnle
We need to account for SGPR locations in merged shaders.
This case is exercised by KHR-GL45.enhanced_layouts.vertex_attrib_locations
Fixes: 79c2e7388c7f ("radeonsi/gfx9: use SPI_SHADER_USER_DATA_COMMON")
---
I thought I sent a Rb on this one...
Reviewed-by: Lionel Landwerlin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Not sure if it's just my client, but all the nice ASCII art got messed
up unfortunately :/
On 14.11.2017 21:21, Mun, Gwan-gyeong wrote:
+--+
| [Tizen Window
On 10.11.2017 04:13, Timothy Arceri wrote:
This is too simple and breaks gs and I'm not sure its required there
anyway.
Can you add an example for what breaks?
Thanks,
Nicolai
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
On 15/11/17 21:39, Nicolai Hähnle wrote:
On 10.11.2017 04:13, Timothy Arceri wrote:
This is too simple and breaks gs and I'm not sure its required there
anyway.
Can you add an example for what breaks?
It breaks because it removes the outer array on gs inputs.
I have an updated series which
v2: make use of existing si_tgsi_emit_epilogue()
---
src/gallium/drivers/radeonsi/si_shader.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index
v2: add emit_gs_epilogue() helper function to reduce duplication.
---
src/gallium/drivers/radeonsi/si_shader.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index
As per the spec, the query identified by queryPool and query
must currently be active. Applications have to call vkCmdBeginQuery()
before, and thus the query pool BO will already be in the list.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_query.c | 4 +++-
On 10.11.2017 04:13, Timothy Arceri wrote:
---
src/amd/common/ac_nir_to_llvm.c | 24 -
src/amd/common/ac_shader_abi.h| 7 ++
src/gallium/drivers/radeonsi/si_shader.c | 1 +
On 15.11.2017 12:09, Timothy Arceri wrote:
On 15/11/17 21:56, Nicolai Hähnle wrote:
On 10.11.2017 04:13, Timothy Arceri wrote:
---
src/amd/common/ac_nir_to_llvm.c | 24
-
src/amd/common/ac_shader_abi.h | 7 ++
On 15/11/17 22:17, Nicolai Hähnle wrote:
On 15.11.2017 12:09, Timothy Arceri wrote:
On 15/11/17 21:56, Nicolai Hähnle wrote:
On 10.11.2017 04:13, Timothy Arceri wrote:
---
src/amd/common/ac_nir_to_llvm.c | 24
-
src/amd/common/ac_shader_abi.h
On 15/11/2017 11:21, Nicolai Hähnle wrote:
On 13.11.2017 23:55, Rob Herring wrote:
On Fri, Nov 10, 2017 at 12:39 PM, Jon Turney
wrote:
On 10/11/2017 15:42, Nicolai Hähnle wrote:
On 10.11.2017 14:00, Jon Turney wrote:
On 09/11/2017 21:41, Nicolai Hähnle wrote:
On Wednesday, 2017-11-15 09:43:59 +, Rogovin, Kevin wrote:
> Hi,
>
> I do not know if anyone has noticed or if it is deliberate, but the meson
> builds have that assert()'s are active but the autotools release builds have
> that assert() is inactive.
Hi,
Yep, this is by design, meson
Am Dienstag, den 14.11.2017, 10:21 +0100 schrieb Wladimir J. van der
Laan:
> Resources only need a resolve-to-itself if their TS is valid for any
> level, not just if it happens to be allocated.
>
> Signed-off-by: Wladimir J. van der Laan
Reviewed-by: Lucas Stach
Hi!
> Are you using the amdgpu kernel driver from an amdgpu-pro release or
> from the upstream Linux kernel? (If you're not sure, provide the dmesg
> output and Xorg log file)
> If the latter, can you try a 4.13 or 4.14 kernel and see if that works
> better?
I'm using upstream Linux kernel
1 - 100 of 176 matches
Mail list logo