Reviewed-by: Jason Ekstrand
---
src/compiler/nir/nir.h| 1 +
src/compiler/nir/nir_opt_algebraic.py | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index db935c8496b..25ed64aa73c 100644
--- a/src/compiler/nir/nir.h
+++
The hardware doesn't support half-float for these.
---
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 aa6788b9fe5..e0027f5179c 100644
--- a/src/intel/compiler/brw_nir.c
+++
---
src/compiler/shader_info.h| 1 +
src/compiler/spirv/spirv_to_nir.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 65bc0588d67..0a3cb37069c 100644
--- a/src/compiler/shader_info.h
+++
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 we have,
but instead add to it.
---
Reviewed-by: Jason Ekstrand
---
src/compiler/nir/nir.h| 1 +
src/compiler/nir/nir_opt_algebraic.py | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 25ed64aa73c..65a1f60c3c6 100644
--- a/src/compiler/nir/nir.h
+++
Broadwell hardware has a bug that manifests in SIMD8 executions of
16-bit MAD instructions when any of the sources is a Y or W component.
We pack these components in the same SIMD register as components X and
Z respectively, but starting at offset 16B (so they live in the second
half of the
---
src/intel/compiler/brw_fs_nir.cpp | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 3eba8a478f5..559b55a0f84 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++
The PRM states that half-float operands are supported since gen9.
---
src/intel/compiler/brw_eu_emit.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 4630b83b1a0..5f066d17a1f 100644
---
v2: fix huge_val for 16-bit, it was mean't to be 2^14 not 10^14.
---
src/compiler/spirv/vtn_glsl450.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 9cda80c5137..f05531dbad6
Hi,
this series implements support for VK_KHR_shader_float16_int8 for Intel
platforms (Broadwell and later). This extension enables Vulkan applications
to consume SPIR-V shaders that use Float16 and Int8 types in shader code,
extending the functionality included with VK_KHR_16bit_storage and
---
src/compiler/spirv/vtn_glsl450.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index e85123725da..4345c9c61a3 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@
---
src/compiler/spirv/vtn_glsl450.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 06a49e48e3f..e85123725da 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++
Reviewed-by: Jason Ekstrand
---
src/compiler/spirv/vtn_glsl450.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index f05531dbad6..8bdef9db822 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++
---
src/compiler/spirv/vtn_glsl450.c | 36 +---
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 4345c9c61a3..9cda80c5137 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs_nir.cpp | 41 +++
1 file changed, 41 insertions(+)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 6eb68794f58..7294f49ddc0 100644
---
On Mon, Dec 3, 2018 at 7:49 PM Jason Ekstrand wrote:
>
> Jordan has requested to be made an Owner of the mesa project. As much as I
> may be the guy who pushed to get everything set up, I don't want to do this
> sort of thing on my own. As such, I'm asking for some ACKs. If I can get 5
>
Jason Ekstrand writes:
> Jordan has requested to be made an Owner of the mesa project. As much as I
> may be the guy who pushed to get everything set up, I don't want to do this
> sort of thing on my own. As such, I'm asking for some ACKs. If I can get
> 5 ACKs (at least 2 non-intel) from
Ack.
On Mon, Dec 3, 2018, 7:49 PM Jason Ekstrand Jordan has requested to be made an Owner of the mesa project. As much as
> I may be the guy who pushed to get everything set up, I don't want to do
> this sort of thing on my own. As such, I'm asking for some ACKs. If I can
> get 5 ACKs (at
Hi Dylan,
The architecture name in Debian is definitely ppc64el (not ppc64le).
However, it's the IBM Power platform (POWER8) running in little endian mode
(which yes, is confusing).
https://wiki.debian.org/ppc64el
https://wiki.debian.org/ArchiveQualification/ppc64el
FWIW: Apparently there's
On Tue, Dec 4, 2018 at 10:49 AM Jason Ekstrand wrote:
>
> Jordan has requested to be made an Owner of the mesa project. As much as I
> may be the guy who pushed to get everything set up, I don't want to do this
> sort of thing on my own. As such, I'm asking for some ACKs. If I can get 5
>
Lots of discussion here. :) I hoped to just dip our toes into the
merge request stream, but the consensus is clearly against my idea. Oh
well. :)
Here's what I gathered from the discussion:
== Keep email, allow duplicate MR, my idea ==
I don't think anyone else was in favor of this. Several
Seems like a pretty good sum-up of the discussion to me.
On Mon, Dec 3, 2018 at 7:50 PM Jordan Justen
wrote:
> Lots of discussion here. :) I hoped to just dip our toes into the
> merge request stream, but the consensus is clearly against my idea. Oh
> well. :)
>
> Here's what I gathered from
On Mon, Dec 3, 2018 at 8:06 AM Emil Velikov
wrote:
> Hi Gurchetan,
>
> On Thu, 29 Nov 2018 at 23:41, Gurchetan Singh
> wrote:
> >
> > Does this require libdrm 2.4.95 for virtio-gpu? With
> > platform_surfaceless, I keep getting "DRI2: failed to find EGLDevice"
> > and the failure is happening
Den tir. 20. nov. 2018 kl. 09:15 skrev Timothy Arceri :
>
> ---
> src/compiler/nir/nir_opt_loop_unroll.c | 74 ++
> 1 file changed, 28 insertions(+), 46 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
> b/src/compiler/nir/nir_opt_loop_unroll.c
> index
Ping!
On 20/11/18 7:14 pm, Timothy Arceri wrote:
This series add support for partial loop unrolling for loops with an
unknown trip count. The new partial_unroll function allows the caller
to specifiy how may times the loop should be unrolled and then the
loop is inserted in the innermost
From the Skylake PRM, Extended Math Function:
"The execution size must be no more than 8 when half-floats
are used in source or destination operand."
Earlier generations do not support Extended Math with half-float.
---
src/intel/compiler/brw_fs.cpp | 30 +++---
1
Section Register Region Restriction of the 3D Media GPGPU chapter states:
"Conversion between Integer and HF (Half Float) must be DWord
aligned and strided by a DWord on the destination."
The same restriction shows up in all hardware platforms that support
half-float, however, empirical
This optimization depends on two other optimization passes: the
constant propagation pass, which allows immediate propagation
on MAD/LRP instructions even though the hardware can't do it,
and the combine constants pass to fix this up afterwards for the
cases that we could not optimize here.
Also,
From: Samuel Iglesias Gonsálvez
It is not supported directly in the HW, we need to convert to a 32-bit
type first as intermediate step.
v2 (Iago): handle conversions from 64-bit integers as well
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs_nir.cpp | 42
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
We were assuming 32-bit elements.
---
src/intel/compiler/brw_fs_generator.cpp | 34 +
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/src/intel/compiler/brw_fs_generator.cpp
b/src/intel/compiler/brw_fs_generator.cpp
index 08dd83dded7..bffd9bc4787 100644
---
include/vulkan/vulkan_core.h | 109 +++--
src/vulkan/registry/vk.xml | 130 +++
2 files changed, 204 insertions(+), 35 deletions(-)
diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
index
---
src/intel/vulkan/anv_pipeline.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 5b583c28582..d55e51adcbb 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -147,6 +147,7 @@
---
src/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index caf25ad8a03..17b73c115cd 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -971,7 +971,7 @@
---
src/compiler/shader_info.h| 1 +
src/compiler/spirv/spirv_to_nir.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 0a3cb37069c..e745cc15fc5 100644
--- a/src/compiler/shader_info.h
+++
Now that this case only handles 64-bit destinations we can simplify
a bit the code.
---
src/intel/compiler/brw_fs_nir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 6c765fc2661..3eba8a478f5
There are hardware restrictions that need to be considered.
---
src/intel/compiler/brw_fs_nir.cpp | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index c1ba799d59c..4f815fef891
---
src/intel/compiler/brw_fs_copy_propagation.cpp | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/src/intel/compiler/brw_fs_copy_propagation.cpp
b/src/intel/compiler/brw_fs_copy_propagation.cpp
index 0f0284115fb..3d0fe883324 100644
---
These need to be implemented in two steps using an intermediary type.
---
src/intel/compiler/brw_fs_nir.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 559b55a0f84..c1ba799d59c 100644
---
src/compiler/nir/nir_opt_algebraic.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index 6c3b77c9b6e..747f1751086 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++
We are now using these bits, so don't assert that they are not set, just
avoid compaction in that case.
---
src/intel/compiler/brw_eu_compact.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_compact.c
b/src/intel/compiler/brw_eu_compact.c
index
3-src instructions don't support immediates, but since 36bc5f06dd22,
we allow them on MAD and LRP relying on the combine constants pass to
fix it up later. However, that pass is specialized for 32-bit float
immediates and can't handle HF constants at present, so this patch
ensures that
---
src/compiler/spirv/vtn_glsl450.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 8bdef9db822..85851755aab 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++
---
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 db3a8812ae3..7a4594a24ac 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++
---
src/intel/compiler/brw_fs.cpp | 46 +--
1 file changed, 33 insertions(+), 13 deletions(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 9ea67975e1e..32e0817ce02 100644
--- a/src/intel/compiler/brw_fs.cpp
+++
Since we handle booleans as integers this makes more sense.
---
src/intel/compiler/brw_fs_nir.cpp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 9f3d3bf9762..6c765fc2661 100644
---
The implementation of these opcodes in the generator assumes that their
arguments are packed, and it generates register regions based on that
assumption. While this expectation is reasonable for 32-bit, when we
load 16-bit elements from UBOs we get them with a stride of 2 that we
then need to pack
---
src/intel/vulkan/anv_device.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 6b5ba25c6bc..caf25ad8a03 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -966,6 +966,15 @@ void
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_compiler.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/compiler/brw_compiler.c
b/src/intel/compiler/brw_compiler.c
index f885e79c3e6..04a1a7cac4e 100644
--- a/src/intel/compiler/brw_compiler.c
+++
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 hardware only has two bits to specify the horizontal stride, so the
maximum horizontal stride we can use is 4. The pass calculates strides
based on the sizes of the types involved, and for conversions between
64-bit and 8-bit types that can lead to strides of 8.
The compiler should make sure
There is a hardware restriction where <0,1,0>:HF in Align16 doesn't replicate
a single 16-bit channel, but instead it replicates a full 32-bit channel.
---
.../compiler/brw_fs_combine_constants.cpp | 24 +--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git
---
src/intel/compiler/brw_fs_nir.cpp | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 4f815fef891..3f98c6a4474 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++
---
src/intel/compiler/brw_fs_cmod_propagation.cpp | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp
b/src/intel/compiler/brw_fs_cmod_propagation.cpp
index 7bb5c9afbc9..dfef9d720a2 100644
---
---
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 5f066d17a1f..2c9fc9a5c7c 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@
---
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 ffbec90d3fe..a3365b7e34c 100644
--- a/src/intel/compiler/brw_reg_type.h
+++
---
src/intel/vulkan/anv_extensions.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/anv_extensions.py
b/src/intel/vulkan/anv_extensions.py
index 7c81228f705..9ca42d998ef 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -104,6
We use ALign16 mode for this, since it is more convenient, but the PRM
for Broadwell states in Volume 3D Media GPGPU, Chapter 'Register region
restrictions', Section '1. Special Restrictions':
"In Align16 mode, the channel selects and channel enables apply to a
pair of half-floats, because
---
src/intel/vulkan/anv_pipeline.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index ee37685fccf..5b583c28582 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -146,6 +146,7 @@
This is available since gen8.
---
src/intel/compiler/brw_reg_type.c | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_reg_type.c
b/src/intel/compiler/brw_reg_type.c
index 60240ba1513..72295a2bd75 100644
---
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.
---
src/intel/compiler/brw_shader.cpp | 20
1 file changed, 20 insertions(+)
diff --git
Extended math desn't support half-float on these generations.
---
src/intel/compiler/brw_nir.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index e0027f5179c..0b3094724c4 100644
---
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
Particularly, we need the same lowewrings we use for 16-bit
integers.
---
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 0b3094724c4..0a5aa35c700 100644
---
---
.../compiler/brw_fs_combine_constants.cpp | 60 +++
1 file changed, 49 insertions(+), 11 deletions(-)
diff --git a/src/intel/compiler/brw_fs_combine_constants.cpp
b/src/intel/compiler/brw_fs_combine_constants.cpp
index e0c95d379b8..24307e365ab 100644
---
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 Ekstrand
---
src/compiler/nir/nir_builtin_builder.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_builtin_builder.h
b/src/compiler/nir/nir_builtin_builder.h
index 0e5b9db462a..1f5a1a12533 100644
---
---
src/compiler/spirv/vtn_glsl450.c | 48 ++--
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 85851755aab..bb340c87416 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++
The 16-bit polynomial execution doesn't meet Khronos precision requirements.
Also, the half-float denorm range starts at 2^(-14) and with asin taking input
values in the range [0, 1], polynomial approximations can lead to flushing
relatively easy.
An alternative is to use the atan2 formula to
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_compiler.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/compiler/brw_compiler.c
b/src/intel/compiler/brw_compiler.c
index fe632c5badc..f885e79c3e6 100644
--- a/src/intel/compiler/brw_compiler.c
+++
This just broke for me locally:
../mesa/src/mesa/state_tracker/st_glsl_to_tgsi.cpp: In member function
‘virtual void glsl_to_tgsi_visitor::visit(ir_call*)’:
../mesa/src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4075:9: error:
‘ir_intrinsic_begin_fragment_shader_ordering’ was not declared in this
Quoting Bas Nieuwenhuizen (2018-12-03 14:14:19)
> On Mon, Dec 3, 2018 at 7:30 PM Jan Vesely wrote:
> >
> > On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote:
> > > Cc: Emil Velikov
> > > Cc: Andres Gomez
> > > Cc: Juan A. Suarez Romero
> > > Cc: Dylan Baker
> > > Signed-off-by: Eric
Jordan has requested to be made an Owner of the mesa project. As much as I
may be the guy who pushed to get everything set up, I don't want to do this
sort of thing on my own. As such, I'm asking for some ACKs. If I can get
5 ACKs (at least 2 non-intel) from other Owners and no NAKs, I'll click
On Mon, Dec 3, 2018 at 7:05 PM Ilia Mirkin wrote:
> On Mon, Dec 3, 2018 at 7:49 PM Jason Ekstrand
> wrote:
> >
> > Jordan has requested to be made an Owner of the mesa project. As much
> as I may be the guy who pushed to get everything set up, I don't want to do
> this sort of thing on my own.
Ping! on the series
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hey,
On Monday, 3 December 2018 12:15:17 CET Erik Faye-Lund wrote:
> Yeah. An important thing to note is that virgl is pretty widely tested
> by now, and we don't see this pop up in other places... And that sounds
> a bit strange to me.
Good to know, I don't actually know how wide virgl is
Build mesa 9463 completed
Commit dd53bb7e1f by Matt Turner on 12/4/2018 12:20 AM:
Revert "st/mesa: silenced unhanded enum warning in st_glsl_to_tgsi.cpp"\n\nThis reverts commit 198c50f4873758e9f64d89eea262af5dd1644df9.\n\nThis needs to be reverted after commit
This adds support needed for marking the varyings as used but we
don't actually support packing patches in this patch.
---
src/compiler/nir/nir_linking_helpers.c | 73 ++
1 file changed, 51 insertions(+), 22 deletions(-)
diff --git a/src/compiler/nir/nir_linking_helpers.c
There are three reasons for the rewrite.
1. Adding support for packing tess patch varyings in a sane way.
2. Making use of qsort allowing the code to be much easier to
follow.
3. Adding a crude live range analysis for deciding which components
should be packed together.
We could simplify
This was used for implementing FBFETCH. However that uses TXF, which
doesn't do much with a TSC. The only important bit is that sRGB-decoding
works as expected, which we can achieve since all samplers we ever
generate enable sRGB-decoding. Always point to entry 0 in the TSC table,
and ensure that
Same as on nv50, the TXF op always uses the TSC bound to slot 0,
returning blank values if nothing is bound.
An earlier change arranges for the TSC entries list to always have valid
data at entry 0, so here we just make use of it.
Fixes arb_texture_buffer_object-subdata-sync among others.
Jordan Justen writes:
> Lots of discussion here. :) I hoped to just dip our toes into the
> merge request stream, but the consensus is clearly against my idea. Oh
> well. :)
>
> Here's what I gathered from the discussion:
>
> == Keep email, allow duplicate MR, my idea ==
>
> I don't think anyone
https://bugs.freedesktop.org/show_bug.cgi?id=108922
Alexandre Demers changed:
What|Removed |Added
Summary|Meson: crosscompiling with |Meson: crosscompiling with
https://bugs.freedesktop.org/show_bug.cgi?id=108922
Alexandre Demers changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
Previously the code to load from a constant instruction was always
using the u32 pointer. If the constant is actually a 16-bit source
this would end up with the wrong values because the pointer would be
offset by the wrong size. This fixes it to use the u16 pointer.
---
The commit aa0fed10d35 moved a bunch of Freedreno code to a common
directory. The previous directory had a .dir-locals file for Emacs.
This patch copies it to the new directory as well.
---
src/freedreno/.dir-locals.el | 8
1 file changed, 8 insertions(+)
create mode 100644
On Fri, 2018-11-30 at 18:15 -0500, Marek Olšák wrote:
> On Fri, Nov 30, 2018 at 5:57 PM Ian Romanick
> wrote:
> > On 11/30/2018 02:17 PM, Marek Olšák wrote:
> > >
> > >
> > > On Fri, Nov 23, 2018 at 5:54 AM Erik Faye-Lund
> > > > erik.faye-l...@collabora.com>> wrote:
> > >
> > > S3_s3tc
https://bugs.freedesktop.org/show_bug.cgi?id=108925
Bug ID: 108925
Summary: vkCmdCopyQueryPoolResults(VK_QUERY_RESULT_WAIT_BIT)
for timestamps with large query count hangs
Product: Mesa
Version: git
Hardware: Other
Cc: Emil Velikov
Cc: Andres Gomez
Cc: Juan A. Suarez Romero
Cc: Dylan Baker
Signed-off-by: Eric Engestrom
---
This patch depends on the releasing procedure in docs/releasing.html to
be updated to not rely on autotools anymore.
I think our release managers (cc'ed) should work together and
https://bugs.freedesktop.org/show_bug.cgi?id=108914
--- Comment #11 from Samuel Pitoiset ---
Interesting to see that RADV_DEBUG=nofastclears also fixes the problem. Totally
unexpected to be honest.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=108925
--- Comment #1 from Alex Smith ---
FWIW, doesn't occur on AMDVLK. As far as I can see, that is just using a
barrier rather than waiting for each individual query value to be available.
Also, it looks like RADV is only waiting on the low 32
https://bugs.freedesktop.org/show_bug.cgi?id=108927
Richard changed:
What|Removed |Added
Priority|medium |highest
--- Comment #1 from Richard ---
https://bugs.freedesktop.org/show_bug.cgi?id=108927
Bug ID: 108927
Summary: anaconda3 spyder fails to launch on Centos 7
Product: Mesa
Version: 11.0
Hardware: x86-64 (AMD64)
OS: other
Status: NEW
On Fri, 2018-11-30 at 07:06 +0100, Mathias Fröhlich wrote:
> Good Morning,
>
> On Tuesday, 27 November 2018 10:17:07 CET Erik Faye-Lund wrote:
> > On Tue, 2018-11-27 at 07:11 +0100, Mathias Fröhlich wrote:
> > > Hi Erik,
> > >
> > > > > On Monday, 26 November 2018 19:39:50 CET Erik Faye-Lund
> >
Hi Gurchetan,
On Thu, 29 Nov 2018 at 23:41, Gurchetan Singh
wrote:
>
> Does this require libdrm 2.4.95 for virtio-gpu? With
> platform_surfaceless, I keep getting "DRI2: failed to find EGLDevice"
> and the failure is happening in "drmGetDevice2(fd, 0, )".
virtio-gpu should work fine with
---
include/vulkan/vulkan_core.h | 109 +++--
src/vulkan/registry/vk.xml | 130 +++
2 files changed, 204 insertions(+), 35 deletions(-)
diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
index
Eric Engestrom writes:
> Cc: Emil Velikov
> Cc: Andres Gomez
> Cc: Juan A. Suarez Romero
> Cc: Dylan Baker
> Signed-off-by: Eric Engestrom
> ---
> This patch depends on the releasing procedure in docs/releasing.html to
> be updated to not rely on autotools anymore.
>
> I think our release
https://bugs.freedesktop.org/show_bug.cgi?id=108922
--- Comment #3 from Alexandre Demers ---
It seems I missed last week's memo about the cross file. ;) I'll try it and
I'll update this bug accordingly in the next few days.
Thank you about the cue on env var VS meson's flags, I'm new to meson
Eric Anholt writes:
> [ Unknown signature status ]
> Eric Engestrom writes:
>
>> Cc: Emil Velikov
>> Cc: Andres Gomez
>> Cc: Juan A. Suarez Romero
>> Cc: Dylan Baker
>> Signed-off-by: Eric Engestrom
>> ---
>> This patch depends on the releasing procedure in docs/releasing.html to
>> be
Before this commit, there were two copies of the algorithm: one in C,
that we would use to figure out what bit-size to give the replacement
expression, and one in Python, that emulated the C one and tried to
prove that the C algorithm would never fail to correctly assign
bit-sizes. That seemed
1 - 100 of 161 matches
Mail list logo