https://bugs.freedesktop.org/show_bug.cgi?id=109201
--- Comment #14 from Samuel Pitoiset ---
What mesa version are you using? Can you try with latest mesa (git) ?
We recently fixed an issue which might help you too.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You
On 2019-02-11 5:18 p.m., Andy Ritger wrote:
> On Mon, Feb 11, 2019 at 12:09:26PM +0100, Michel Dänzer wrote:
>> On 2019-02-08 11:43 p.m., Kyle Brenneman wrote:
>>>
>>> Also, is Mesa the only client-side vendor library that works with the
>>> Xorg GLX module? I vaguely remember that there was at lea
opt_split_alu_of_phi moves ALU instruction to the end of continue block.
But if the continue block ends with a jump instruction (an explicit
"continue" instruction) then the ALU must be inserted before the jump,
as it is illegal to add instructions after the jump.
CC: Ian Romanick
Fixes: 0881e90
Both patches:
Reviewed-by: Nicolai Hähnle
On 11.02.19 21:26, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_perfcounter.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c
b/src/gallium/driver
On 11.02.19 21:27, Marek Olšák wrote:
From: Marek Olšák
initialize all non-compute context functions to NULL.
---
src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
src/gallium/drivers/radeonsi/si_clear.c | 7 +-
src/gallium/drivers/radeonsi/si_compute.c | 15 +--
src/galli
Hi all,
Unfortunately, freedesktop.org's job of sending mail to a huge number
of people whilst pretending to be other people, has just got even
harder than it was.
fd.o can no longer (at least for the moment) send mail with the From
addresses of DMARC/DKIM/SPF-protected sender domains. When we try
Reviewed-by: Bas Nieuwenhuizen
On Mon, Feb 11, 2019 at 1:16 PM Gustaw Smolarczyk wrote:
>
> FWIW,
>
> Reviewed-by: Gustaw Smolarczyk
>
> pon., 11 lut 2019 o 10:15 Samuel Pitoiset
> napisał(a):
> >
> > "The C standard says that compound literals which occur inside of
> > the body of a function
Empirical testing shows that gen8 has a bug where MAD instructions with
a half-float source starting at a non-zero offset fail to execute
properly.
This scenario usually happened in SIMD8 executions, where we used to
pack vector components Y and W in the second half of SIMD registers
(therefore, w
The hardware doesn't support half-float for these.
Reviewed-by: Topi Pohjolainen
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_nir.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 7e3dbc9e447..75513e5113c 10064
There are some hardware restrictions that brw_nir_lower_conversions should
have taken care of before we get here.
v2:
- rebased on top of regioning lowering pass
Reviewed-by: Topi Pohjolainen (v1)
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 5 +++--
1 file changed, 3 i
Reviewed-by: Topi Pohjolainen
Reviewed-by: Jason Ekstrand
Reviewed-by: Matt Turner
---
src/intel/compiler/brw_eu_emit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 2f31d9591fc..30037e71b00 100644
It is very likely that this optimzation is never useful and we'll probably
just end up removing it, so let's not bother adding more cases to it for
now.
---
src/intel/compiler/brw_fs.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_
---
src/intel/compiler/brw_eu_validate.c| 10 +-
src/intel/compiler/test_eu_validate.cpp | 46 +
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index 203641fecb9..b1fdd1ce94
We were assuming 32-bit elements. Also, In SIMD8 we pack 2 vector components
in a single SIMD register, so for example, component Y of a 16-bit vec2
starts is at byte offset 16B. This means that when we compute the offset of
the elements to be differentiated we should not stomp whatever base offset
So it is right after the checks for the other various Int* capabilities.
---
src/compiler/spirv/spirv_to_nir.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
index 1cbc926c818..7e07de2bfc0 100644
---
And enable it on Intel.
v2:
- Squash the change to enable it on Intel (Jason)
Reviewed-by: Jason Ekstrand
---
src/compiler/nir/nir.h| 1 +
src/compiler/nir/nir_opt_algebraic.py | 1 +
src/intel/compiler/brw_compiler.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/sr
Some conversions are not directly supported in hardware and need to be
split in two conversion instructions going through an intermediary type.
Doing this at the NIR level simplifies a bit the complexity in the backend.
v2:
- Consider fp16 rounding conversion opcodes
- Properly handle swizzles o
v2 (Jason):
- Merge shaderFloat16 and shaderInt8 enablement into a single patch.
- Merge extension enable.
Reviewed-by: Jason Ekstrand (v1)
---
src/intel/vulkan/anv_device.c | 9 +
src/intel/vulkan/anv_extensions.py | 1 +
2 files changed, 10 insertions(+)
diff --git a/src/intel/
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 64e24f86b5a..f59e9ad4e2b 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src
Extended math with half-float operands is only supported since gen9,
but it is limited to SIMD8. In gen8 we lower it to 32-bit.
v2: quashed together the following patches (Jason):
- intel/compiler: allow extended math functions with HF operands
- intel/compiler: lower 16-bit extended math to 3
Broadwell has restrictions that apply to Align16 half-float that
make the Align16 implementation of this invalid for this platform.
Use the gen11 path for this instead, which uses Align1 mode.
The restriction is not present in cherryview, gen9 or gen10, where
the Align16 implementation seems to wo
At the very least we need it to handle HF too, since we are doing
constant propagation for MAD and LRP, which relies on this pass
to promote the immediates to GRF in the end, but ideally
we want it to support even more types so we can take advantage
of it to improve register pressure in some scenar
The hardware only allows a stride of 1 on a Byte destination for raw
byte MOV instructions. This is required even when the destination
is the NULL register.
Rather than making sure that we emit a proper NULL:B destination
every time we need one, just fix it at emission time.
Reviewed-by: Jason Ek
v2:
- Assign BRW_REGISTER_TYPE_B directly for 8-bit (Jason)
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 40c0481ac53..761d4
Particularly, we need the same lowewrings we use for 16-bit
integers.
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_nir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 9b26a6c3d6f..1d62f2adde8 100644
NIR already has these and correctly considers exact/inexact qualification,
whereas the backend doesn't and can apply the optimizations where it
shouldn't. This happened to be the case in a handful of Tomb Raider shaders,
where NIR would skip the optimizations because of a precise qualification
but
v2:
- Do not propagate if the bit-size changes
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_cmod_propagation.cpp | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp
b/src/intel/compiler/brw_fs_cmod_propa
v2:
- Fixed typo: meant BRW_REGISTER_TYPE_UB instead BRW_REGISTER_TYPE_UV
Reviewed-by: Jason Ekstrand (v1)
---
src/intel/compiler/brw_reg_type.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/intel/compiler/brw_reg_type.h
b/src/intel/compiler/brw_reg_type.h
index f
Now that we have the regioning lowering pass we can just put all of these
opcodes together in a single block and we can just assert on the few cases
of conversion instructions that are not supported in hardware and that should
be lowered in brw_nir_lower_conversions.
The only cases what we still h
v2:
- Merge Float16 and Int8 capabilities into a single patch (Jason)
- Merged patch that enabled SPIR-V front-end checks for these caps
(except for Int8, which was already merged)
Reviewed-by: Jason Ekstrand (v1)
---
src/compiler/shader_info.h| 1 +
src/compiler/spirv/spirv_to_n
There are no 8-bit immediates, so assert in that case.
16-bit immediates are replicated in each word of a 32-bit immediate, so
we only need to check the lower 16-bits.
v2:
- Fix is_zero with half-float to consider -0 as well (Jason).
- Fix is_negative_one for word type.
Reviewed-by: Jason Ekstr
Since we handle booleans as integers this makes more sense.
v2:
- rebased to incorporate new boolean conversion opcodes
v3:
- rebased on top regioning lowering pass
Reviewed-by: Jason Ekstrand (v1)
Reviewed-by: Topi Pohjolainen (v2)
---
src/intel/compiler/brw_fs_nir.cpp | 16 ---
The section 'Execution Data Types' of 3D Media GPGPU volume, which
describes execution types, is exactly the same in BDW and SKL+.
Also, this section states that there is a single execution type, so it
makes sense that this is the wider of the two floating point types
involved in mixed float mode,
Mixed float instructions are those that use both F and HF operands as their
sources or destination, except for regular conversions.
There are specific rules for mixed float operation mode with its own set
of restrictions, which involve rules that are incompatible with general
restrictions. For exa
v2 (Topi):
- Make bit-size handling order be 16-bit, 32-bit, 64-bit
- Clamp lower exponent range at -28 instead of -30.
Reviewed-by: Topi Pohjolainen
Reviewed-by: Jason Ekstrand
---
src/compiler/nir/nir_opt_algebraic.py | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --gi
The changes in this version address review feedback to v3. The most significant
changes include:
1. A more generic constant combining pass that can handle more
constant types (not just F and HF) requested by Jason.
2. The addition of assembly validation for half-float restrictions, and also
for m
This is available since gen8.
v2: restore previously existing assertion.
v3: don't use separate tables for gen7 and gen8, just assert that we
don't use half-float before gen8 (Matt)
Reviewed-by: Topi Pohjolainen (v1)
---
src/intel/compiler/brw_reg_type.c | 4
1 file changed, 4 inserti
This function is used in two different scenarios that for 32-bit
instructions are the same, but for 16-bit instructions are not.
One scenario is that in which we are working at a SIMD8 register
level and we need to know if a register is fully defined or written.
This is useful, for example, in the
And enable it on Intel.
v2:
- Squash the change to enable this lowering on Intel (Jason)
Reviewed-by: Jason Ekstrand
---
src/compiler/nir/nir.h| 1 +
src/compiler/nir/nir_opt_algebraic.py | 1 +
src/intel/compiler/brw_compiler.c | 1 +
3 files changed, 3 insertions(+)
diff
https://bugs.freedesktop.org/show_bug.cgi?id=109532
--- Comment #25 from asimiklit ---
(In reply to asimiklit from comment #23)
> (In reply to Mark Janes from comment #22)
> > The combination of deqp/mesa patches passed CI. The only failure was
> >
> > piglit.spec.!opengl 1_1.tex-upside-down
https://bugs.freedesktop.org/show_bug.cgi?id=109615
Bug ID: 109615
Summary: 19.0.0_rc2 fails u_format_test on ppc64
Product: Mesa
Version: unspecified
Hardware: PowerPC
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=109615
--- Comment #1 from erhar...@mailbox.org ---
Created attachment 143366
--> https://bugs.freedesktop.org/attachment.cgi?id=143366&action=edit
Gentoo build.log.xz
--
You are receiving this mail because:
You are the assignee for the bug.
You are
https://bugs.freedesktop.org/show_bug.cgi?id=109615
--- Comment #2 from erhar...@mailbox.org ---
The "44/47 mesa:gallium / u_format_test" failing here is new in 19.0.0_rc.
18.3.x passes core tests just fine on ppc64 (not so the llvmpipe tests, see bug
#106644).
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=109543
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
The formats will be used for reducing the number of loaded channels.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 22 +++---
src/amd/vulkan/radv_private.h | 1 +
src/amd/vulkan/radv_shader.h | 1 +
3 files changed, 21 insertions(+), 3 deletions(-)
dif
And make ac_build_expand() a static function.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 9 +
src/amd/common/ac_llvm_build.h | 3 ---
src/amd/common/ac_nir_to_llvm.c | 2 +-
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/amd/common/ac_llvm_b
It's unnecessary to load more channels than the vertex attribute
format. The remaining channels are filled with 0 for y and z,
and 1 for w.
29077 shaders in 15096 tests
Totals:
SGPRS: 1321605 -> 1318869 (-0.21 %)
VGPRS: 935236 -> 932252 (-0.32 %)
Spilled SGPRs: 24860 -> 24776 (-0.34 %)
Code Size:
On Mon, 11 Feb 2019 11:41:08 -0800 Eric Anholt said:
> Carsten Haitzler writes:
>
> > On Mon, 04 Feb 2019 16:31:57 -0800 Eric Anholt said:
> >
> >> Carsten Haitzler writes:
> >>
> >> > On Fri, 1 Feb 2019 11:08:07 + Emil Velikov
> >> > said:
> >> >
> >> >> Hi Carsten,
> >> >>
> >> >> On
On February 12, 2019 05:57:09 Iago Toral Quiroga wrote:
v2:
- Merge Float16 and Int8 capabilities into a single patch (Jason)
- Merged patch that enabled SPIR-V front-end checks for these caps
(except for Int8, which was already merged)
Reviewed-by: Jason Ekstrand (v1)
---
src/compiler/s
Add compute shader initilization, assign and cleanup in vl_compositor API.
Set video compositor compute shader render as default when pipe support it.
Signed-off-by: James Zhu
Reviewed-by: Christian König
---
src/gallium/auxiliary/vl/vl_compositor.c | 108 +++
src/ga
On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> I had a chat with Caio about this and I'm skeptical. In general, users of
> the CF manipulation code shouldn't be stitching two blocks together where the
> first contains a jump and the second is non-empty. If the caller knows that
> t
On 2/12/19 10:35 AM, Zhu, James wrote:
> Add compute shader initilization, assign and cleanup in vl_compositor API.
> Set video compositor compute shader render as default when pipe support it.
>
> Signed-off-by: James Zhu
> Reviewed-by: Christian König
> ---
> src/gallium/auxiliary/vl/vl_comp
What's the status of this?
On 12/7/18 6:21 PM, Rhys Perry wrote:
This series add support for:
- VK_KHR_shader_float16_int8
- VK_AMD_gpu_shader_half_float
- VK_AMD_gpu_shader_int16
- VK_KHR_8bit_storage
on VI+. Half floats are currently disabled on LLVM 7 because of a bug
causing large memory usa
https://bugs.freedesktop.org/show_bug.cgi?id=109575
--- Comment #13 from LunarG ---
Yes! this patch worked for me on my Ubuntu 18.04 - AMD R9 380 system! I will
check with my other AMD systems today.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=109107
--- Comment #5 from leoxs...@gmail.com ---
The fixe is in Mesa master branch, also includes fix for playing VP9 with
Chromium. Please make sure run with "allow_rgb10_configs=false" for now.
--
You are receiving this mail because:
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=109575
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/237
New version of the thread that I sent recently, showing two initial
versions to solve the regression I found on MR #144:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/214808.html
This MR includes a v2 of the second op
It currently requires review (and possibly rebasing). Marek Olšák send
some feedback for a few of the patches but other than that, it hasn't
gotten much attention.
Also patch 35 seems to vectorize 32-bit code which can help or hurt
shaders quite a bit and seems to hurt shaders overall. I'm not yet
How about splitting this series in four different parts? One for every
extension? Is this doable without too much troubles?
On 2/12/19 6:02 PM, Rhys Perry wrote:
It currently requires review (and possibly rebasing). Marek Olšák send
some feedback for a few of the patches but other than that, it
On Tue, Feb 12, 2019 at 10:48 AM Juan A. Suarez Romero
wrote:
> This can happen when we record a VkCmdDraw in a secondary buffer that
> was created inheriting from the primary buffer, but with the framebuffer
> set to NULL in the VkCommandBufferInheritanceInfo.
>
> Vulkan 1.1.81 spec says that "t
Hi Juan,
On Tue, Feb 12, 2019 at 04:37:23PM +0100, Juan A. Suarez Romero wrote:
> On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> > I had a chat with Caio about this and I'm skeptical. In general, users of
> > the CF manipulation code shouldn't be stitching two blocks together where
Based on VA Spec,DeriveImage() returns VA_STATUS_ERROR_OPERATION_FAILED if
driver
dont have support for internal surface formats.Currently vaDeriveImage()
failed for non-contiguous planes and operation failed error string is
required to support indirect manner i.e. vaCreateImage()+vaPutImage()
inc
Sorry that I step in so late, but the whole family recover slowly from a
bad flu...
Tried your 'latest" three series altogether with my Polaris 20 (NIR!).
UH and UV hang after some seconds reliable. VM faults. Have to dig
deeper in (remote) to get some logs.
But my reported Polaris triangle c
All of the actual abstraction (except possibly setting size_written)
happens as part of the logical opcodes. The only thing that the surface
builder is providing at this point is extra levels of functions to call
through. I'm going to be adding bindless image support soon and all the
extra abstra
---
src/intel/compiler/brw_eu_validate.c| 256 ++
src/intel/compiler/test_eu_validate.cpp | 618
2 files changed, 874 insertions(+)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index ed9c8fe59dd..a61d4c46e81 100644
This is set to True only for numeric conversion opcodes.
---
src/compiler/nir/nir.h| 3 ++
src/compiler/nir/nir_opcodes.py | 73 +--
src/compiler/nir/nir_opcodes_c.py | 1 +
3 files changed, 44 insertions(+), 33 deletions(-)
diff --git a/src/compiler/ni
The original SrcType is a 3-bit field that takes a subset of the types
supported for the hardware for 3-source instructions. Since gen8,
when the half-float type was added, 3-source floating point operations
can use use mixed precision mode, where not all the operands have the
same floating-point p
v2:
- make 16-bit be its own separate case (Jason)
v3:
- Drop the result_int temporary (Jason)
Reviewed-by: Topi Pohjolainen (v1)
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/intel/
https://bugs.freedesktop.org/show_bug.cgi?id=109532
--- Comment #26 from asimiklit ---
(In reply to Ian Romanick from comment #17)
> (In reply to asimiklit from comment #6)
> > Created attachment 143288 [details]
> > this simple program helps me to reproduce this issue.
> >
> > just share my sim
https://bugs.freedesktop.org/show_bug.cgi?id=109575
--- Comment #10 from Samuel Pitoiset ---
Interesting, thanks for bisecting. I will investigate.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.__
For some reasons, this breaks trees rendering in Project Cars.
Fixes: 85010585cde ("radv: only enable gl_SampleMask if MSAA is enabled too")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109401
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 8
1 file change
In opt_peel_initial_if optimization, when moving the continue list to
end of the continue block, before the jump, could happen that the
continue list itself also ends with a jump.
This would mean that we would have two jump instructions in a row: the
first one from the continue list and the second
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 0fef92773e1..9778b13ce86 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_de
Source0 and Destination extract the floating-point precision automatically
from the SrcType and DstType instruction fields respectively when they are
set to types :F or :HF. For Source1 and Source2 operands, we use the new
1-bit fields Src1Type and Src2Type, where 0 means normal precision and 1
mea
We are now using these bits, so don't assert that they are not set. In gen8,
if these bits are set compaction is not possible. On gen9 and CHV platforms
set_3src_control_index() checks these bits (and others) against a table to
validate if the particular bit combination is eligible for compaction o
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 3a6e4a2eb60..40c0481ac53 100644
--- a/src/intel/compiler/br
Instead of generating a GL_INVALID_ENUM error when the type or format
is incorrect while using glClear{Named}Buffer{Sub}Data, generate
GL_INVALID_VALUE.
From page 72 (page 94 of the PDF) of the OpenGL 4.6 spec:
" An INVALID_VALUE error is generated if type is not one of the
types in table 8
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Bug 109535 depends on bug 109543, which changed state.
Bug 109543 Summary: After upgrade mesa to 19.0.0~rc1 all vulkan based
application stop working ["vulkan-cube" received SIGSEGV in
radv_pipeline_init_blend_state at ../src/amd/vulkan/radv_pi
Going forward having these split is a bit more convenient since these two
groups have different restrictions.
v2:
- Rebased on top of new regioning lowering pass.
Reviewed-by: Topi Pohjolainen (v1)
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 7 +++
1 file changed,
---
src/intel/compiler/brw_eu_validate.c| 64 -
src/intel/compiler/test_eu_validate.cpp | 122
2 files changed, 185 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index 000a05cb6ac..2
Thank you for the advice.
James
From: Marek Olšák
Sent: Monday, February 11, 2019 4:56 PM
To: Zhu, James
Cc: mesa-dev@lists.freedesktop.org; jzh...@gmail.com
Subject: Re: [Mesa-dev] [PATCH v4 5/5] gallium/auxiliary/vl: Add video
compositor compute shader render
This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.
Vulkan 1.1.81 spec says that "the application must ensure (using scissor
if neccesary) that all renderin
On Tue, 2019-02-12 at 11:31 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 10:48 AM Juan A. Suarez Romero
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> >
> > was created inheriting from the primary buffer, but with the framebuffer
> >
> > set to NU
From: Marek Olšák
initialize all non-compute context functions to NULL.
v2: fix SI
---
src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
src/gallium/drivers/radeonsi/si_clear.c | 7 +-
src/gallium/drivers/radeonsi/si_compute.c | 15 +--
src/gallium/drivers/radeonsi/si_descripto
On Tue, 2019-02-12 at 09:38 -0800, Caio Marcelo de Oliveira Filho wrote:
> Hi Juan,
>
> On Tue, Feb 12, 2019 at 04:37:23PM +0100, Juan A. Suarez Romero wrote:
> > On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> > > I had a chat with Caio about this and I'm skeptical. In general, users
From: Marek Olšák
---
src/gallium/auxiliary/util/u_tests.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_tests.c
b/src/gallium/auxiliary/util/u_tests.c
index 365d4fa8f17..7b87337bb98 100644
--- a/src/gallium/auxiliary/util/u_tests.c
+++
Just saw your patch. I'll review that one then :-)
On Tue, Feb 12, 2019 at 09:38:32AM -0800, Caio Marcelo de Oliveira Filho wrote:
> Hi Juan,
>
> On Tue, Feb 12, 2019 at 04:37:23PM +0100, Juan A. Suarez Romero wrote:
> > On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> > > I had a chat
On Tue, Feb 12, 2019 at 04:38:04PM +0100, Juan A. Suarez Romero wrote:
> In opt_peel_initial_if optimization, when moving the continue list to
> end of the continue block, before the jump, could happen that the
> continue list itself also ends with a jump.
>
> This would mean that we would have tw
https://bugs.freedesktop.org/show_bug.cgi?id=109201
--- Comment #15 from Alexander ---
unfortunately still the same
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
---
src/compiler/nir/nir_opt_if.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 9afb901be14..170caaad89d 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -96,7 +96,7 @@
Fixes: 19064b8c "nir: Add a pass for gathering transform feedback info"
Cc: Alejandro Piñeiro
---
src/compiler/nir/nir_gather_xfb_info.c | 44 ++
1 file changed, 44 insertions(+)
diff --git a/src/compiler/nir/nir_gather_xfb_info.c
b/src/compiler/nir/nir_gather_xfb_info.c
Add compute shader initilization, assign and cleanup in vl_compositor API.
Set video compositor compute shader render as default when pipe support it.
Signed-off-by: James Zhu
Reviewed-by: Christian König
---
src/gallium/auxiliary/vl/vl_compositor.c | 106 +++
src/ga
Stop using 12.12 quantization for viewports that are not contained in
the lower 4k corner of the render target as the hardware needs to keep
both absolute and relative coordinates representable.
---
.../drivers/radeonsi/si_state_viewport.c | 30 +--
1 file changed, 28 insertio
https://bugs.freedesktop.org/show_bug.cgi?id=109107
--- Comment #6 from Michael Eagle ---
I can confirm that now chrome is no longer printing
ERROR:vaapi_wrapper.cc(568)] : vaQueryConfigProfiles returned: 14
in terminal, and chrome://media-internals/ reports:
video_decoder GpuVideoDecoder
So,
Hello Marek, Timo, Nicolai,
Timo SOLVED this long-standing NIR corruption on Polaris with his 'nir:
rewrite varying component packing' commit.
It was triggered with
commit 86b52d42368ac496fe24bc6674e754c323381635
Author: Marek Olšák
Date: Fri Jul 13 00:23:36 2018 -0400
radeonsi: reduc
From page 76 (page 80 of the PDF) of the GLSL 4.60 v.5 spec:
" No aliasing in output buffers is allowed: It is a compile-time or
link-time error to specify variables with overlapping transform
feedback offsets."
Currently, this is expected to fail, but it succeeds:
"
...
la
Pushed, thanks!
Marek
On Tue, Feb 12, 2019 at 2:55 PM Oscar Blumberg wrote:
> Stop using 12.12 quantization for viewports that are not contained in
> the lower 4k corner of the render target as the hardware needs to keep
> both absolute and relative coordinates representable.
> ---
> .../drive
Hi List,
Mesa 19.0-rc3 is now available.
Due to a bug I discovered in the script that scrapes for stable nominations
(after uploading the tarball) there is basically nothing in the -rc3 release. As
a result I'm planning to make a -rc4 tomorrow. You can see the staging/19.0
branch to see the addit
https://bugs.freedesktop.org/show_bug.cgi?id=109617
Bug ID: 109617
Summary: Gallium OpenCL: While-If Problem with Booleans
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109617
--- Comment #2 from Jan Vesely ---
results:
xxx
Correct executionxx
xxx
---
bool flag = false;
#defi
1 - 100 of 142 matches
Mail list logo
