On Thu, Jan 18, 2024 at 10:22 AM Stefan Dirsch wrote:
> I noticed that with version 23.3.x Mesa no longer can be built with python
> 2.6. It still worked with Mesa 23.2.1.
For anyone who got this far and was completely incredulous... this
(and the subject) is typo'd -- the problem is about
On Mon, Aug 28, 2023 at 8:25 AM Mike Blumenkrantz
wrote:
> Hi,
>
> As everyone has likely noticed, we've had a significant uptick of spam on
> Mesa-related IRC channels lately. Sometimes these occurrences go on for many
> hours before someone takes action.
>
> I'd like to request that all
In case it's useful for anyone, I've written a Google Apps Script that
allows me to filter notification emails based on X-GitLab headers.
It's available here
(https://github.com/mattst88/gmail-gitlab-filtering) and I'd be happy
to hear if it's useful for you.
Thanks,
Matt
On Fri, Sep 10, 2021 at 2:19 PM Timur Kristóf wrote:
> Matt Turner ezt írta (időpont: 2021. szept. 10., P
> 22:33):
>>
>> On Fri, Sep 10, 2021 at 10:20 AM Timur Kristóf
>> wrote:
>> >
>> > Hi,
>> >
>> > We've been recently worki
On Fri, Sep 10, 2021 at 10:20 AM Timur Kristóf wrote:
>
> Hi,
>
> We've been recently working on tracking down some "mysterious" crashes
> that some users experienced on distro builds of mesa but we couldn't
> reproduce locally, until we found out about _GLIBCXX_ASSERTIONS=1 which
> seems to be
: fix the debug parameter to properly handle --disable-debug
Matt Turner (2):
Remove glu_mangle.h
glu 9.0.2
Nicolas Caramelli (1):
Check the definition instead of the extension to which it belongs
git tag: glu-9.0.2
https://mesa.freedesktop.org/archive/glu/glu-9.0.2.tar.gz
On Sun, Oct 4, 2020 at 2:00 PM Marek Olšák wrote:
> I think it's just going to get more messy and complicated for people who
> don't want to learn or use another language. Mesa already requires people to
> know C, Python, and now newly Gitlab CI scripts just to get stuff done and
> merged.
On Fri, Feb 28, 2020 at 12:00 AM Daniel Stone wrote:
>
> Hi Matt,
>
> On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> > We're paying 75K USD for the bandwidth to transfer data from the
> > GitLab cloud instance. i.e., for viewing the https site, for
> &
On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially
On Mon, Dec 9, 2019 at 6:07 PM Dylan Baker wrote:
>
> Hi everyone,
>
> I think its time we discussed whether we're going to continue to do patch
> review
> on the mailing list, or if it it should all go through gitlab. I think we
> should
> stop using the mailing list, here are some reasons:
>
On Wed, Sep 11, 2019 at 9:14 PM Kyle Brenneman wrote:
>
> On 9/9/19 12:07 PM, Adam Jackson wrote:
> > On Wed, 2019-09-04 at 14:27 -0600, Kyle Brenneman wrote:
> >> On 9/4/19 8:44 AM, Daniel Stone wrote:
> >>> Hi,
> >>>
> >>> On Wed, 4 Sep 2019 at 15:12, Chuck Atkins
> >>> wrote:
> Can we
On Tue, Sep 10, 2019 at 10:54 PM Brian Paul wrote:
>
> IIRC, designated initializers are not legal C++.
> Fixes the MSVC build.
>
> Fixes: 83fd1e58 ("glsl/nir: Add and use a gl_nir_link() function")
> ---
> src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1
What is going on with the 19.2 RCs? I know that we said we would push
the releases back a week to let some feature work land, but the last
blocker of the feature tracker [0] landed on the 14th and RC1 wasn't
until the 20th. Now another two weeks have passed without an RC. RC2
should have been
Getting patches into libglvnd has proven quite difficult (see [0] for
example). There was some talk of moving it to FreeDesktop Gitlab on
IRC recently. Can we move forward with that? Are there objections to
doing so?
[0] https://github.com/NVIDIA/libglvnd/pull/86
On Thu, Aug 8, 2019 at 2:56 AM Emil Velikov wrote:
>
> On Wed, 7 Aug 2019 at 21:43, Mark Janes wrote:
> >
> > Eric Engestrom writes:
> >
> > > On 2019-07-31 at 09:38, Emil Velikov wrote:
> > >> Hi all,
> > >>
> > >> Here is the tentative release plan for 19.2.0.
> > >>
> > >> As many of you
oved since
> we will be merging a block with multiple children into the first one
> of them.
Okay, so I think you're saying that ::remove_block already does
exactly what we need so we don't need to bother ensuring that the
"internal" edges are removed. If that's an accurate restate
Amarnath Valluri (1):
libutils/mipmap.c: Fixed possible memory leak
John Hein (1):
pkgconfig: Include -I path for glu itself
Krzysztof Kosiński (1):
Remove all uses of the register keyword.
Matt Turner (4):
Add -D(N)DEBUG to CFLAGS dependent on --enable-debug
libutil
On Thu, Jul 18, 2019 at 7:19 AM Alyssa Ross wrote:
>
> "auto" pays attention to the OS and architecture of the target system,
> but not the available libraries. If, say, libdrm isn't available, "auto"
> won't work, and a manual list of drivers will be required anyway. It
> would also try building
Heh, interesting!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Whoops/Nice!
Are there any shader-db changes as a result?
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
In the FS IR we pretend that the instruction is predicated with (+f0.1)
just for flag dependency tracking purposes. Since the instruction
doesn't support predication before Haswell, we unset the predicate so we
should also unset the flag register so that we can round-trip the
disassembly.
---
On Mon, Apr 22, 2019 at 1:09 PM Kristian Høgsberg wrote:
>
> On Mon, Apr 22, 2019 at 12:11 PM Jason Ekstrand wrote:
> >
> > All,
> >
> > I've seen discussions come up several times lately about whether you should
> > use MAYBE_UNUSED or UNUSED in what scenario and why do we have two of them
>
On Thu, Apr 4, 2019 at 9:16 AM Emil Velikov wrote:
>
> On Tue, 2 Apr 2019 at 20:13, Matt Turner wrote:
> >
> > On Mon, Apr 1, 2019 at 5:18 AM Emil Velikov
> > wrote:
> > > For anyone wondering about the delay:
> > >
> > > We have
On Mon, Apr 1, 2019 at 5:18 AM Emil Velikov wrote:
> For anyone wondering about the delay:
>
> We have been using LunarG OpenGL and Vulkan testing service to
> validate Mesa releases since day 1.
>
> Unfortunately, they've been experiencing some issues which we're
> expecting to be resolved any
mul->src[1].ud << 16);
Please put braces around the statement, since it's in nested control flow.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Feb 18, 2019 at 9:32 AM Daniel Stone wrote:
>
> Hi all,
> A few people have noted that Mesa's GitLab CI is just too slow, and
> not usable in day-to-day development, which is a massive shame.
>
> I looked into it a bit this morning, and also discussed it with Emil,
> though nothing in
On Thu, Feb 14, 2019 at 1:30 PM Jason Ekstrand wrote:
>
> On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez wrote:
>>
>> Strides up to 32B can be implemented for the source regions of most
>> instructions by leveraging either the vertical or the horizontal
>> stride of the hardware Align1 region.
causing it to render nothing.
>
> Fixes: 1f862e923cb "i965/fs: Optimize float conversions of byte/word..."
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109601
> Cc: Matt Turner
> ---
> src/intel/compiler/brw_fs_nir.cpp | 5 +
> 1 file changed,
My OCD is really bothered by the backslashes in the commit title. Can
we use forward slashes like all the other commits?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jan 30, 2019 at 10:37 AM Emil Velikov wrote:
>
> Hello list,
>
> The candidate for the Mesa 18.3.3 is now available. Currently we have:
> - 45 queued
> - 4 nominated (outstanding)
> - and 3 rejected patches
Might be good to cherry-pick the two patches mentioned in
On Mon, Jan 28, 2019 at 10:25 AM Roland Scheidegger wrote:
>
> I like it :-).
> That said, there's some caveats as discussed on IRC - in particular for
> gpus which don't do round-to-nearest-even for ordinary fp64 math (or
> rounding mode could be set to something else manually) it won't do the
>
Use the trick of adding and then subtracting 2**52 (52 is the number of
explicit mantissa bits a double-precision floating-point value has) to
implement round-to-even.
Cuts the number of instructions on SKL of the piglit test
fs-roundEven-double.shader_test from 109 to 21.
---
Compilation of user-specified shaders with software fp64 works by
compiling on demand an "fp64-funcs" shader implementing various fp64
operations and then linking it into the "user shader".
In
commit 64b8c86d37ebb1e1d286c69d642d52b7bcf051d3
Author: Timothy Arceri
Date: Thu Jan 17
On Thu, Jan 24, 2019 at 12:16 PM Francisco Jerez wrote:
>
> Matt Turner writes:
>
> > ---
> > src/intel/compiler/brw_eu_validate.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/compiler/brw_
---
src/intel/compiler/brw_eu_validate.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index a25010b225c..7f1580a5bb3 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++
On Wed, Jan 23, 2019 at 6:03 AM Francisco Jerez wrote:
>
> Iago Toral Quiroga writes:
>
> > Commit c84ec70b3a72 implemented execution type promotion to 32-bit for
> > conversions involving half-float registers, which empirical testing
> > suggested
> > was required, but it did not incorporate
On Wed, Jan 23, 2019 at 4:18 AM Iago Toral Quiroga wrote:
>
> Commit c84ec70b3a72 implemented execution type promotion to 32-bit for
> conversions involving half-float registers, which empirical testing suggested
> was required, but it did not incorporate this change into the assembly
>
NEON (now called ASIMD) is available on all aarch64 CPUs. Our code was
missing an aarch64 path, leading to util_cpu_caps.has_neon always being
false on aarch64.
---
Here's the simpler patch to just always enable NEON on aarch64. It suits
my purposes, but I can imagine that you may prefer the
On Wed, Jan 23, 2019 at 3:26 PM Eric Anholt wrote:
>
> Matt Turner writes:
>
> > NEON (now called ASIMD) is available on all aarch64 CPUs. It seems that
> > our code was missing an aarch64 path, leading to util_cpu_caps.has_neon
> > always being false on aarch64. I thi
On Tue, Jan 22, 2019 at 10:26 PM Matt Turner wrote:
> Was this just something that you noticed by inspection?
With the patch reverted I see some validation failures in
dEQP-VK.spirv_assembly.instruction.compute.8bit_storage.push_constant_8_to_16.scalar_uint
and friends.
mov(16) g10&
On Sun, Jul 8, 2018 at 5:27 PM, Jose Maria Casanova Crespo
wrote:
> When the destination is a BYTE type allow raw movs
> even if the stride is not exact multiple of destination
> type and exec type, execution type is Word and its size is 2.
>
> This restriction was only allowing stride==2
== 8 && src.type == BRW_REGISTER_TYPE_HF)) {
The docs are bad about telling us whether a BDW restriction applies to
CHV as well, but in this case I suspect the answer is no. CHV seems to
inherit its FP16 hw from SKL, which doesn't have the restriction as
you say.
So I suspect you want d
Obviously you cannot test the Gen11 code, but it looks believable.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga wrote:
>
> 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
t; assert(src0.type == BRW_REGISTER_TYPE_F || src0.type == BRW_REGISTER_TYPE_HF);
Please don't. Stuff like this should go in brw_eu_validate.c. If you
add asserts to the emission code, it'll assert fail when you write a
negative test for brw_eu_validate.c.
The code as-is is
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
amp;&
> !brw_inst_bits(src, 7, 7));
> +
> + /* Src1Type and Src2Type, used for mixed-precision floating point */
> + if (brw_inst_bits(src, 36, 35))
> + return true;
> }
These bits are used on SKL+ and CHV (which is handled i
On Tue, Jan 15, 2019 at 5:55 AM Iago Toral Quiroga wrote:
>
> This is available since gen8.
>
> v2: restore previously existing assertion.
>
> Reviewed-by: Topi Pohjolainen (v1)
> ---
> src/intel/compiler/brw_reg_type.c | 36 +++
> 1 file changed, 32 insertions(+), 4
On Tue, Jan 22, 2019 at 3:25 PM Francisco Jerez wrote:
>
> Matt Turner writes:
>
> > emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
> > flag_subreg set, so that the IR knows which flag is accessed. However
> > the flag is only used on Gen7 in Al
emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
flag_subreg set, so that the IR knows which flag is accessed. However
the flag is only used on Gen7 in Align1 mode.
To avoid setting unnecessary bits in the instruction words, get the
information we need and reset the default flag
LLVM uses the single instruction "FRINTI" to implement llvm.nearbyint.
Fixes the rounding tests of lp_test_arit.
Bug: https://bugs.gentoo.org/665570
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 4 +++-
src/gallium/drivers/llvmpipe/lp_test_arit.c | 3 ++-
2 files changed, 5 insertions(+), 2
NEON (now called ASIMD) is available on all aarch64 CPUs. It seems that
our code was missing an aarch64 path, leading to util_cpu_caps.has_neon
always being false on aarch64. I think that means that the NEON tiling
code in vc4 would not be enabled on aarch64 (vc4_load_lt_image_neon,
etc).
---
I
emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
flag_subreg set, so that the IR knows which flag is accessed. However
the flag is only used on Gen7 in Align1 mode.
To avoid setting unnecessary bits in the instruction words, get the
information we need and reset the default flag
On Tue, Jan 22, 2019 at 11:53 AM Francisco Jerez wrote:
>
> Matt Turner writes:
>
> > emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
> > flag_subreg set, so that the IR knows which flag is accessed. However
> > the flag is only used on Gen7 in
emit_uniformize() emits SHADER_OPCODE_FIND_LIVE_CHANNEL with its
flag_subreg set, so that the IR knows which flag is accessed. However
the flag is only used on Gen7 in Align1 mode, and it is used as an
explicit source and destination.
To avoid setting unnecessary bits in the instruction words,
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Jan 15, 2019 at 5:54 AM Iago Toral Quiroga wrote:
>
> NIR already has these so they are redundant. A run of shader-db confirms
> that the only cases where these backend optimizations are activated
> are some Tomb Raider shaders where the affected variables are qualified
> as "precise",
On Wed, Jan 16, 2019 at 8:40 PM Jason Ekstrand wrote:
>
> The pass was discovered to cause problems with the MUL+MACH combination
> we emit for nir_[iu]mul_high. In an experimental branch of mine, I ran
> into issues where the MUL+MACH ended up using a strided source due to
> working on half of
On Wed, Jan 16, 2019 at 3:53 AM Gert Wollny wrote:
>
> Hello,
>
> I'm trying to get soft-fp64 working with my experimental r600-nir
> backend, and thanks to Dave's contribution it is already tied in,
> some instructions are not yet supported by the backend, but when
> running the piglits I have
On Fri, Jan 11, 2019 at 2:11 PM Matt Turner wrote:
>
> From: Gert Wollny
>
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
> --enable-autotools
>
> NAKed-by: Ilia Mirkin
&g
On Mon, Oct 29, 2018 at 11:16 AM Lionel Landwerlin
wrote:
>
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/tools/intel_sanitize_gpu.in | 55 ++-
> 1 file changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/tools/intel_sanitize_gpu.in
>
On Tue, Jan 15, 2019 at 8:58 AM Jason Ekstrand wrote:
>
> Previously, we only applied the fix to shaders with a dispatch mode of
> SIMD8 but the code it relies on for SIMD16 mode only applies to SIMD16
> instructions. If you have a SIMD8 instruction in a SIMD16 shader,
> neither would trigger
On Mon, Jan 14, 2019 at 4:36 AM Daniel Stone wrote:
>
> Hi,
>
> On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote:
> > 5. There's no way with gitlab for Reviewed-by tags to get automatically
> > applied as part of the merging process. This makes merging a bit more
> > manual than it needs
On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin wrote:
>
> On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
> >
> > From: Gert Wollny
> >
> > Since Meson will eventually be the only build system deprecate autotools
> > now. It can still be used by invoking co
On Fri, Jan 11, 2019 at 2:17 PM Jason Ekstrand wrote:
>
> On Fri, Jan 11, 2019 at 4:11 PM Matt Turner wrote:
>>
>> From: Gert Wollny
>>
>> Since Meson will eventually be the only build system deprecate autotools
>> now. It can still be used by invoking c
Ekstrand
Acked-by: Rob Clark
Acked-by: Marek Olšák
Reviewed-by: Christian Gmeiner
Reviewed-by: Matt Turner
Reviewed-by: Eric Anholt
Signed-off-by: Gert Wollny
---
I think there's support for overriding the sole objection to this patch.
To confirm:
(1) The plan is to remove Autotools
On Fri, Jan 11, 2019 at 9:11 AM Kenneth Graunke wrote:
>
> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
> > > Those names (nir_var_func_local, nir_var_thread_local, and
> > > nir_var_thread_global) make more sense to
On Fri, Dec 21, 2018 at 1:36 AM Stuart Young wrote:
> Yes, but at the moment we have no consensus and a deadlock on the issue.
Consensus need not be unanimous. We have consensus.
Signed-off-by: Gert Wollny
Reviewed-by: Matt Turner
Acked-by: Eric Engestrom
Acked-by: Kenneth Graunke
an
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/39
Some upcoming Intel platforms do not have 64-bit type support. This
series implements support for ARB_gpu_shader_fp64 and
ARB_gpu_shader_int64 via software implementations.
To do this we add a .glsl file containing GLSL implementations
On Wed, Dec 19, 2018 at 12:06 PM Ilia Mirkin wrote:
> > We're simply trying to get the feedback from users sooner. And the
> > cost to you is very small: Use an extra flag. It's not a burden.
>
> Before the community is happy? Premature. The way you build consensus
> for a new thing is not by
On Wed, Dec 19, 2018 at 10:32 AM Ilia Mirkin wrote:
>
> On Wed, Dec 19, 2018 at 10:25 AM Matt Turner wrote:
> >
> > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin wrote:
> > >
> > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner wrote:
> > > >
On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin wrote:
>
> On Wed, Dec 19, 2018 at 1:01 AM Matt Turner wrote:
> > WTF would you have us do?
>
> Same thing as for any change with an impact this wide --
>
> 1. Identify stakeholders. In this case, probably the sub-proj
On Tue, Dec 18, 2018 at 6:53 PM Ilia Mirkin wrote:
>
> On Tue, Dec 18, 2018 at 6:40 PM Gert Wollny wrote:
> >
> > Hi Ilia,
> >
> > Am Sonntag, den 16.12.2018, 12:40 -0500 schrieb Ilia Mirkin:
> > > On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny
> > > wrote:
> > > >
> > > > Since Meson will
On Mon, Dec 10, 2018 at 11:25 AM Samuel Iglesias Gonsálvez
wrote:
>
> On 07/12/2018 03:03, Matt Turner wrote:
> > On Wed, Dec 5, 2018 at 7:56 AM Samuel Iglesias Gonsálvez
> > wrote:
> >>
> >> Signed-off-by: Samuel Iglesias Gonsálvez
> >> ---
>
On Mon, Dec 17, 2018 at 2:12 PM Emil Velikov wrote:
> Additionally, distributions build latest loader and use it with DRI1
> era drivers.
I'm curious if there are distributions that still ships the DRI1
drivers. Do you know which, if any, do?
___
; != "xyes" ; then
> +AC_MSG_ERROR([the autotools build system has been deprecated in favour of
> +meson and will be removed eventually. For instructions on how to use
> meson
> +see https://www.mesa3d.org/meson.html.
> +If you still want to use
On Fri, Dec 14, 2018 at 11:40 AM Ilia Mirkin wrote:
>
> On Fri, Dec 14, 2018 at 11:32 AM Matt Turner wrote:
> >
> > On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny wrote:
> > > I second that, I voiced my concerns in a former thread, especially that
> > > so f
On Fri, Dec 14, 2018 at 4:12 AM Gert Wollny wrote:
> I second that, I voiced my concerns in a former thread, especially that
> so far this upcoming change has not been officially announced in the
> release notes or on mesa-user, and that I don't understand why it is so
> urgent to drop autotools
On Thu, Dec 13, 2018 at 10:19 PM Ilia Mirkin wrote:
> So now what? I don't remember how that config was done, except that it
> was done the way I decided I needed it at the time. I have no way to
> recover it. With autotools, in such cases (which are immensely rare),
> you just run "head
Thanks. This was very useful for me in the fp64 work.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
all zeros) when it is unused due to RepCtrl
>
> Signed-off-by: Sagar Ghuge
> Reviewed-by: Matt Turner
... and committed!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, Dec 8, 2018 at 11:08 PM Sagar Ghuge wrote:
>
> While disassembling the predicate always print flag subregister number
> to keep grammar same across the generation for assembler tool.
>
> v2: Club consecutive format calls (Matt Turner)
>
> Signed-off-by: Sagar Ghug
On Mon, Dec 10, 2018 at 6:21 AM Samuel Iglesias Gonsálvez
wrote:
>
> Hello Matt,
>
> On 07/12/2018 03:20, Matt Turner wrote:
> > Since this is for an extension that will be BDW+ can we use the
> > _cvtss_sh() intrinsic instead? It corresponds to an IVB+ instruction
> &g
On Thu, Nov 22, 2018 at 1:05 PM Matt Turner wrote:
>
> On Wed, Nov 21, 2018 at 10:48 AM Matt Turner wrote:
> >
> > Thanks Arfrever and Dylan.
> >
> > Acked-by: Matt Turner
>
> Hmm, actually this doesn't seem to work for me. With it applied I get:
>
> sr
On Thu, Dec 6, 2018 at 7:22 PM Roland Scheidegger wrote:
>
> Am 07.12.18 um 03:20 schrieb Matt Turner:
> > Since this is for an extension that will be BDW+ can we use the
> > _cvtss_sh() intrinsic instead? It corresponds to an IVB+ instruction
> > and even takes th
Since this is for an extension that will be BDW+ can we use the
_cvtss_sh() intrinsic instead? It corresponds to an IVB+ instruction
and even takes the rounding mode directly as an immediate argument.
___
mesa-dev mailing list
On Wed, Dec 5, 2018 at 7:56 AM Samuel Iglesias Gonsálvez
wrote:
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/util/Makefile.sources | 2 +
> src/util/double.c | 197 ++
> src/util/double.h | 46 +
> src/util/meson.build
On Tue, Dec 4, 2018 at 7:39 PM Jason Ekstrand wrote:
>
> It's been 24 hours and the only owner who hasn't replied yet is Matt. Given
> that everyone else has firmly ACKed, I'm going to click the button.
> Congratulations, Jordan, you're now a mesa Owner!
That's certainly no reflection on my
On Tue, Dec 4, 2018 at 3:43 PM Gert Wollny wrote:
>
> Am Dienstag, den 04.12.2018, 14:01 -0800 schrieb Matt Turner:
> > On Tue, Dec 4, 2018 at 12:48 PM Gert Wollny
> > wrote:
> > > FWIW, I also don't understand the urge to remove the automake build
> > >
On Tue, Dec 4, 2018 at 12:48 PM Gert Wollny wrote:
> FWIW, I also don't understand the urge to remove the automake build
> system files, they account for less then 1% of line count in the source
> tree, Emil offered to maintain the build system in a way that nobody
> who doesn't want to deal with
On Tue, Dec 4, 2018 at 3:15 AM Juan A. Suarez Romero
wrote:
>
> On Mon, 2018-12-03 at 15:38 -0800, Matt Turner wrote:
> > On Mon, Dec 3, 2018 at 8:12 AM Emil Velikov
> > wrote:
> > > On Thu, 29 Nov 2018 at 23:54, Matt Turner wrote:
> > > > This ex
On Mon, Dec 3, 2018 at 8:12 AM Emil Velikov wrote:
>
> On Thu, 29 Nov 2018 at 23:54, Matt Turner wrote:
> >
> > This extension is not properly tested (testing for
> > GL_ARB_fragment_shader_interlock is not sufficient), and since this was
> > noted in review on
On Fri, Nov 30, 2018 at 4:46 AM Francesco Ansanelli wrote:
> Il giorno ven 30 nov 2018, 12:26 Erik Faye-Lund
> ha scritto:
>>
>> On Fri, 2018-11-23 at 11:53 +0100, Erik Faye-Lund wrote:
>> > OK, so here's a v2 of this series. These are the changes since v1:
>> > - Removed double-semicolons in
On Fri, Nov 30, 2018 at 2:28 AM Gert Wollny wrote:
> Am Donnerstag, den 29.11.2018, 17:44 + schrieb Emil Velikov:
> > Hi all,
> >
> > I can see why people may opt to not use or maintain the autotools
> > build. Although I would kindly ask that we do not remove it just yet.
>
> I second that,
On Thu, Nov 29, 2018 at 5:49 PM Alex Deucher wrote:
>
> On Thu, Nov 29, 2018 at 8:26 PM Eric Anholt wrote:
> >
> > Emil Velikov writes:
> >
> > > Hi all,
> > >
> > > I can see why people may opt to not use or maintain the autotools build.
> > > Although I would kindly ask that we do not remove
This extension is not properly tested (testing for
GL_ARB_fragment_shader_interlock is not sufficient), and since this was
noted in review on August 28th no tests have been sent.
Revert "i965: Add INTEL_fragment_shader_ordering support."
Revert "mesa: Add GL/GLSL plumbing for
On Thu, Nov 29, 2018 at 9:47 AM Emil Velikov wrote:
> In Mesa, we have different parts not used by different teams. As such
> we tend to remove stuff when nobody is around to maintain it anymore.
We drop things for that reason, but also when something is no longer
needed. I don't think autotools
On Wed, Nov 28, 2018 at 11:30 AM Jason Ekstrand wrote:
> We have enough stubborn people on the list that MRs are going to constantly
> get pulled back to the list just because someone doesn't want to use the web
> interface.
A couple of people in this thread have now made similar claims, but
Reviewed-by: Matt Turner
I'll commit it tomorrow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
The common truncf(x + 0.5) fails for the floating-point value just less
than 0.5 (nextafterf(0.5, 0.0)). nextafterf(0.5, 0.0) + 0.5, after
rounding is 1.0, thus truncf does not produce the desired value.
The solution is to add nextafterf(0.5, 0.0) instead of 0.5 before
truncating. This works for
1 - 100 of 6330 matches
Mail list logo
