This is:
Reviewed-by: Andres Gomez
On Fri, 2019-03-22 at 03:04 +, Vinson Lee wrote:
> Fix this build error with GCC 4.4.7.
>
> CC nir/nir_opt_copy_prop_vars.lo
> nir/nir_opt_copy_prop_vars.c: In function ‘load_element_from_ssa_entry_value’:
> nir/nir_opt_copy_prop_vars.c:454: error: u
From: Iago Toral Quiroga
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
in
From: Iago Toral Quiroga
---
src/intel/compiler/brw_fs.cpp | 65 +++
1 file changed, 65 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 2fc7793709b..3616a7afc31 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/in
CCing Iago and Curro.
On Fri, 2019-03-22 at 10:07 +0100, Juan A. Suarez Romero wrote:
> From: Iago Toral Quiroga
>
> ---
> src/intel/compiler/brw_fs.cpp | 65 +++
> 1 file changed, 65 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compi
CCing Iago and Curro.
On Fri, 2019-03-22 at 10:08 +0100, Juan A. Suarez Romero wrote:
> From: Iago Toral Quiroga
>
> 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
From: Iago Toral Quiroga
v2:
- Consider implicit conversions in 2-src instructions too (Curro)
- For restrictions that involve destination stride requirements
only validate them for Align1, since Align16 always requires
packed data.
- Skip general rule for the dst/execution type size rat
https://bugs.freedesktop.org/show_bug.cgi?id=110221
Bug ID: 110221
Summary: build error with meson
Product: Mesa
Version: git
Hardware: All
OS: Linux (All)
Status: NEW
Severity: normal
Priority:
From: Iago Toral Quiroga
v2:
- Adapted unit tests to make them consistent with the changes done
to the validation of half-float conversions.
---
src/intel/compiler/brw_eu_validate.c| 256 ++
src/intel/compiler/test_eu_validate.cpp | 620
2 files changed,
https://bugs.freedesktop.org/show_bug.cgi?id=110221
Fabio Pedretti changed:
What|Removed |Added
CC||baker.dyla...@gmail.com
--- Comment #1
https://bugs.freedesktop.org/show_bug.cgi?id=110211
--- Comment #13 from Benoit Pierre ---
Commenting on an issue does not add you to the CC list? How stupid is that...
--
You are receiving this mail because:
You are the QA Contact for the bug.___
mes
On 21/03/2019 19:04, Eric Anholt wrote:
I've just put up a new repo that I'm hoping to use to enable automatic
shader-db results for various drivers on Gitlab CI merge requests (and
maybe with some more work, delete the simulator backends of vc4 and v3d).
https://gitlab.freedesktop.org/anholt/dr
If the query is not available and VK_QUERY_RESULT_WAIT_BIT and
VK_QUERY_RESULT_PARTIAL_BIT are both not set, the spec doesn't
allow to modify its result.
From Vulkan spec:
"If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
both not set then no result values are written to pData for
If VK_QUERY_RESULT_WITH_AVAILABILY_BIT is set and
VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are both not
set, we need return to VK_NOT_READY only and set the availability
status field for each query.
From Vulkan spec:
"If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
This lowering isn't needed for RADV because AMDGCN has two
instructions. It will be disabled for RADV in an upcoming series.
While we are at it, factorize a little bit.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 1 +
src/compiler/Makefile.sources
Only the exponent needs to be 32-bit signed integer.
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_opcodes.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 9bbfe66ccdc..90f7aed0c0d 100644
Reviewed-by: Jason Ekstrand
The second will require non-trivial review.
On Fri, Mar 22, 2019 at 8:41 AM Samuel Pitoiset
wrote:
> Only the exponent needs to be 32-bit signed integer.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/compiler/nir/nir_opcodes.py | 4 ++--
> 1 file changed, 2 inser
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 24
src/amd/common/ac_llvm_build.h | 4
src/amd/common/ac_nir_to_llvm.c | 8 +---
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/comm
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 25 +
src/amd/common/ac_llvm_build.h | 4
src/amd/common/ac_nir_to_llvm.c | 4 ++--
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/
This extension allows 16-bit support to Frexp/FrexpStruct.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_extensions.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/vulkan/radv_extensions.py
b/src/amd/vulkan/radv_extensions.py
index 23106765c2a..e97f320e8a1 100644
--- a/s
Hardware has two instructions.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 19a807df199..eecbc6ae759 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vul
Mesa Gallium3D driver for ARM Mali 400/450 GPUs.
Lima is still in development and not ready for daily usage,
but can run some simple tests like kmscube and glamrk2, and some
single full screen application like kodi-gbm.
Mesa related EGL/GLX_EXT_buffer_age and EGL_KHR_partial_update
changes are no
This is needed for lima gp compiler.
Signed-off-by: Qiang Yu
---
src/compiler/nir/nir_intrinsics.py| 4 +--
src/compiler/nir/nir_lower_io.c | 2 +-
src/compiler/nir/nir_lower_io_to_scalar.c | 41 +--
3 files changed, 42 insertions(+), 5 deletions(-)
diff
This is for the case that user only know a max size
it wants to append to the array and enlarge the array
capacity before writing into it.
v2:
- rename newsize to newcap
- rename util_dynarray_enlarge to util_dynarray_grow_cap
Cc: Caio Marcelo de Oliveira Filho
Signed-off-by: Qiang Yu
---
src/
This helper function can be used by driver which
always need min/max index.
Signed-off-by: Qiang Yu
---
src/gallium/auxiliary/util/u_vbuf.c | 7 +++
src/gallium/auxiliary/util/u_vbuf.h | 3 +++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_vbuf.c
v2:
- return 0 for NaN too
Cc: Roland Scheidegger
Signed-off-by: Qiang Yu
---
src/util/u_math.h | 31 +++
1 file changed, 31 insertions(+)
diff --git a/src/util/u_math.h b/src/util/u_math.h
index e7dbbe5ca22..5e712dadb4a 100644
--- a/src/util/u_math.h
+++ b/src/util
Signed-of-by: Qiang Yu
---
include/drm-uapi/lima_drm.h | 169
1 file changed, 169 insertions(+)
create mode 100644 include/drm-uapi/lima_drm.h
diff --git a/include/drm-uapi/lima_drm.h b/include/drm-uapi/lima_drm.h
new file mode 100644
index 000..95a0
From: Rob Herring
Enable using lima for KMS renderonly. This still needs KMS driver
name mapping to kmsro to be used automatically.
Signed-off-by: Rob Herring
Signed-off-by: Qiang Yu
---
meson.build | 4 ++--
src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c
From: Rob Herring
Signed-off-by: Rob Herring
Signed-off-by: Qiang Yu
---
src/gallium/targets/dri/meson.build | 2 ++
src/gallium/targets/dri/target.c| 2 ++
2 files changed, 4 insertions(+)
diff --git a/src/gallium/targets/dri/meson.build
b/src/gallium/targets/dri/meson.build
index ff345
I'm confused. Don't we always have a NULL render target at location 0? Is
the problem really that we need the NULL render target or is it that we
can't throw away the alpha component of the RT write in the shader? If
it's that we can't throw away the alpha component of the RT write, then I'd
sug
> +
> +static bool gpir_lower_viewport_transform(gpir_compiler *comp)
> +{
> + gpir_node *rcpw = NULL;
> +
> + /* rcpw = 1 / w */
> + list_for_each_entry(gpir_block, block, &comp->block_list, list) {
> + list_for_each_entry(gpir_node, node, &block->node_list, list) {
> + if (node
On Fri, Mar 22, 2019 at 8:41 AM Samuel Pitoiset
wrote:
> This lowering isn't needed for RADV because AMDGCN has two
> instructions. It will be disabled for RADV in an upcoming series.
>
> While we are at it, factorize a little bit.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_
> + f->temp_write.dest = 0x03; // 11 - temporary
Maybe make a #define, enum
[poofs, again]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This lowering isn't needed for RADV because AMDGCN has two
instructions. It will be disabled for RADV in an upcoming series.
While we are at it, factorize a little bit.
v2: - use integer for zero instead of 32-bit float
- inline lower_frexp and tidy up the switch
- handle metadata in lowe
On Fri, Mar 22, 2019 at 11:10 AM Samuel Pitoiset
wrote:
> This lowering isn't needed for RADV because AMDGCN has two
> instructions. It will be disabled for RADV in an upcoming series.
>
> While we are at it, factorize a little bit.
>
> v2: - use integer for zero instead of 32-bit float
> - i
On 3/22/19 1:03 PM, Samuel Iglesias Gonsálvez wrote:
If the query is not available and VK_QUERY_RESULT_WAIT_BIT and
VK_QUERY_RESULT_PARTIAL_BIT are both not set, the spec doesn't
allow to modify its result.
From Vulkan spec:
"If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
bot
On 3/22/19 5:18 PM, Samuel Pitoiset wrote:
On 3/22/19 1:03 PM, Samuel Iglesias Gonsálvez wrote:
If the query is not available and VK_QUERY_RESULT_WAIT_BIT and
VK_QUERY_RESULT_PARTIAL_BIT are both not set, the spec doesn't
allow to modify its result.
From Vulkan spec:
"If VK_QUERY_RESULT_WAI
Does this fix anything known?
Does that rule also apply for CmdCopyQueryPoolResults()? If so, we might
need to fix it (I haven't looked yet).
With the comment on patch 1, series is:
Reviewed-by: Samuel Pitoiset
On 3/22/19 1:03 PM, Samuel Iglesias Gonsálvez wrote:
If VK_QUERY_RESULT_WITH_AV
Can you eventually merge all NIR patches now? We should be able to hook
up that extension for RADV quite soon.
On 2/12/19 12:55 PM, Iago Toral Quiroga wrote:
The changes in this version address review feedback to v3. The most significant
changes include:
1. A more generic constant combining pa
Yes, I think those should be fine to land now, they are very few
actually. Jason, any objections?
Iago
On Fri, 2019-03-22 at 17:26 +0100, Samuel Pitoiset wrote:
> Can you eventually merge all NIR patches now? We should be able to
> hook
> up that extension for RADV quite soon.
>
> On 2/12/19 12
On Fri, Mar 22, 2019 at 03:04:28AM +, Vinson Lee wrote:
> Fix this build error with GCC 4.4.7.
>
> CC nir/nir_opt_copy_prop_vars.lo
> nir/nir_opt_copy_prop_vars.c: In function ‘load_element_from_ssa_entry_value’:
> nir/nir_opt_copy_prop_vars.c:454: error: unknown field ‘ssa’ specified in
https://bugs.freedesktop.org/show_bug.cgi?id=110221
Dylan Baker changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Dylan Baker
On Fri, Mar 22, 2019 at 11:53 AM Iago Toral wrote:
> Yes, I think those should be fine to land now, they are very few
> actually. Jason, any objections?
>
None at all. Also, where are we at with the last few patches?
--Jason
> Iago
>
> On Fri, 2019-03-22 at 17:26 +0100, Samuel Pitoiset wrot
On Fri, 2019-03-22 at 12:47 -0500, Jason Ekstrand wrote:
> On Fri, Mar 22, 2019 at 11:53 AM Iago Toral
> wrote:
> > Yes, I think those should be fine to land now, they are very few
> >
> > actually. Jason, any objections?
>
> None at all. Also, where are we at with the last few patches?
Juan h
On Fri, Mar 22, 2019 at 1:13 PM Iago Toral wrote:
> On Fri, 2019-03-22 at 12:47 -0500, Jason Ekstrand wrote:
>
> On Fri, Mar 22, 2019 at 11:53 AM Iago Toral wrote:
>
> Yes, I think those should be fine to land now, they are very few
> actually. Jason, any objections?
>
>
> None at all. Also, wh
On Fri, 2019-03-22 at 13:23 -0500, Jason Ekstrand wrote:
> On Fri, Mar 22, 2019 at 1:13 PM Iago Toral wrote:
> > On Fri, 2019-03-22 at 12:47 -0500, Jason Ekstrand wrote:
> > > On Fri, Mar 22, 2019 at 11:53 AM Iago Toral
> > > wrote:
> > > > Yes, I think those should be fine to land now, they are
https://bugs.freedesktop.org/show_bug.cgi?id=110211
Dylan Baker changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=110221
Dylan Baker changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://bugs.freedesktop.org/show_bug.cgi?id=100316
Jordan Justen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
When we destroy a context, we need to temporarily make that context
the current one for the thread.
That's because during context tear-down we make many calls to
_mesa_reference_texobj(&texObj, NULL). Note there's no context
parameter. If the texture's refcount goes to zero and we need to
delete
Looks alright to me, it's all quite tricky stuff...
Reviewed-by: Roland Scheidegger
Am 22.03.19 um 20:51 schrieb Brian Paul:
> When we destroy a context, we need to temporarily make that context
> the current one for the thread.
>
> That's because during context tear-down we make many calls to
https://bugs.freedesktop.org/show_bug.cgi?id=109810
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109540
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
52 matches
Mail list logo
