Reviewed-by: Jason Ekstrand
On Thu, Apr 25, 2019 at 9:50 PM Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes a case where we are expecting 64-bit but generate
> 32-bit consts and validate gets angry.
>
> Signed-off-by: Dave Airlie
> ---
> src/compiler/nir/nir_lower_indirect_derefs.c |
From: Dave Airlie
This fixes a case where we are expecting 64-bit but generate
32-bit consts and validate gets angry.
Signed-off-by: Dave Airlie
---
src/compiler/nir/nir_lower_indirect_derefs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
> iand and ior are commutative, so you don't need both.
--Wait, woaaah, the algebraic generator respects that? Super neat, thank
you!
> Especially without instruction count data
(I'm assuming I won't be able to do shader-db on my hw at this point..)
> For example, if the only use of
> We can support all of these with source modifiers because the above three
> aren't really "dest invertable"... For us, they'd be
>
> ~src0 | ~src1
> ~src0 & ~src1
> ~src0 ^ ~src1
>
> Is it really dest_invertable or both_srcs_invertable? :-)
Sure, I wasn't sure how other drivers would want to
From: Marek Olšák
src/mesa/state_tracker/st_tgsi_lower_yuv.c:68: void reg_dst(struct
tgsi_full_dst_register *, const struct tgsi_full_dst_register *, unsigned
int): assertion "dst->Register.WriteMask" failed
Cc: 19.0
---
src/mesa/state_tracker/st_tgsi_lower_yuv.c | 46 +-
From: Marek Olšák
It's done by:
- decrease the number of frames in flight by 1
- flush before throttling in SwapBuffers
(instead of wait-then-flush, do flush-then-wait)
The improvement is apparent with Unigine Heaven.
Previously:
draw frame 2
wait frame 0
flush frame 2
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_fence.c
b/src/gallium/drivers/radeonsi/si_fence.c
index 3d23597413c..ffda98d2834 100644
---
On 4/25/19 3:37 PM, Alyssa Rosenzweig wrote:
> In addition to the familiar iand/ior/ixor, some architectures feature
> destination-inverted versions inand/inor/inxor. Certain
> architectures also have source-inverted forms, dubbed iandnot/iornot
> here. Midgard has the all of these opcodes
On Thu, Apr 25, 2019 at 5:37 PM Alyssa Rosenzweig
wrote:
> In addition to the familiar iand/ior/ixor, some architectures feature
> destination-inverted versions inand/inor/inxor. Certain
> architectures also have source-inverted forms, dubbed iandnot/iornot
> here. Midgard has the all of these
Alright, good to know, thank you! :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Thu, Apr 25, 2019 at 3:37 PM Alyssa Rosenzweig wrote:
>
> In addition to the familiar iand/ior/ixor, some architectures feature
> destination-inverted versions inand/inor/inxor. Certain
> architectures also have source-inverted forms, dubbed iandnot/iornot
> here. Midgard has the all of these
On Thu, Apr 25, 2019 at 6:37 PM Alyssa Rosenzweig wrote:
> Various combinations of these instructions are found on many
> architectures. They appear directly as-is on Midgard; some of them
> should be implementable on Intel Gen8+ via the source modifiers; I was
> told over IRC that AMD/Nouveau
I ran this via the intel-ci and it has 0 regressions, I've also looked
at this before in v1.
Reviewed-by: Dave Airlie
On Tue, 23 Apr 2019 at 06:08, Marek Olšák wrote:
>
> Ping. Thanks.
>
> On Tue, Apr 16, 2019 at 10:16 AM Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> This fixes
Thanks!
Quoting Timothy Arceri (2019-04-25 15:36:44)
> On 26/4/19 6:50 am, Dylan Baker wrote:
> > Hi Tim,
> >
> > I had to make a couple of small tweaks to get this to apply against 19.0
> > (namely
> > that the glsl_type_is_struct -> glsl_type_is_struct_or_ifc doesn't exist in
> > 19.0), could
Awesome, thanks.
Quoting Marek Olšák (2019-04-25 14:50:52)
> Thanks. It looks good.
>
> Marek
>
> On Thu, Apr 25, 2019, 5:17 PM Dylan Baker wrote:
>
> Hi Marek,
>
> I've tried to apply this to 19.0, I had to pull "radeonsi: add
> si_debug_options
> for convenient
In addition to the familiar iand/ior/ixor, some architectures feature
destination-inverted versions inand/inor/inxor. Certain
architectures also have source-inverted forms, dubbed iandnot/iornot
here. Midgard has the all of these opcodes natively. Many arches have
comparible features to implement
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 5 +
src/gallium/drivers/panfrost/midgard/midgard_compile.h | 5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
Various combinations of these instructions are found on many
architectures. They appear directly as-is on Midgard; some of them
should be implementable on Intel Gen8+ via the source modifiers; I was
told over IRC that AMD/Nouveau might have some of these as well. Rather
than forcing backends to
On 26/4/19 6:50 am, Dylan Baker wrote:
Hi Tim,
I had to make a couple of small tweaks to get this to apply against 19.0 (namely
that the glsl_type_is_struct -> glsl_type_is_struct_or_ifc doesn't exist in
19.0), could you take a look at the patch in the staging/19.0 branch and let me
know if it
Thanks. It looks good.
Marek
On Thu, Apr 25, 2019, 5:17 PM Dylan Baker wrote:
> Hi Marek,
>
> I've tried to apply this to 19.0, I had to pull "radeonsi: add
> si_debug_options
> for convenient adding/removing of options", which is fine, but this patch
> also
> assumes your si compute-queue
https://bugs.freedesktop.org/show_bug.cgi?id=107022
zefkerri...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Marek,
I've tried to apply this to 19.0, I had to pull "radeonsi: add si_debug_options
for convenient adding/removing of options", which is fine, but this patch also
assumes your si compute-queue only patches, which aren't present in 19.0. I've
made a small change to get it compiling, but I'm
Hi Tim,
I had to make a couple of small tweaks to get this to apply against 19.0 (namely
that the glsl_type_is_struct -> glsl_type_is_struct_or_ifc doesn't exist in
19.0), could you take a look at the patch in the staging/19.0 branch and let me
know if it looks okay?
Thanks,
Dylan
Quoting
https://bugs.freedesktop.org/show_bug.cgi?id=110456
Bas Nieuwenhuizen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110439
Bug 110439 depends on bug 110456, which changed state.
Bug 110456 Summary: Land YCBCR extensions
https://bugs.freedesktop.org/show_bug.cgi?id=110456
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=110516
Volker Enderlein changed:
What|Removed |Added
Attachment #144094|0 |1
is obsolete|
czw., 25 kwi 2019 o 20:11 Gustaw Smolarczyk napisał(a):
>
> czw., 25 kwi 2019 o 19:42 Emil Velikov napisał(a):
> >
> > The function is analogous to lp_fence_wait() while taking at timeout
> > (ns) parameter, as needed for EGL fence/sync.
> >
> > v2:
> > - use absolute UTC time, as per spec
https://bugs.freedesktop.org/show_bug.cgi?id=110516
Bug ID: 110516
Summary: OpenGLCurveEvaluator does not return affine
coordinates
Product: Mesa
Version: 19.0
Hardware: All
OS: All
Status: NEW
czw., 25 kwi 2019 o 19:42 Emil Velikov napisał(a):
>
> The function is analogous to lp_fence_wait() while taking at timeout
> (ns) parameter, as needed for EGL fence/sync.
>
> v2:
> - use absolute UTC time, as per spec (Gustaw)
> - bail out on cnd_timedwait() failure (Gustaw)
>
> Cc: Gustaw
https://bugs.freedesktop.org/show_bug.cgi?id=110356
--- Comment #5 from Fabio Pedretti ---
Any plan to backport these (up to 5d310015) to 18.3 (I know it is EOL) and
release a 18.3.7?
See Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926857
--
You are receiving this mail
Currently if the timeout differs from 0, we'll end up with infinite
wait... even if the user is perfectly clear they don't want that.
Use the new lp_fence_timedwait() helper guarding both waits in an
!lp_fence_signalled block like the rest of llvmpipe.
Signed-off-by: Emil Velikov
Reviewed-by:
The function is analogous to lp_fence_wait() while taking at timeout
(ns) parameter, as needed for EGL fence/sync.
v2:
- use absolute UTC time, as per spec (Gustaw)
- bail out on cnd_timedwait() failure (Gustaw)
Cc: Gustaw Smolarczyk
Cc: Roland Scheidegger
Signed-off-by: Emil Velikov
From: Tomasz Figa
If there is no last fence, due to no rendering happening yet, just
create a new signaled fence and return it, to match the expectations of
the EGL sync fence API.
Fixes random "Could not create sync fence 0x3003" assertion failures from
Skia on Android, coming from the
On Tue, 16 Apr 2019 at 11:50, Gustaw Smolarczyk wrote:
>
> wt., 16 kwi 2019 o 12:11 Emil Velikov napisał(a):
> >
> > On Thu, 11 Apr 2019 at 17:55, Gustaw Smolarczyk
> > wrote:
> > >
> > > czw., 11 kwi 2019 o 18:06 Emil Velikov
> > > napisał(a):
> > > >
> > > > The function is analogous to
Mesa already keeps track of the GLES precision for variables and stores
it in the ir_variable. When no precision is explicitly specified it
takes the default precision for the corresponding type. However, when
the variable is a struct or interface, the precision of each individual
member is
Hi all,
the following patches contain code to implement all vertex fetches
using plain, non-format loads plus explicit shader arithmetic for
format conversion.
This allows us to remove the software workaround for unaligned vertex
buffers on SI, because we can just load individual bytes on the
From: Nicolai Hähnle
Purely as a shorthand in the remainder of the function.
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
From: Nicolai Hähnle
The overall goal is to support unaligned loads from vertex buffers
natively on SI.
In the unaligned case, we fall back to the general case implementation in
ac_build_opencoded_load_format. Since this function is fully general,
we will also use it going forward for cases
From: Nicolai Hähnle
Implement software emulation of buffer_load_format for all types required
by vertex buffer fetches.
---
src/amd/common/ac_llvm_build.c | 313 +
src/amd/common/ac_llvm_build.h | 30
2 files changed, 343 insertions(+)
diff --git
r-b
On Thu, Apr 25, 2019 at 12:22 PM Emil Velikov wrote:
>
> On Fri, 19 Apr 2019 at 16:01, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > As effectively required by the extension, we need to ensure we're master
> >
> > Currently drivers employ vendor specific solutions, which check if
r-b
On Thu, Apr 25, 2019 at 12:22 PM Emil Velikov wrote:
>
> On Fri, 19 Apr 2019 at 16:03, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > Currently we get normal GEM handles from PrimeFDToHandle, yet we close
> > then with DUMB_CLOSE. Use GEM_CLOSE instead.
> >
> > Cc: Keith Packard
>
On 25.04.19 04:45, Marek Olšák wrote:
[snip]
- bool clear_db_cache_before_clear;
bool has_msaa_sample_loc_bug;
bool has_ls_vgpr_init_bug;
bool
On Fri, 19 Apr 2019 at 16:01, Emil Velikov wrote:
>
> From: Emil Velikov
>
> As effectively required by the extension, we need to ensure we're master
>
> Currently drivers employ vendor specific solutions, which check if the
> device behind the fd is capable*, yet none of them do the master
On Fri, 19 Apr 2019 at 16:03, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Currently we get normal GEM handles from PrimeFDToHandle, yet we close
> then with DUMB_CLOSE. Use GEM_CLOSE instead.
>
> Cc: Keith Packard
> Cc: Jason Ekstrand
> Cc: Bas Nieuwenhuizen
> Fixes: da997ebec92 ("vulkan:
On 2019-04-24 11:36 p.m., Marek Olšák wrote:
> It should be fixed by the patch "radeonsi: add BOs after need_cs_space".
Looks like that did the trick, thanks!
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa
Hi Christian,
Am Mittwoch, den 24.04.2019, 08:36 +0200 schrieb Christian Gmeiner:
> This patch series goes a complete different route then the one from
> Lucas Stach. I am using the integrated YUV tiler instead of using
> the 2D core for format conversion. I am reusing some patches from
> Lucas
On Thu, Apr 25, 2019 at 11:28:40AM +0800, zhoucm1 wrote:
>
>
> On 2019年04月25日 03:22, Eric Anholt wrote:
> > "Zhou, David(ChunMing)" writes:
> >
> > > Will linux be only mesa-linux? I thought linux is an open linux.
> > > Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> >
We will make use of this in the following commit.
---
src/gallium/drivers/radeonsi/si_shader.h | 1 +
src/gallium/drivers/radeonsi/si_shader_nir.c | 78 +++-
2 files changed, 43 insertions(+), 36 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.h
Some of the opts are not called in the general optimastion loop
in the state trackers glsl -> nir conversion. We need to call
the radeonsi specific optimisation once before scanning over
the nir otherwise we can end up gathering info on code that
is later removed.
Fixes an assert in the piglit
Reviewed-by: Samuel Pitoiset
Thanks fo the fix Tim!
On 4/25/19 3:17 AM, Timothy Arceri wrote:
We were only setting the used mask for the first component of a
varying. Since the linking opts split vectors into scalars this
has mostly worked ok.
However this causes an issue where for example
50 matches
Mail list logo
