No changes to shader-db expected.
---
src/gallium/drivers/freedreno/ir3/ir3_nir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/freedreno/ir3/ir3_nir.c
b/src/gallium/drivers/freedreno/ir3/ir3_nir.c
index db1d74fdee7..d5f42f2a231 100644
---
Also tests for removal of redundant loads, that we currently handle as
part of the copy propagation.
---
src/compiler/nir/tests/vars_tests.cpp | 300 ++
1 file changed, 300 insertions(+)
diff --git a/src/compiler/nir/tests/vars_tests.cpp
These are covered by another pass now.
---
src/compiler/nir/nir_opt_copy_prop_vars.c | 84 +++
1 file changed, 8 insertions(+), 76 deletions(-)
diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c
b/src/compiler/nir/nir_opt_copy_prop_vars.c
index 9fecaf0eeec..5276aa176d8
Extend the pass to propagate the copies information along the control
flow graph. It performs two walks, first it collects the vars
that were written inside each node. Then it walks applying the copy
propagation using a list of copies previously available. At each node
the list is invalidated
No changes to shader-db.
---
src/intel/compiler/brw_nir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index b38c3ba383d..77938efae31 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -553,6 +553,7 @@
Instead of doing this as part of the existing copy_prop_vars pass.
Separation makes easier to expand the scope of both passes to be more
than per-block. For copy propagation, the information about valid
copies comes from previous instructions; while the dead write removal
depends on information
Calls are not used yet (functions are inlined), but since new code is
already taking them into account, do it here too. The convention here
and in other places is that no writable memory is assumed to remain
unchanged, as well as global variables.
Also, explicitly state the modes affected
---
I've ended up not using this macro in this series, but it is useful
for other cases, so kept it here.
src/util/u_dynarray.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/util/u_dynarray.h b/src/util/u_dynarray.h
index f74bfc7080b..53dde9241bb 100644
--- a/src/util/u_dynarray.h
+++
Note at the moment the pass called is nir_opt_copy_prop_vars, because
dead write elimination is implemented there.
Also added tests that involve identifying dead writes in multiple
blocks (e.g. the overwrite happens in another block). Those currently
fail as expected, so are marked to be
Add basic helpers for doing tests on the vars related optimization
passes. The main goal is to lower the barrier to create tests during
development and debugging of the passes. Full coverage is not a
requirement.
---
src/compiler/Makefile.nir.am | 34 +++--
This series supersedes the "Global dead write vars removal pass".
The goal here is to perform copy propagation among values in different
blocks. While this has currently small benefits (it effectively
helped some cases with uniforms), as we move other resources to be
addressed with derefs (e.g.
Useful to walk the array removing elements by swapping them with the
last element.
---
src/util/u_dynarray.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/util/u_dynarray.h b/src/util/u_dynarray.h
index 6bea481d44b..f74bfc7080b 100644
--- a/src/util/u_dynarray.h
+++
Any progress on adding EXT_sRGB support to Mesa?
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=78123
--- Comment #7 from Brian Paul ---
John, is this still an issue?
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
---
src/intel/vulkan/genX_query.c | 53 ++-
1 file changed, 21 insertions(+), 32 deletions(-)
diff --git a/src/intel/vulkan/genX_query.c b/src/intel/vulkan/genX_query.c
index 4ccbe2975de..7533ec05095 100644
--- a/src/intel/vulkan/genX_query.c
+++
Instead of passing around BOs and offsets, use addresses which are anv's
GPU equivalent of pointers.
---
src/intel/vulkan/genX_query.c | 121 ++
1 file changed, 64 insertions(+), 57 deletions(-)
diff --git a/src/intel/vulkan/genX_query.c
Each query slot is a uint64_t and we were only zeroing half of it.
Fixes: 7ec6e4e68980 "anv/query: implement multiview interactions"
---
src/intel/vulkan/genX_query.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/intel/vulkan/genX_query.c b/src/intel/vulkan/genX_query.c
index
---
src/intel/vulkan/anv_genX.h| 4
src/intel/vulkan/genX_gpu_memcpy.c | 17 +
src/intel/vulkan/genX_query.c | 14 ++
3 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
index
Instead of computing an index at the end which we hope maps to the
number of things written, just count the number of things as we go.
---
src/intel/vulkan/genX_query.c | 67 ---
1 file changed, 31 insertions(+), 36 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=91098
Brian Paul changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=48143
Brian Paul changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=92983
Brian Paul changed:
What|Removed |Added
CC||v...@freedesktop.org
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=107878
--- Comment #6 from Timothy Arceri ---
(In reply to gloriouseggroll from comment #5)
> can confirm fixed on llvm8 for me as well. (still broken with current mesa
> git and llvm 7)
If you want llvm7 to work you might need to do a git bisect to
https://bugs.freedesktop.org/show_bug.cgi?id=93970
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEEDINFO
https://bugs.freedesktop.org/show_bug.cgi?id=96542
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107878
--- Comment #5 from gloriouseggr...@gmail.com ---
can confirm fixed on llvm8 for me as well. (still broken with current mesa git
and llvm 7)
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for
Since only Blender and Firefox experience problems, they can be
blacklisted for this optimization, and then we can expand the
blacklist as we go.
Marek
On Fri, Sep 14, 2018 at 9:04 PM, Marek Olšák wrote:
> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer wrote:
>> On 2018-09-13 8:56 p.m., Marek
https://bugs.freedesktop.org/show_bug.cgi?id=106922
--- Comment #7 from Christoph Haag ---
Created attachment 141569
--> https://bugs.freedesktop.org/attachment.cgi?id=141569=edit
corruption at small resolutions
Nice, with the patches it runs without crashing.
At 1920x1080 it looks good, but
On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer wrote:
> On 2018-09-13 8:56 p.m., Marek Olšák wrote:
>> On Thu, Sep 13, 2018 at 11:48 AM, Michel Dänzer wrote:
>>> On 2018-09-13 2:40 a.m., Marek Olšák wrote:
From: Marek Olšák
[...]
static void
On Fri, Sep 14, 2018 at 12:54 PM, Nicholas Miell wrote:
> On 09/12/2018 05:40 PM, Marek Olšák wrote:
>> +static void
>> +util_set_full_cpu_affinity(void)
>> +{
>> + cpu_set_t cpuset;
>> +
>> + CPU_ZERO();
>> + for (unsigned i = 0; i < CPU_SETSIZE; i++)
>> + CPU_SET(i, );
>> +
>> +
https://bugs.freedesktop.org/show_bug.cgi?id=104681
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Gallium/StateTracker/Clover
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=106833
Timothy Arceri changed:
What|Removed |Added
QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=106996
Timothy Arceri changed:
What|Removed |Added
QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=78123
Timothy Arceri changed:
What|Removed |Added
Component|Other |Drivers/Gallium/vmwgfx
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=106677
Timothy Arceri changed:
What|Removed |Added
Component|Other |Drivers/Gallium/vmwgfx
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=100037
Timothy Arceri changed:
What|Removed |Added
Component|Other |Drivers/Gallium/vmwgfx
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=91098
Timothy Arceri changed:
What|Removed |Added
Component|Other |Drivers/Gallium/vmwgfx
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=48143
Timothy Arceri changed:
What|Removed |Added
Component|Other |Drivers/Gallium/vmwgfx
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=92983
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/vmwgfx
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=101405
--- Comment #2 from David Hedlund ---
(In reply to Timothy Arceri from comment #1)
> I don't think there is much point fixing this that page is out of date
> (hasn't been updated in over 5 years) and its usefulness is questionable.
Thank you.
https://bugs.freedesktop.org/show_bug.cgi?id=101405
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|REOPENED
Series:
Reviewed-by: Timothy Arceri
Are there piglit tests to go with this?
On 15/8/18 10:46 pm, Danylo Piliaiev wrote:
do_assignment validated assigment but when rhs type was not compatible
it proceeded without issues and returned error_emitted = false.
On the other hand process_initializer
https://bugs.freedesktop.org/show_bug.cgi?id=107939
--- Comment #1 from Timothy Arceri ---
Since the referenced sha is for the 18.1 rather than the master branch I'm
copying here for completeness.
commit 888b7fcaf4d4f25c90c318495c7c38066cff29fb
Author: Samuel Pitoiset
Date: Wed Jun 13
https://bugs.freedesktop.org/show_bug.cgi?id=107923
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
CC|
---
src/intel/genxml/gen10.xml | 32
src/intel/genxml/gen11.xml | 32
src/intel/genxml/gen7.xml | 32
src/intel/genxml/gen75.xml | 32
src/intel/genxml/gen8.xml |
https://bugs.freedesktop.org/show_bug.cgi?id=100960
--- Comment #9 from Fabian Maurer ---
Created attachment 141566
--> https://bugs.freedesktop.org/attachment.cgi?id=141566=edit
Windows - Call 2245521 - Framebuffer
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=97516
--- Comment #4 from Sven Arvidsson ---
I tried the suggested hack of adding _DRI_ATTRIB_SWAP_EXCHANGE to
back_buffer_modes[]. In the case of Brink, it allows me to launch the game, but
in fullscreen mode it stops updating the screen, so only a
https://bugs.freedesktop.org/show_bug.cgi?id=107923
--- Comment #4 from Dylan Baker ---
This seems to be auto tools specific, I cn't replicate with the closest meson
configuration I could come up with (-Dbuildtype=debug -Dglx=gallium-xlib
-Ddri-drivers= -Dvulkan-drivers=
On Wed, Sep 12, 2018 at 12:06:49AM -0500, Jason Ekstrand wrote:
> This shouldn't matter as we'll never write OOB anyway but we may as well
> get it right. It's supposed to be in dwords - 1.
> ---
> src/intel/vulkan/genX_gpu_memcpy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On 09/14/2018 01:09 PM, Fritz Koenig wrote:
Instances where direction was determined based on
winsys or user fbo and should be determined based on
FlipY.
Key STATE_FB_WPOS_Y_TRANSFORM for of FlipY instead of
_mesa_is_user_fbo. This corrects gl_FragCoord usage
when applying
https://bugs.freedesktop.org/show_bug.cgi?id=107923
--- Comment #3 from Brian Paul ---
I'm seeing similar issues.
$ ../autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug
--enable-xlib-glx --disable-driglx-direct --disable-dri
--with-gallium-drivers=swrast,svga --disable-gbm
Instances where direction was determined based on
winsys or user fbo and should be determined based on
FlipY.
Key STATE_FB_WPOS_Y_TRANSFORM for of FlipY instead of
_mesa_is_user_fbo. This corrects gl_FragCoord usage
when applying GL_MESA_framebuffer_flip_y.
Fixes: ab05dd183cc ("i965: implement
Missing break; causes parameter checking to
never pass GL_FRAMEBUFFER_FLIP_Y_MESA paramers.
Fixes: 318c265160 ("mesa: GL_MESA_framebuffer_flip_y extension [v4]")
---
src/mesa/main/fbobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
Quoting Eric Engestrom (2018-09-14 09:39:27)
> On Thursday, 2018-09-13 11:41:38 -0700, Dylan Baker wrote:
> > Rather than trying to encode all of the rules in a header, lets just put
> > them in the build system where they belong. This fixes the build on
> > FreeBSD, which does have
https://bugs.freedesktop.org/show_bug.cgi?id=107923
--- Comment #2 from Vinson Lee ---
(In reply to Sergii Romantsov from comment #1)
> could you, please, specify your build-configuration?
./autogen.sh --disable-dri --disable-egl --disable-gbm --enable-debug
--with-dri-drivers=swrast
https://bugs.freedesktop.org/show_bug.cgi?id=107765
--- Comment #2 from farmboy0+freedesk...@googlemail.com ---
I use
vanilla wine 3.12/3.14
DXVK 0.7.0 and 0.7.1
in a 32 or 64 bit prefix.
I have a R9 380X
Kernel 4.18.5 with DC enabled.
I tried Mesa git, no change.
Latest console output before
Hi Dylan,
this patch only matters for debug builds (DEBUG set), but your merge
result looks correct nonetheless.
Thanks
On Fri, Sep 14, 2018 at 6:16 PM, Dylan Baker wrote:
> Quoting Pierre Moreau (2017-12-04 15:51:04)
>> Those operations do not map to actual hardware instructions, therefore
>>
On 09/12/2018 05:40 PM, Marek Olšák wrote:
> +static void
> +util_set_full_cpu_affinity(void)
> +{
> + cpu_set_t cpuset;
> +
> + CPU_ZERO();
> + for (unsigned i = 0; i < CPU_SETSIZE; i++)
> + CPU_SET(i, );
> +
> + pthread_setaffinity_np(pthread_self(), sizeof(cpuset), );
> +}
>
>
Quoting Dylan Baker (2018-09-13 11:41:38)
> Rather than trying to encode all of the rules in a header, lets just put
> them in the build system where they belong. This fixes the build on
> FreeBSD, which does have pthraed_setaffinity_np, but it's in a
> pthread_np.h, not behind _GNU_SOURCE.
I suppose ideally it would only affect instruction chains which have a
precise modifier somewhere. But it's better than just ignoring it
completely.
Reviewed-by: Roland Scheidegger
Am 14.09.2018 um 16:56 schrieb Gert Wollny:
> Fixes:
>
On Thursday, 2018-09-13 11:41:38 -0700, Dylan Baker wrote:
> Rather than trying to encode all of the rules in a header, lets just put
> them in the build system where they belong. This fixes the build on
> FreeBSD, which does have pthraed_setaffinity_np, but it's in a
> pthread_np.h, not behind
Quoting Pierre Moreau (2017-12-04 15:51:04)
> Those operations do not map to actual hardware instructions, therefore
> those should always be lowered to 32-bit instructions.
>
> Fixes: 009c54aa7af "nv50/ir: Split 64-bit integer MAD/MUL operations"
> Signed-off-by: Pierre Moreau
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=107939
Michel Dänzer changed:
What|Removed |Added
Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon
On 09/14/2018 02:52 AM, Alejandro Piñeiro wrote:
> No shader-db changes, so perhaps adding a test on
> test_fs_cmod_propagation? In any case, the patch looks good to me:
I should have mentioned in the commit message, but I added a piglit test:
https://patchwork.freedesktop.org/patch/249182/
>
The typo in subject is fixed locally.
Am Freitag, den 14.09.2018, 16:56 +0200 schrieb Gert Wollny:
> Fixes:
> dEQP-
> GLES3.functional.shaders.invariance.highp.common_subexpression_3
> dEQP-
> GLES3.functional.shaders.invariance.mediump.common_subexpression_3
> dEQP-
>
Am Freitag, den 14.09.2018, 15:26 +0300 schrieb andrey simiklit:
[...]
> > + if (vcmd == VCMD_TRANSFER_PUT2)
> > + vtest_hdr[VTEST_CMD_LEN] += data_size + 3 / 4;
>
> Looks like a copy/paste mistake)
> I suppose that it is should be like:
> ... = (data_size + 3) / 4;
> or may be just:
> ...
Fixes:
dEQP-GLES3.functional.shaders.invariance.highp.common_subexpression_3
dEQP-GLES3.functional.shaders.invariance.mediump.common_subexpression_3
dEQP-GLES3.functional.shaders.invariance.lowp.common_subexpression_3
Signed-off-by: Gert Wollny
---
src/gallium/drivers/r600/r600_asm.h
https://bugs.freedesktop.org/show_bug.cgi?id=107547
--- Comment #4 from Sergii Romantsov ---
One more version:
https://patchwork.freedesktop.org/series/48256/
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev
Seems that patch is simplified version of already exist one:
https://patchwork.freedesktop.org/series/48256/
On Fri, Sep 14, 2018 at 4:39 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:
> During do_assignment a validation of rhs may fail.
> Because of lack error_emitted an error_value
https://bugs.freedesktop.org/show_bug.cgi?id=97516
--- Comment #3 from Sven Arvidsson ---
As a temporary workaround to get the game Brink running I disabled the
GLX_OML_swap_method. Wine has a check, and will ignore the attribute if the
extension is missing.
Brink starts and runs, though I'm
https://bugs.freedesktop.org/show_bug.cgi?id=107547
--- Comment #3 from Sergii Romantsov ---
Proposed patch:
https://patchwork.freedesktop.org/patch/249568/
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing
During do_assignment a validation of rhs may fail.
Because of lack error_emitted an error_value may not be generated.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
Signed-off-by: Sergii Romantsov
---
src/compiler/glsl/ast_to_hir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff
https://bugs.freedesktop.org/show_bug.cgi?id=107391
--- Comment #2 from tempel.jul...@gmail.com ---
DXVK now also supports enforcing vsync on/off. :)
However, it would still be nice to also have these options for outside of DXVK
since native Linux apps might not offer full control to the user
https://bugs.freedesktop.org/show_bug.cgi?id=107391
--- Comment #1 from Samuel Pitoiset ---
DXVK now allows to force AF, so I guess the only feature you want is vsync?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=106769
Samuel Pitoiset changed:
What|Removed |Added
Summary|radv: Support |radv: add support for
Reviewed-by: Bas Nieuwenhuizen
On Fri, Sep 14, 2018 at 2:55 PM Samuel Pitoiset
wrote:
>
> The size has to be multiplied by the number of sets.
>
> This gets rid of the OUT_OF_POOL_KHR error and fixes
> the Tangrams demo.
>
> CC: 18.1 18.2
> Signed-off-by: Samuel Pitoiset
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=106922
--- Comment #6 from Samuel Pitoiset ---
The demo should now work if you apply:
https://patchwork.freedesktop.org/series/49701/
https://patchwork.freedesktop.org/series/49710/
--
You are receiving this mail because:
You are the assignee for
The size has to be multiplied by the number of sets.
This gets rid of the OUT_OF_POOL_KHR error and fixes
the Tangrams demo.
CC: 18.1 18.2
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_descriptor_set.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Rb
On September 14, 2018 04:12:44 Eric Engestrom wrote:
Fixes: da997ebec929421939553 "vulkan: Add KHR_display extension using DRM
[v10]"
Cc: Keith Packard
Cc: Jason Ekstrand
Signed-off-by: Eric Engestrom
---
v2: don't forget to free the swapchain too (Jason)
---
https://bugs.freedesktop.org/show_bug.cgi?id=107351
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107923
--- Comment #1 from Sergii Romantsov ---
Hello, Vinson,
could you, please, specify your build-configuration?
I don't see such output.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
Hello,
Please find my comment below:
Regards,
Andrii.
On Fri, Sep 14, 2018 at 12:23 PM Gert Wollny
wrote:
> From: Tomeu Vizoso
>
> Pass the size of a resource when creating it so a backing can be kept in
> the other side.
>
> Also pass the required offset to transfer commands.
>
> This moves
Reviewed-by: Bas Nieuwenhuizen
for the series.
On Fri, Sep 14, 2018 at 12:51 PM Samuel Pitoiset
wrote:
>
> Not sure if this is all wired up. CTS does pass and the Tangrams
> demo seems to work (though with a local hack that is unrelated
> to 16-bit integer).
>
> Signed-off-by: Samuel Pitoiset
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 71723d5e91..905146c9f2 100644
--- a/src/amd/common/ac_llvm_build.c
+++
Are we missing 64-bit support?
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 22 ++
src/amd/common/ac_llvm_build.h | 3 +++
src/amd/common/ac_nir_to_llvm.c | 2 +-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 98635ec25a..ab0ba09c83 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
Not sure if this is all wired up. CTS does pass and the Tangrams
demo seems to work (though with a local hack that is unrelated
to 16-bit integer).
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 2 +-
src/amd/vulkan/radv_shader.c | 1 +
2 files changed, 2 insertions(+), 1
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 6955df48e0..98635ec25a 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 905146c9f2..6955df48e0 100644
--- a/src/amd/common/ac_llvm_build.c
+++
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 011cea5cd0..71723d5e91 100644
--- a/src/amd/common/ac_llvm_build.c
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 ++
src/amd/common/ac_llvm_build.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index a99314266c..011cea5cd0 100644
--- a/src/amd/common/ac_llvm_build.c
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 28
src/amd/common/ac_llvm_build.h | 2 ++
src/amd/common/ac_nir_to_llvm.c | 7 +--
3 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c
I can't say I know enough of all these parts but I went through the API
functions and tried to check that you have proper checks in place. Will
try to still review :)
I did not see any check against MAX_INLINE_UNIFORM_BLOCK_DESCRIPTORS
when creating pipeline layout. I'm not sure if such is
No shader-db changes, so perhaps adding a test on
test_fs_cmod_propagation? In any case, the patch looks good to me:
Reviewed-by: Alejandro Piñeiro
On 14/09/18 00:06, Ian Romanick wrote:
> From: Ian Romanick
>
> No shader-db changes on any Intel platform... which probably explains
> why no
On 2018-09-14 10:53 a.m., Michel Dänzer wrote:
> On 2018-09-13 8:56 p.m., Marek Olšák wrote:
>
>> +* What happens if a driver is unloaded and the app creates a thread?
>
> I suppose the child process will likely crash, because the memory
> address where util_set_full_cpu_affinity was located
did not spot any behavioral change, LGTM
Reviewed-by: Tapani Pälli
On 11.09.2018 23:22, Lionel Landwerlin wrote:
The following commits will make the allocation more complicated so
split the free list allocation logic out.
Signed-off-by: Lionel Landwerlin
---
On 9/14/18 11:10 AM, Bas Nieuwenhuizen wrote:
On Fri, Sep 14, 2018 at 10:31 AM Samuel Pitoiset
wrote:
On 9/12/18 11:19 PM, Bas Nieuwenhuizen wrote:
On Wed, Sep 12, 2018 at 10:44 PM Samuel Pitoiset
wrote:
Only supported by GFX9+.
The conservativeraster Sascha demo seems to work as
From: Tomeu Vizoso
Pass the size of a resource when creating it so a backing can be kept in
the other side.
Also pass the required offset to transfer commands.
This moves vtest closer to how virtio-gpu works, making it more useful
for testing.
v2: - Use new messages for creation and
From: Tomeu Vizoso
Check if server supports version negotation by sending a PING_PROTOCOL_VERSION
message right before a dummy RESOURCE_BUSY_WAIT. If we don't get a reply
for the first, we know the server doesn't support it.
If it does support it, we can query the max protocol version supported
Hello Dave,
Am Freitag, den 14.09.2018, 13:25 +1000 schrieb Dave Airlie:
[...]
> This causes regressions in a bunch of piglits on skylake for me.
>
> arb_copy_image-formats
> and some
> ./bin/fbo-generatemipmap-formats GL_EXT_texture_sRGB-s3tc
>
> have some different results after this.
1 - 100 of 114 matches
Mail list logo