[Mesa-dev] MR!2161: Some random warning fixes

[Kai Wasserbäch]

Hey,
just for visibility and maybe a quick merge: I sent MR!2161
() last week and
would be much appreciated if somebody could click on that merge button. All
changes are trivial and NFC.

There is one open discussion, for which I could use further input.

I got an Ack by Lionel for the intel/gen_decoder commit (Thank you so much!) and
Eric (Thanks!) had two comments. One is resolved, the other is waiting for a 
reply.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [MR!1706] Bump C++ standard requirement to C++17 to fix FTBFS with LLVM 10

[Kai Wasserbäch]

Hey,
I sent an MR to fix a build failure with LLVM 10
(). Comments and
merge welcome. 😉

(Can I add labels myself, I don't think so?)

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] autotools/meson transition: meson uses hardcoded list of llvm-config binaries, FTBFS with new upstream LLVM (development) versions

[Kai Wasserbäch]

Hey,
I just discovered that meson hardcodes the list of llvm-config binary names to
try in mesonbuild/dependencies/dev.py, line 214ff ([0]). This is breaking now
since LLVM upstream switched to version 9 and branched version 8 of to become a
stable release soon. See [1] for the upstream ticket I filed about this.

The hardcoded list seems rather fragile, and I would prefer if the default
behaviour of meson improves to the point, where the default build ("use newest
LLVM") doesn't depend on new meson releases or manual overrides before meson is
made mandatory for building Mesa.

Is this a sentiment shared by others?

Cheers,
Kai


[0]

[1] 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] last call for autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 11.12.18 00:10:
> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> final call for autotools. My patch is so massive that it's a huge pain to send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools

I've switched to building with meson now and everything seems to work for my
environment, including the usage of a particular LLVM version.

I've noticed, that Debian carries the changes from
 as local patches. It would
probably be good, if those patches land before autotools support is nuked.

Also: meson complains that deprecated features are used:
 - DEPRECATION: Project targetting '>= 0.45' but tried to use feature deprecated
since '0.48.0': python3 module
 - DEPRECATION: build_always is deprecated. Combine build_by_default and
build_always_stale instead.

Can these be fixed before making meson mandatory? Or are they completely
harmless and won't break builds?

This leaves me with a feature request: the autotools build generated a
configuration summary at the end, which is helpful in checking if changes to the
configuration in my debian/rules file are actually propagated to the build or if
something went wrong. Could the meson build provide such a summary as well?

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/1] clover: Fix build after clang r348827

[Kai Wasserbäch]

Jan Vesely wrote on 13.12.18 22:17:
> CodeGenOptions were moved to Basic.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109039
> Signed-off-by: Jan Vesely 

Since this is the same as my patch
(<https://patchwork.freedesktop.org/patch/268295/>) but older than mine, you can
have my:

 Reviewed-by: Kai Wasserbäch 

Cheers,
Kai


> ---
>  src/gallium/state_trackers/clover/llvm/compat.hpp | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index 975012cbda..b91cb95a29 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -58,9 +58,14 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  
> +#if HAVE_LLVM >= 0x0800
> +#include 
> +#else
> +#include 
> +#endif
> +
>  namespace clover {
> namespace llvm {
>namespace compat {



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] clover: Fix include of CodeGenOptions.h, upstream moved it in r348827

[Kai Wasserbäch]

Hey,
I'm just noticing, that there's also a bug report for this, so please add

 Bugzilla: https://bugs.freedesktop.org/109039

before commiting this, in case you accept it (I don't have commit access).

Cheers,
Kai


Kai Wasserbäch wrote on 14.12.18 17:26:
> Signed-off-by: Kai Wasserbäch 
> ---
>  src/gallium/state_trackers/clover/llvm/compat.hpp | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index 975012cbda..9c5b9d8917 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -58,7 +58,11 @@
>  #include 
>  
>  #include 
> +#if HAVE_LLVM >= 0x0800
> +#include 
> +#else
>  #include 
> +#endif
>  #include 
>  
>  namespace clover {



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] clover: Fix include of CodeGenOptions.h, upstream moved it in r348827

[Kai Wasserbäch]

Signed-off-by: Kai Wasserbäch 
---
 src/gallium/state_trackers/clover/llvm/compat.hpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 975012cbda..9c5b9d8917 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -58,7 +58,11 @@
 #include 
 
 #include 
+#if HAVE_LLVM >= 0x0800
+#include 
+#else
 #include 
+#endif
 #include 
 
 namespace clover {
-- 
2.19.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 19.11.18 20:02:
> Sorry, cell phones are really bad for responding to email...

no worries.

> The file has the same rules as cross files, it can be a local file, passed as 
> an
> absolute path, or read from $XDG directories (local files will be read before
> XDG ones).

That sounds workable then. I might have preferred a simple option/flag on the
CLI, but this works as well.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 17.11.18 05:04:
> Quoting Dylan Baker (2018-09-17 09:44:07)
>> I feel like for !windows meson is in good enough shape at this point that we
>> can start having the discussion about deleting the autotools build. So, is 
>> there
>> anything left that autotools can do that meson cannot (that we actually want 
>> to
>> implement)? And, what is a reasonable time-table to remove the autotools 
>> build?
>> I think we could reasonably remove it as soon as 18.3 if others felt 
>> confident
>> that it would work for them.
>>
>> Dylan
> 
> Okay, time for an update on things and a chance to talk about what else we 
> need.
> 
> Support for llvm-config (and any binary, actually) overriding has landed in
> meson, and will be present in the 0.49.0 release, which is due out December 
> 9th.
> support for ICC has improved a great deal already, and I have a series here:
> https://github.com/mesonbuild/meson/pull/4359 (which may unfortunately not
> land until after 0.49) which should get ICC into pretty good shape on Linux 
> and
> Mac, including actually checking that arguments are understood (which should
> allow us to drop the prefix test from SWR). I have some ideas on how we might
> remove auto options, some of them can already use meson's "feature"
> https://mesonbuild.com/Build-options.html#features option (which should make
> distro packagers happy too), for arch and OS specific options I have some 
> ideas
> and I'll continue following up with those upstream.
> 
> For those interested in llvm-config overriding, with meson out of git you can
> add a files like:
> 
> $ cat ~/.local/share/meson/native/llvm-6.0
> [binaries]
> llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'
> 
> and invoke meson with:
> meson builddir --native-file llvm-6.0
> 
> which will configure with the specified llvm-config, and remember the
> llvm-config used on subsequent reconfigurations. You can override all binaries
> from a native file as well, so if you want to use a specific python3 or
> compiler you can do that, and you can load multiple native files in a single
> invocation.

do I understand that correctly as "there is no way to set this on the command
line"? Ie. something like
  meson --override-native="llvm-config=/usr/local/lib/llvm-6/bin/llvm-config"
or something similar? I need to have a file in $XDG_DATA_HOME/meson/native? That
would be really ugly for (automatic) package build environments IMHO, especially
if you want to have reproducible builds. Could these files at least be put in
eg. the debian directory of a source package and then I could pass some option
to meson to look there for these overrides?

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 9/19/18 6:24 PM:
> Quoting Kai Wasserbäch (2018-09-19 08:04:35)
> [...]
>> In any case, thanks for your replies. I'll see if I can scare up some time 
>> over
>> the weekend and check if I can get Mesa building with meson. Nevertheless I'd
>> like to ask for not making meson mandatory until something like today's
>> LLVM_CONFIG or something equivalent within a released version of meson is 
>> available.
> 
> In case you (or anyone else following this is interested) here's my work in
> progress for getting llvm-config overrides into meson:
> https://github.com/mesonbuild/meson/pull/4216

I left you an inline comment there. In addition to that, I'd like to request
some documentation on this new feature to be included in the PR: what format
does the file have, what can I override, do I need one file per override or
multiple files? Etc.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 9/18/18 10:43 PM:
> Quoting Kai Wasserbäch (2018-09-18 11:14:19)
>> Dylan Baker wrote on 9/18/18 6:40 PM:
>>> Quoting Kai Wasserbäch (2018-09-18 08:56:30)
>>>> Dylan Baker wrote on 9/18/18 5:35 PM:
>>>>> [...]
>>>>>
>>>>> The other option you have it to set the $PATH variable, as long as the
>>>>> llvm-config you want returns the highest version things will work as you 
>>>>> expect.
>>>>
>>>> This might do as a workaround, though I'm not too keen on extending $PATH. 
>>>> But
>>>> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain 
>>>> that
>>>> versions binaries, putting it first into the path could work.
>>>
>>> meson will cache the llvm-config values, so you should be able to just do
>>> something like:
>>>
>>> PATH=/path/to/my/llvm meson build-with-my-llvm
>>
>> Ok. Where's the cache? In the build directory or is this something, that's 
>> kept
>> globally and needs potential clearing? A quick search for this feature 
>> yielded
>> <https://mesonbuild.com/Release-notes-for-0-38-0.html>. That makes it sound 
>> like
>> it is global, which I would almost consider broken design. Or is it local but
>> kept between multiple invocations of meson? That also sounds like a recipe 
>> for
>> disaster, though it would be easier to deal with: just nuke the build 
>> directory.
> 
> It's per build directory, and is kept on subsequent rebuilds. The idea is that
> if you need to reconfigure a build (say meson.build changes) when you do a 
> `git
> pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it makes 
> the
> rebuild faster. I don't think there is a cache-invalidation method, though 
> that
> would be a nice feature to have.

I think I can work with that: one build-directory per build and nuke it 
afterwards.

As a side note: to me this sounds like a mis-feature or at least something that
you should have to turn on explicitly. I'd rather pay a little time penalty
(which isn't too much these days, given how fast SSDs and systems in general
have become), than using some stale value. Especially since it sounds like meson
is caching the values of environment variables as well? Which would make usage
of MESA_GIT_SHA1_OVERRIDE after some changes awkward (which value is used and 
why).

In any case, thanks for your replies. I'll see if I can scare up some time over
the weekend and check if I can get Mesa building with meson. Nevertheless I'd
like to ask for not making meson mandatory until something like today's
LLVM_CONFIG or something equivalent within a released version of meson is 
available.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Dylan Baker wrote on 9/18/18 6:40 PM:
> Quoting Kai Wasserbäch (2018-09-18 08:56:30)
>> Dylan Baker wrote on 9/18/18 5:35 PM:
>>> [...]
>>>
>>> This is something we've discussed upstream several times. I will freely 
>>> admit
>>> that llvm-config is a huge pain in the ass to deal with for a ton of 
>>> reasons,
>>> and since we don't use it at Intel
>>
>> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no 
>> longer
>> the case?
> 
> Our relationship with the KBL-G is complicated :)

Well, there's also SWR from Intel, which also relies on LLVM...

>>> it hasn't been on the top of my list of
>>> things to do, and also because the solution upstream wants is very 
>>> non-trival to
>>> implement. This has come up already and I am working on it right now.
>>
>> If upstream support is unreasonable, I'd like to see a similar solution to
>> LLVM_CONFIG as it's in autotools today. It must be possible to 
>> mangle/override
>> the meson variables right? (This might be totally ignorant, because I was 
>> able
>> to avoid Meson so far and all other build systems I've worked with, have one 
>> or
>> more options to set variables. Either by having an option in the build files 
>> or
>> by passing some option into the configure step.)
> 
> It really isn't, the only way we could really override this today is to allow
> you to pass a version requirement. One of the guiding ideas of meson is that
> complicated logic like "how the hell do you make a tool as
> broken-by-design-and-implementation as llvm-config work" should be part of 
> meson
> itself and not in the local build-system. The downside of that is that 
> upstream
> really wants you to think about how you handle things like overriding a 
> specific
> binary like llvm-config because it has to live with that decision for a long
> time.

I'm for the hiding, but why not do it in an easy to change way like the
"Find${FOO}.cmake" scripts? As long as you get certain variables populated
downstream is happy and an occasional change can be managed, if it should become
necessary. Having everything "in the core" sounds rather inflexible to me. Or
I'm misunderstanding you. Anyway, this isn't really the topic here.

>>> The other option you have it to set the $PATH variable, as long as the
>>> llvm-config you want returns the highest version things will work as you 
>>> expect.
>>
>> This might do as a workaround, though I'm not too keen on extending $PATH. 
>> But
>> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain that
>> versions binaries, putting it first into the path could work.
> 
> meson will cache the llvm-config values, so you should be able to just do
> something like:
> 
> PATH=/path/to/my/llvm meson build-with-my-llvm

Ok. Where's the cache? In the build directory or is this something, that's kept
globally and needs potential clearing? A quick search for this feature yielded
<https://mesonbuild.com/Release-notes-for-0-38-0.html>. That makes it sound like
it is global, which I would almost consider broken design. Or is it local but
kept between multiple invocations of meson? That also sounds like a recipe for
disaster, though it would be easier to deal with: just nuke the build directory.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Dylan Baker wrote on 9/18/18 5:35 PM:
> Quoting Kai Wasserbäch (2018-09-18 07:43:08)
>> Hey,
>> Dylan Baker wrote on 9/17/18 6:44 PM:
>>> I feel like for !windows meson is in good enough shape at this point that we
>>> can start having the discussion about deleting the autotools build. So, is 
>>> there
>>> anything left that autotools can do that meson cannot (that we actually 
>>> want to
>>> implement)? And, what is a reasonable time-table to remove the autotools 
>>> build?
>>> I think we could reasonably remove it as soon as 18.3 if others felt 
>>> confident
>>> that it would work for them.
>>
>> How do I set a specific llvm-config name to look for? I have build 
>> environments
>> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
>> could convince each build system with LLVM_CONFIG or similar means to choose 
>> a
>> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
>>
>> Eric pointed me to an ugly hack on IRC, which involves symlinking the 
>> particular
>> llvm-config-${VERSION} to llvm-config in $PATH
>> (<https://gitlab.freedesktop.org/mesa/mesa/commit/b5b912dfeebabafbaff176fe4205eb74607f709b>).
>> But I think this should be fixed properly before making meson mandatory. 
>> Other
>> modern build systems like CMake react to something like -DLLVM_DIR during
>> configure (see
>> <https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project>) and Mesa's
>> stable build systems use LLVM_CONFIG, if set.
>>
>> Cheers,
>> Kai
> 
> This is something we've discussed upstream several times. I will freely admit
> that llvm-config is a huge pain in the ass to deal with for a ton of reasons,
> and since we don't use it at Intel

Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no longer
the case?

> it hasn't been on the top of my list of
> things to do, and also because the solution upstream wants is very non-trival 
> to
> implement. This has come up already and I am working on it right now.

If upstream support is unreasonable, I'd like to see a similar solution to
LLVM_CONFIG as it's in autotools today. It must be possible to mangle/override
the meson variables right? (This might be totally ignorant, because I was able
to avoid Meson so far and all other build systems I've worked with, have one or
more options to set variables. Either by having an option in the build files or
by passing some option into the configure step.)

> The other option you have it to set the $PATH variable, as long as the
> llvm-config you want returns the highest version things will work as you 
> expect.

This might do as a workaround, though I'm not too keen on extending $PATH. But
as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain that
versions binaries, putting it first into the path could work.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Hey,
Dylan Baker wrote on 9/17/18 6:44 PM:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is 
> there
> anything left that autotools can do that meson cannot (that we actually want 
> to
> implement)? And, what is a reasonable time-table to remove the autotools 
> build?
> I think we could reasonably remove it as soon as 18.3 if others felt confident
> that it would work for them.

How do I set a specific llvm-config name to look for? I have build environments
with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
could convince each build system with LLVM_CONFIG or similar means to choose a
particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.

Eric pointed me to an ugly hack on IRC, which involves symlinking the particular
llvm-config-${VERSION} to llvm-config in $PATH
().
But I think this should be fixed properly before making meson mandatory. Other
modern build systems like CMake react to something like -DLLVM_DIR during
configure (see
) and Mesa's
stable build systems use LLVM_CONFIG, if set.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: tools: Fix aubinator_error's fprintf call (format-security)

[Kai Wasserbäch]

Hey Lionel,
Lionel Landwerlin wrote on 8/25/18 5:50 PM:
> On 25/08/2018 11:00, Kai Wasserbäch wrote:
>> The recent commit 4616639b49b4bbc91e503c1c27632dccc1c2b5be introduced
>> the new function aubinator_error() which is a trivial wrapper around
>> fprintf() to STDERR. The call to fprintf() however is passed the message
>> msg directly:
>>    fprintf(stderr, msg);
>>
>> This is a format-security violation and leads to an FTBFS with
>> -Werror=format-security (GCC 8):
>>    ../../../src/intel/tools/aubinator.c: In function 'aubinator_error':
>>    ../../../src/intel/tools/aubinator.c:74:4: error: format not a string
>> literal and no format arguments [-Werror=format-security]
>>    fprintf(stderr, msg);
>>    ^~~
>>
>> This patch fixes this trivially by introducing a catch-all "%s" format
>> argument.
>>
>> Fixes: 4616639b49b ("intel: tools: split aub parsing from aubinator")
>> Cc: Lionel Landwerlin 
>> Signed-off-by: Kai Wasserbäch 
> 
> 
> Reviewed-by: Lionel Landwerlin 

thank you for the review and pushing the patch for me!

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] intel: tools: Fix aubinator_error's fprintf call (format-security)

[Kai Wasserbäch]

The recent commit 4616639b49b4bbc91e503c1c27632dccc1c2b5be introduced
the new function aubinator_error() which is a trivial wrapper around
fprintf() to STDERR. The call to fprintf() however is passed the message
msg directly:
  fprintf(stderr, msg);

This is a format-security violation and leads to an FTBFS with
-Werror=format-security (GCC 8):
  ../../../src/intel/tools/aubinator.c: In function 'aubinator_error':
  ../../../src/intel/tools/aubinator.c:74:4: error: format not a string literal 
and no format arguments [-Werror=format-security]
  fprintf(stderr, msg);
  ^~~

This patch fixes this trivially by introducing a catch-all "%s" format
argument.

Fixes: 4616639b49b ("intel: tools: split aub parsing from aubinator")
Cc: Lionel Landwerlin 
Signed-off-by: Kai Wasserbäch 
---

Hey,
just tried compiling the latest version of Mesa but due to commit
4616639b49b4bbc91e503c1c27632dccc1c2b5be by Lionel I got a FTBFS. Please
commit this patch for me, if you accept it. I do not have commit access
for Mesa.

The pull request for this would be:
 The following changes since commit 1281608849a058fcdbe2f64481a159d58af3d888:

   gallium: Split out PIPE_CAP_TEXTURE_MIRROR_CLAMP_TO_EDGE. (2018-08-24 
17:25:36 -0700)

 are available in the Git repository at:

   https://gitlab.freedesktop.org/curan/mesa.git aub-format-security

 for you to fetch changes up to 24957b0db3c12a097d70033ec8596da5bafedd55:

   intel: tools: Fix aubinator_error's fprintf call (format-security) 
(2018-08-25 11:43:25 +0200)

Cheers,
Kai

 src/intel/tools/aubinator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 374ed46f86..c22d191f14 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -71,7 +71,7 @@ struct brw_instruction;
 static void
 aubinator_error(void *user_data, const void *aub_data, const char *msg)
 {
-   fprintf(stderr, msg);
+   fprintf(stderr, "%s", msg);
 }
 
 static void
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amd/addrlib: Fix include path for c99_compat.h

[Kai Wasserbäch]

Hey Mariusz,
Mariusz Ceier wrote on 8/22/18 10:16 PM:
> Without this patch mesa doesn't compile:
> 
> In file included from ../mesa-/src/amd/addrlib/addrinterface.cpp:39:
> ../mesa-/src/util/macros.h:29:10: fatal error: c99_compat.h: No such file 
> or directory
>  #include "c99_compat.h"
>   ^~
> compilation terminated.
> 
> Signed-off-by: Mariusz Ceier 

please add:
 Fixes 15ca5ce99a (amd/addrlib: mark returnCode as MAYBE_UNUSED in)
and you can have my
 Acked-by: Kai Wasserbäch 

No R-b from me, because I have never used meson to build Mesa and don't plan to
do so before Debian's packaging switches to it.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/12] amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled

[Kai Wasserbäch]

Kai Wasserbäch wrote on 8/22/18 5:19 PM:
> Hey Marek,
> Marek Olšák wrote on 8/22/18 3:13 AM:
>> Get you send me a "git fetch" line that I can use to download your patches?
> 
> sure. I rebased them on top of the current master and pushed the five patches 
> to
> a new branch fix-warnings2-addrlibv2 on the FDO GitLab. Find the pull request
> for that below:
> 
> The following changes since commit 4c43ec461de4f122d5d6566361d064c816e4ef69:
> 
>   ac/nir: fix getting GLSL type of array of samplers for TG4 (2018-08-22
> 15:23:11 +0200)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/curan/mesa.git fix-warnings2-addrlibv2
> 
> for you to fetch changes up to 88f825e915cd3d52b13489633e1c805bf2cf765b:

I had to redo this, because I forgot to include your R-bs and also the v2 notes.
Now it should read „[...] fetch changes up to
418ca1d6285aa8fa37d39884adab41f8989825eb“.

>   amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in
> Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled (2018-08-22 17:08:04 
> +0200)
> 
> 
> Kai Wasserbäch (5):
>   amd/addrlib: mark returnCode as MAYBE_UNUSED in ElemGetExportNorm
>   amd/addrlib: mark microBlockDim as MAYBE_UNUSED in
> Addr::V2::Gfx9Lib::HwlComputeBlock256Equation
>   amd/addrlib: mark *pEqToCheck as MAYBE_UNUSED in
> Addr::V2::Gfx9Lib::ComputeStereoInfo
>   amd/addrlib: mark numPipes as MAYBE_UNUSED in
> Addr::V1::EgBasedLib::SanityCheckMacroTiled
>   amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in
> Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled
> 
>  src/amd/Makefile.addrlib.am  | 1 +
>  src/amd/addrlib/addrinterface.cpp| 4 +++-
>  src/amd/addrlib/gfx9/gfx9addrlib.cpp | 6 --
>  src/amd/addrlib/r800/egbaddrlib.cpp  | 6 --
>  4 files changed, 12 insertions(+), 5 deletions(-)
> 
> Cheers,
> Kai
> 
> 
> _______
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/12] amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled

[Kai Wasserbäch]

Hey Marek,
Marek Olšák wrote on 8/22/18 3:13 AM:
> Get you send me a "git fetch" line that I can use to download your patches?

sure. I rebased them on top of the current master and pushed the five patches to
a new branch fix-warnings2-addrlibv2 on the FDO GitLab. Find the pull request
for that below:

The following changes since commit 4c43ec461de4f122d5d6566361d064c816e4ef69:

  ac/nir: fix getting GLSL type of array of samplers for TG4 (2018-08-22
15:23:11 +0200)

are available in the Git repository at:

  https://gitlab.freedesktop.org/curan/mesa.git fix-warnings2-addrlibv2

for you to fetch changes up to 88f825e915cd3d52b13489633e1c805bf2cf765b:

  amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in
Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled (2018-08-22 17:08:04 +0200)

----
Kai Wasserbäch (5):
  amd/addrlib: mark returnCode as MAYBE_UNUSED in ElemGetExportNorm
  amd/addrlib: mark microBlockDim as MAYBE_UNUSED in
Addr::V2::Gfx9Lib::HwlComputeBlock256Equation
  amd/addrlib: mark *pEqToCheck as MAYBE_UNUSED in
Addr::V2::Gfx9Lib::ComputeStereoInfo
  amd/addrlib: mark numPipes as MAYBE_UNUSED in
Addr::V1::EgBasedLib::SanityCheckMacroTiled
  amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in
Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled

 src/amd/Makefile.addrlib.am  | 1 +
 src/amd/addrlib/addrinterface.cpp| 4 +++-
 src/amd/addrlib/gfx9/gfx9addrlib.cpp | 6 --
 src/amd/addrlib/r800/egbaddrlib.cpp  | 6 --
 4 files changed, 12 insertions(+), 5 deletions(-)

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/12] amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled

[Kai Wasserbäch]

Hey Marek,
Marek Olšák wrote on 8/21/18 2:23 AM:
> I've sent comments on patches 3 & 4. With those addressed, patches 1-5 are:
> 
> Reviewed-by: Marek Olšák 

thanks for the review! I've just sent updated versions of patches 3 and 4. (Just
as a side note: I only reindented the other variable definitions, because it
seemed to be the style of the files to use that type of indention).

If you're happy with the changes, feel free to push them. I do not have commit
access. Please note, that Lionel already pushed the changes to the intel
directories, he was comfortable with. So only the five addrlib changes would
sill need to be pushed.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 04/12] amd/addrlib: mark numPipes as MAYBE_UNUSED in Addr::V1::EgBasedLib::SanityCheckMacroTiled (v2)

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/amd/addrlib/r800/egbaddrlib.cpp: In member function 'int 
Addr::V1::EgBasedLib::SanityCheckMacroTiled(ADDR_TILEINFO*) const':
 ../../../src/amd/addrlib/r800/egbaddrlib.cpp:982:13: warning: unused variable 
'numPipes' [-Wunused-variable]
  UINT_32 numPipes= HwlGetPipes(pTileInfo);
  ^~~~

v2: Don't realign other variable definitions, to keep in line with file
style (Marek)

Cc: Marek Olšák 
Signed-off-by: Kai Wasserbäch 
Reviewed-by: Marek Olšák 
---
 src/amd/addrlib/r800/egbaddrlib.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/addrlib/r800/egbaddrlib.cpp 
b/src/amd/addrlib/r800/egbaddrlib.cpp
index 3947cfda2f..905d443cfa 100644
--- a/src/amd/addrlib/r800/egbaddrlib.cpp
+++ b/src/amd/addrlib/r800/egbaddrlib.cpp
@@ -33,6 +33,8 @@
 
 #include "egbaddrlib.h"
 
+#include "util/macros.h"
+
 namespace Addr
 {
 namespace V1
@@ -979,7 +981,7 @@ BOOL_32 EgBasedLib::SanityCheckMacroTiled(
 ) const
 {
 BOOL_32 valid   = TRUE;
-UINT_32 numPipes= HwlGetPipes(pTileInfo);
+MAYBE_UNUSED UINT_32 numPipes = HwlGetPipes(pTileInfo);
 
 switch (pTileInfo->banks)
 {
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 03/12] amd/addrlib: mark *pEqToCheck as MAYBE_UNUSED in Addr::V2::Gfx9Lib::ComputeStereoInfo (v2)

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/amd/addrlib/gfx9/gfx9addrlib.cpp: In member function 
'ADDR_E_RETURNCODE Addr::V2::Gfx9Lib::ComputeStereoInfo(const 
ADDR2_COMPUTE_SURFACE_INFO_INPUT*, ADDR2_COMPUTE_SURFACE_INFO_OUTPUT*, unsigned 
int*) const':
 ../../../src/amd/addrlib/gfx9/gfx9addrlib.cpp:3879:34: warning: unused 
variable 'pEqToCheck' [-Wunused-variable]
  const ADDR_EQUATION *pEqToCheck= 
&m_equationTable[eqIndex];
   ^~

v2: Don't realign other variable definitions, to keep in line with file
style (Marek)

Cc: Marek Olšák 
Signed-off-by: Kai Wasserbäch 
Reviewed-by: Marek Olšák 
---
 src/amd/addrlib/gfx9/gfx9addrlib.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/addrlib/gfx9/gfx9addrlib.cpp 
b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
index 853a041158..d27aabbb60 100644
--- a/src/amd/addrlib/gfx9/gfx9addrlib.cpp
+++ b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
@@ -3878,7 +3878,7 @@ ADDR_E_RETURNCODE Gfx9Lib::ComputeStereoInfo(
 const UINT_32numBankBits   = 
GetBankXorBits(blkSizeLog2);
 const UINT_32bppLog2   = Log2(pIn->bpp >> 3);
 const UINT_32maxYCoordBlock256 = 
Log2(Block256_2d[bppLog2].h) - 1;
-const ADDR_EQUATION *pEqToCheck= &m_equationTable[eqIndex];
+MAYBE_UNUSED const ADDR_EQUATION *pEqToCheck = 
&m_equationTable[eqIndex];
 
 ADDR_ASSERT(maxYCoordBlock256 ==
 GetMaxValidChannelIndex(&pEqToCheck->addr[0], 
GetBlockSizeLog2(ADDR_SW_256B), 1));
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/12] Compiler warning fixes, round 2

[Kai Wasserbäch]

Hey Linoel,
Lionel Landwerlin wrote on 20.08.2018 11:19:
> On 20/08/18 09:16, Kai Wasserbäch wrote:
>> Lionel Landwerlin wrote on 19.08.2018 11:05:
>>> Patches 6, 7, 10 & 11 are :
>>>
>>> Reviewed-by: Lionel Landwerlin 
>> thanks! Feel free to push, I don't have commit access (see cover letter).
> 
> Will do.

thanks!

>>> There are 2 existing series touching the same code, in patches 8, 9 & 12, I
>>> think should land before the warnings are fixed.
>> Hm, I can see why you might want to hold off on 8 and 9 then, but 12 
>> shouldn't
>> break anything, should it? It might even work as a fixup for your other 
>> series?
>> Anyway, I can carry those three over to the next series, once I get most of 
>> this
>> into master. 😉
> 
> It clashes with this one : https://patchwork.freedesktop.org/series/48139/

Ah, I see. Patch 12 from this series wouldn't be needed at all afterwards, since
result would be the return value then. Let's abandon this one then. 🙂

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 00/12] Compiler warning fixes, round 2

[Kai Wasserbäch]

Hey Lionel,
Lionel Landwerlin wrote on 19.08.2018 11:05:
> Patches 6, 7, 10 & 11 are :
> 
> Reviewed-by: Lionel Landwerlin 

thanks! Feel free to push, I don't have commit access (see cover letter).

> There are 2 existing series touching the same code, in patches 8, 9 & 12, I
> think should land before the warnings are fixed.

Hm, I can see why you might want to hold off on 8 and 9 then, but 12 shouldn't
break anything, should it? It might even work as a fixup for your other series?
Anyway, I can carry those three over to the next series, once I get most of this
into master. 😉

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 11/12] intel/decoder: mark total_length as MAYBE_UNUSED in gen_spec_load

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/intel/common/gen_decoder.c: In function 'gen_spec_load':
 ../../../src/intel/common/gen_decoder.c:535:47: warning: variable 
'total_length' set but not used [-Wunused-but-set-variable]
 uint32_t text_offset = 0, text_length = 0, total_length;
^~~~

Signed-off-by: Kai Wasserbäch 
---
 src/intel/common/gen_decoder.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index ec0a486b10..c14c23aad1 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -532,7 +532,8 @@ gen_spec_load(const struct gen_device_info *devinfo)
struct parser_context ctx;
void *buf;
uint8_t *text_data = NULL;
-   uint32_t text_offset = 0, text_length = 0, total_length;
+   uint32_t text_offset = 0, text_length = 0;
+   MAYBE_UNUSED uint32_t total_length;
uint32_t gen_10 = devinfo_to_gen(devinfo);
 
for (int i = 0; i < ARRAY_SIZE(genxml_files_table); i++) {
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 09/12] intel: aubinator: mark *res as MAYBE_UNUSED in get_ppgtt_batch_bo

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/intel/tools/aubinator.c: In function 'get_ppgtt_batch_bo':
 ../../../src/intel/tools/aubinator.c:383:13: warning: unused variable 'res' 
[-Wunused-variable]
void *res = mmap((uint8_t *)bo.map + (page - bo.addr), 4096, PROT_READ,
  ^~~

Signed-off-by: Kai Wasserbäch 
---
 src/intel/tools/aubinator.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 96ac39248d..abdebba53a 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -381,8 +381,9 @@ get_ppgtt_batch_bo(void *user_data, uint64_t address)
for (uint64_t page = address; page < end; page += 4096) {
   struct phys_mem *phys_mem = ppgtt_walk(pml4, page);
 
-  void *res = mmap((uint8_t *)bo.map + (page - bo.addr), 4096, PROT_READ,
-   MAP_SHARED | MAP_FIXED, mem_fd, phys_mem->fd_offset);
+  MAYBE_UNUSED void *res = mmap((uint8_t *)bo.map + (page - bo.addr), 4096,
+   PROT_READ, MAP_SHARED | MAP_FIXED, mem_fd,
+   phys_mem->fd_offset);
   assert(res != MAP_FAILED);
}
 
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 10/12] intel/tools: initialise bo_addr to 0 in main

[Kai Wasserbäch]

Supresses a maybe-uninitialized warning with GCC 8.

Signed-off-by: Kai Wasserbäch 
---
 src/intel/tools/error2aub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
index 2030593691..8a23d5ef1e 100644
--- a/src/intel/tools/error2aub.c
+++ b/src/intel/tools/error2aub.c
@@ -206,7 +206,7 @@ main(int argc, char *argv[])
   BO_TYPE_BATCH,
   BO_TYPE_USER,
} bo_type = BO_TYPE_UNKNOWN;
-   uint64_t bo_addr;
+   uint64_t bo_addr = 0;
 
char *line = NULL;
size_t line_size;
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 08/12] intel: aubinator: mark *res as MAYBE_UNUSED in get_ggtt_batch_bo

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/intel/tools/aubinator.c: In function 'get_ggtt_batch_bo':
 ../../../src/intel/tools/aubinator.c:322:13: warning: unused variable 'res' 
[-Wunused-variable]
void *res = mmap((uint8_t *)bo.map + map_offset, 4096, PROT_READ,
  ^~~

Signed-off-by: Kai Wasserbäch 
---
 src/intel/tools/aubinator.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 66a7db1043..96ac39248d 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -319,8 +319,9 @@ get_ggtt_batch_bo(void *user_data, uint64_t address)
  continue;
 
   uint32_t map_offset = i->virt_addr - address;
-  void *res = mmap((uint8_t *)bo.map + map_offset, 4096, PROT_READ,
-   MAP_SHARED | MAP_FIXED, mem_fd, phys_mem->fd_offset);
+  MAYBE_UNUSED void *res = mmap((uint8_t *)bo.map + map_offset, 4096,
+   PROT_READ, MAP_SHARED | MAP_FIXED, mem_fd,
+   phys_mem->fd_offset);
   assert(res != MAP_FAILED);
}
 
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 02/12] amd/addrlib: mark microBlockDim as MAYBE_UNUSED in Addr::V2::Gfx9Lib::HwlComputeBlock256Equation

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-but-set-variable warning with GCC 8:
 ../../../src/amd/addrlib/gfx9/gfx9addrlib.cpp: In member function 'virtual 
ADDR_E_RETURNCODE 
Addr::V2::Gfx9Lib::HwlComputeBlock256Equation(AddrResourceType, 
AddrSwizzleMode, unsigned int, ADDR_EQUATION*) const':
 ../../../src/amd/addrlib/gfx9/gfx9addrlib.cpp:2473:15: warning: variable 
'microBlockDim' set but not used [-Wunused-but-set-variable]
  Dim2d microBlockDim = Block256_2d[elementBytesLog2];
^

Cc: Marek Olšák 
Signed-off-by: Kai Wasserbäch 
---
 src/amd/addrlib/gfx9/gfx9addrlib.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/addrlib/gfx9/gfx9addrlib.cpp 
b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
index ef86c3bc7b..853a041158 100644
--- a/src/amd/addrlib/gfx9/gfx9addrlib.cpp
+++ b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
@@ -37,6 +37,8 @@
 
 #include "amdgpu_asic_addr.h"
 
+#include "util/macros.h"
+
 

 

 
@@ -2470,7 +2472,7 @@ ADDR_E_RETURNCODE Gfx9Lib::HwlComputeBlock256Equation(
 // Post validation
 if (ret == ADDR_OK)
 {
-Dim2d microBlockDim = Block256_2d[elementBytesLog2];
+MAYBE_UNUSED Dim2d microBlockDim = Block256_2d[elementBytesLog2];
 ADDR_ASSERT((2u << GetMaxValidChannelIndex(pEquation->addr, 8, 0)) ==
 (microBlockDim.w * (1 << elementBytesLog2)));
 ADDR_ASSERT((2u << GetMaxValidChannelIndex(pEquation->addr, 8, 1)) == 
microBlockDim.h);
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 12/12] intel/decoder: mark result as MAYBE_UNUSED in gen_field_iterator_next

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/intel/common/gen_decoder.c: In function 'gen_field_iterator_next':
 ../../../src/intel/common/gen_decoder.c:1008:12: warning: unused variable 
'result' [-Wunused-variable]
bool result = iter_decode_field(iter);
 ^~~~~~

Signed-off-by: Kai Wasserbäch 
---
 src/intel/common/gen_decoder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index c14c23aad1..0600449db6 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -1006,7 +1006,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
   else
  iter->field = iter->group->next->fields;
 
-  bool result = iter_decode_field(iter);
+  MAYBE_UNUSED bool result = iter_decode_field(iter);
   if (iter->p_end)
  assert(result);
 
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 04/12] amd/addrlib: mark numPipes as MAYBE_UNUSED in Addr::V1::EgBasedLib::SanityCheckMacroTiled

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/amd/addrlib/r800/egbaddrlib.cpp: In member function 'int 
Addr::V1::EgBasedLib::SanityCheckMacroTiled(ADDR_TILEINFO*) const':
 ../../../src/amd/addrlib/r800/egbaddrlib.cpp:982:13: warning: unused variable 
'numPipes' [-Wunused-variable]
  UINT_32 numPipes= HwlGetPipes(pTileInfo);
  ^~~~

Cc: Marek Olšák 
Signed-off-by: Kai Wasserbäch 
---
 src/amd/addrlib/r800/egbaddrlib.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/amd/addrlib/r800/egbaddrlib.cpp 
b/src/amd/addrlib/r800/egbaddrlib.cpp
index 3947cfda2f..37a60c7a85 100644
--- a/src/amd/addrlib/r800/egbaddrlib.cpp
+++ b/src/amd/addrlib/r800/egbaddrlib.cpp
@@ -33,6 +33,8 @@
 
 #include "egbaddrlib.h"
 
+#include "util/macros.h"
+
 namespace Addr
 {
 namespace V1
@@ -978,8 +980,8 @@ BOOL_32 EgBasedLib::SanityCheckMacroTiled(
 ADDR_TILEINFO* pTileInfo   ///< [in] macro-tiled parameters
 ) const
 {
-BOOL_32 valid   = TRUE;
-UINT_32 numPipes= HwlGetPipes(pTileInfo);
+BOOL_32  valid   = TRUE;
+MAYBE_UNUSED UINT_32 numPipes= HwlGetPipes(pTileInfo);
 
 switch (pTileInfo->banks)
 {
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 00/12] Compiler warning fixes, round 2

[Kai Wasserbäch]

Hey,
thanks to Bas and Timothy for reviewing and pushing most of my previous
warning fixes series (<https://patchwork.freedesktop.org/series/48403/>)!

I just continued down the build log and fixed the next eleven warnings.
These changes are, again, compile-tested in a clean chroot (pbuilder) on
amd64 and i386.

You can find the signed commits on the FDO GitLab at
<https://gitlab.freedesktop.org/curan/mesa/commits/fix-warnings2>.

Note: the first patch is a resend of patch four of the previous series,
as it hasn't been reviewed/accepted so far and I thought it would be
easier to keep only one series active.

Please review and, if you should accept these patches, please commit
them for me, as I do not have commit access for Mesa.

Cheers,
Kai


Kai Wasserbäch (12):
  amd/addrlib: mark returnCode as MAYBE_UNUSED in ElemGetExportNorm
  amd/addrlib: mark microBlockDim as MAYBE_UNUSED in
Addr::V2::Gfx9Lib::HwlComputeBlock256Equation
  amd/addrlib: mark *pEqToCheck as MAYBE_UNUSED in
Addr::V2::Gfx9Lib::ComputeStereoInfo
  amd/addrlib: mark numPipes as MAYBE_UNUSED in
Addr::V1::EgBasedLib::SanityCheckMacroTiled
  amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in
Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled
  intel/aubinator_error_decode: mark ret as MAYBE_UNUSED in main
  intel: aubinator: mark ftruncate_res as MAYBE_UNUSED in
ensure_phys_mem
  intel: aubinator: mark *res as MAYBE_UNUSED in get_ggtt_batch_bo
  intel: aubinator: mark *res as MAYBE_UNUSED in get_ppgtt_batch_bo
  intel/tools: initialise bo_addr to 0 in main
  intel/decoder: mark total_length as MAYBE_UNUSED in gen_spec_load
  intel/decoder: mark result as MAYBE_UNUSED in gen_field_iterator_next

 src/amd/Makefile.addrlib.am  |  1 +
 src/amd/addrlib/addrinterface.cpp|  4 +++-
 src/amd/addrlib/gfx9/gfx9addrlib.cpp | 16 +---
 src/amd/addrlib/r800/egbaddrlib.cpp  |  8 +---
 src/intel/common/gen_decoder.c   |  5 +++--
 src/intel/tools/aubinator.c  | 12 +++-
 src/intel/tools/aubinator_error_decode.c |  2 +-
 src/intel/tools/error2aub.c  |  2 +-
 8 files changed, 30 insertions(+), 20 deletions(-)

-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 06/12] intel/aubinator_error_decode: mark ret as MAYBE_UNUSED in main

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-but-set-variable warning with GCC 8:
 ../../../src/intel/tools/aubinator_error_decode.c: In function 'main':
 ../../../src/intel/tools/aubinator_error_decode.c:759:11: warning: variable 
'ret' set but not used [-Wunused-but-set-variable]
int ret;
^~~

Signed-off-by: Kai Wasserbäch 
---
 src/intel/tools/aubinator_error_decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/aubinator_error_decode.c 
b/src/intel/tools/aubinator_error_decode.c
index 4e3359bba9..d7f9d9f2af 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -756,7 +756,7 @@ main(int argc, char *argv[])
   setup_pager();
 
if (S_ISDIR(st.st_mode)) {
-  int ret;
+  MAYBE_UNUSED int ret;
   char *filename;
 
   ret = asprintf(&filename, "%s/i915_error_state", path);
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 03/12] amd/addrlib: mark *pEqToCheck as MAYBE_UNUSED in Addr::V2::Gfx9Lib::ComputeStereoInfo

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/amd/addrlib/gfx9/gfx9addrlib.cpp: In member function 
'ADDR_E_RETURNCODE Addr::V2::Gfx9Lib::ComputeStereoInfo(const 
ADDR2_COMPUTE_SURFACE_INFO_INPUT*, ADDR2_COMPUTE_SURFACE_INFO_OUTPUT*, unsigned 
int*) const':
 ../../../src/amd/addrlib/gfx9/gfx9addrlib.cpp:3879:34: warning: unused 
variable 'pEqToCheck' [-Wunused-variable]
  const ADDR_EQUATION *pEqToCheck= 
&m_equationTable[eqIndex];
   ^~

Cc: Marek Olšák 
Signed-off-by: Kai Wasserbäch 
---
 src/amd/addrlib/gfx9/gfx9addrlib.cpp | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/amd/addrlib/gfx9/gfx9addrlib.cpp 
b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
index 853a041158..524b0f6e82 100644
--- a/src/amd/addrlib/gfx9/gfx9addrlib.cpp
+++ b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
@@ -3873,12 +3873,12 @@ ADDR_E_RETURNCODE Gfx9Lib::ComputeStereoInfo(
 {
 if (IsXor(pIn->swizzleMode))
 {
-const UINT_32blkSizeLog2   = 
GetBlockSizeLog2(pIn->swizzleMode);
-const UINT_32numPipeBits   = 
GetPipeXorBits(blkSizeLog2);
-const UINT_32numBankBits   = 
GetBankXorBits(blkSizeLog2);
-const UINT_32bppLog2   = Log2(pIn->bpp >> 3);
-const UINT_32maxYCoordBlock256 = 
Log2(Block256_2d[bppLog2].h) - 1;
-const ADDR_EQUATION *pEqToCheck= &m_equationTable[eqIndex];
+const UINT_32 blkSizeLog2   = 
GetBlockSizeLog2(pIn->swizzleMode);
+const UINT_32 numPipeBits   = 
GetPipeXorBits(blkSizeLog2);
+const UINT_32 numBankBits   = 
GetBankXorBits(blkSizeLog2);
+const UINT_32 bppLog2   = 
Log2(pIn->bpp >> 3);
+const UINT_32 maxYCoordBlock256 = 
Log2(Block256_2d[bppLog2].h) - 1;
+MAYBE_UNUSED const ADDR_EQUATION *pEqToCheck= 
&m_equationTable[eqIndex];
 
 ADDR_ASSERT(maxYCoordBlock256 ==
 GetMaxValidChannelIndex(&pEqToCheck->addr[0], 
GetBlockSizeLog2(ADDR_SW_256B), 1));
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 05/12] amd/addrlib: mark physicalSliceSize as MAYBE_UNUSED in Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-but-set-variable warning with GCC 8:
 ../../../src/amd/addrlib/r800/egbaddrlib.cpp: In member function 'virtual long 
long unsigned int Addr::V1::EgBasedLib::HwlGetSizeAdjustmentMicroTiled(unsigned 
int, unsigned int, ADDR_SURFACE_FLAGS, unsigned int, unsigned int, unsigned 
int, unsigned int*, unsigned int*) const':
 ../../../src/amd/addrlib/r800/egbaddrlib.cpp:4111:13: warning: variable 
'physicalSliceSize' set but not used [-Wunused-but-set-variable]
  UINT_64 physicalSliceSize;
  ^

Cc: Marek Olšák 
Signed-off-by: Kai Wasserbäch 
---
 src/amd/addrlib/r800/egbaddrlib.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/addrlib/r800/egbaddrlib.cpp 
b/src/amd/addrlib/r800/egbaddrlib.cpp
index 37a60c7a85..edc7a13070 100644
--- a/src/amd/addrlib/r800/egbaddrlib.cpp
+++ b/src/amd/addrlib/r800/egbaddrlib.cpp
@@ -4110,7 +4110,7 @@ UINT_64 EgBasedLib::HwlGetSizeAdjustmentMicroTiled(
 ) const
 {
 UINT_64 logicalSliceSize;
-UINT_64 physicalSliceSize;
+MAYBE_UNUSED UINT_64 physicalSliceSize;
 
 UINT_32 pitch   = *pPitch;
 UINT_32 height  = *pHeight;
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 01/12] amd/addrlib: mark returnCode as MAYBE_UNUSED in ElemGetExportNorm

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-but-set-variable warning with GCC 8:
 ../../../src/amd/addrlib/addrinterface.cpp: In function 'int 
ElemGetExportNorm(ADDR_HANDLE, const ELEM_GETEXPORTNORM_INPUT*)':
 ../../../src/amd/addrlib/addrinterface.cpp:835:23: warning: variable 
'returnCode' set but not used [-Wunused-but-set-variable]
  ADDR_E_RETURNCODE returnCode = ADDR_OK;
^~

Cc: Marek Olšák 
Signed-off-by: Kai Wasserbäch 
---
 src/amd/Makefile.addrlib.am   | 1 +
 src/amd/addrlib/addrinterface.cpp | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
index 75ff7fbcf7..af0daf907d 100644
--- a/src/amd/Makefile.addrlib.am
+++ b/src/amd/Makefile.addrlib.am
@@ -24,6 +24,7 @@ ADDRLIB_LIBS = addrlib/libamdgpu_addrlib.la
 addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
$(DEFINES) \
-I$(top_srcdir)/src/ \
+   -I$(top_srcdir)/include \
-I$(srcdir)/common \
-I$(srcdir)/addrlib \
-I$(srcdir)/addrlib/core \
diff --git a/src/amd/addrlib/addrinterface.cpp 
b/src/amd/addrlib/addrinterface.cpp
index 112431e2cb..9cbeba41d9 100644
--- a/src/amd/addrlib/addrinterface.cpp
+++ b/src/amd/addrlib/addrinterface.cpp
@@ -36,6 +36,8 @@
 
 #include "addrcommon.h"
 
+#include "util/macros.h"
+
 using namespace Addr;
 
 

@@ -832,7 +834,7 @@ BOOL_32 ADDR_API ElemGetExportNorm(
 Addr::Lib* pLib = Lib::GetLib(hLib);
 BOOL_32 enabled = FALSE;
 
-ADDR_E_RETURNCODE returnCode = ADDR_OK;
+MAYBE_UNUSED ADDR_E_RETURNCODE returnCode = ADDR_OK;
 
 if (pLib != NULL)
 {
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 07/12] intel: aubinator: mark ftruncate_res as MAYBE_UNUSED in ensure_phys_mem

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with GCC 8:
 ../../../src/intel/tools/aubinator.c: In function 'ensure_phys_mem':
 ../../../src/intel/tools/aubinator.c:209:11: warning: unused variable 
'ftruncate_res' [-Wunused-variable]
int ftruncate_res = ftruncate(mem_fd, mem_fd_len += 4096);
^~~~~

Signed-off-by: Kai Wasserbäch 
---
 src/intel/tools/aubinator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 9a3b1d1ef1..66a7db1043 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -206,7 +206,7 @@ ensure_phys_mem(uint64_t phys_addr)
   new_mem->phys_addr = phys_addr;
   new_mem->fd_offset = mem_fd_len;
 
-  int ftruncate_res = ftruncate(mem_fd, mem_fd_len += 4096);
+  MAYBE_UNUSED int ftruncate_res = ftruncate(mem_fd, mem_fd_len += 4096);
   assert(ftruncate_res == 0);
 
   new_mem->data = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED,
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] amd/addrlib: mark returnCode as MAYBE_UNUSED in ElemGetExportNorm

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-but-set-variable warning with GCC 8:
 ../../../src/amd/addrlib/addrinterface.cpp: In function 'int 
ElemGetExportNorm(ADDR_HANDLE, const ELEM_GETEXPORTNORM_INPUT*)':
 ../../../src/amd/addrlib/addrinterface.cpp:835:23: warning: variable 
'returnCode' set but not used [-Wunused-but-set-variable]
  ADDR_E_RETURNCODE returnCode = ADDR_OK;
^~~~~~

Signed-off-by: Kai Wasserbäch 
---
 src/amd/Makefile.addrlib.am   | 1 +
 src/amd/addrlib/addrinterface.cpp | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
index 75ff7fbcf7..af0daf907d 100644
--- a/src/amd/Makefile.addrlib.am
+++ b/src/amd/Makefile.addrlib.am
@@ -24,6 +24,7 @@ ADDRLIB_LIBS = addrlib/libamdgpu_addrlib.la
 addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
$(DEFINES) \
-I$(top_srcdir)/src/ \
+   -I$(top_srcdir)/include \
-I$(srcdir)/common \
-I$(srcdir)/addrlib \
-I$(srcdir)/addrlib/core \
diff --git a/src/amd/addrlib/addrinterface.cpp 
b/src/amd/addrlib/addrinterface.cpp
index 112431e2cb..9cbeba41d9 100644
--- a/src/amd/addrlib/addrinterface.cpp
+++ b/src/amd/addrlib/addrinterface.cpp
@@ -36,6 +36,8 @@
 
 #include "addrcommon.h"
 
+#include "util/macros.h"
+
 using namespace Addr;
 
 

@@ -832,7 +834,7 @@ BOOL_32 ADDR_API ElemGetExportNorm(
 Addr::Lib* pLib = Lib::GetLib(hLib);
 BOOL_32 enabled = FALSE;
 
-ADDR_E_RETURNCODE returnCode = ADDR_OK;
+MAYBE_UNUSED ADDR_E_RETURNCODE returnCode = ADDR_OK;
 
 if (pLib != NULL)
 {
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4] nir: mark *prev_block as MAYBE_UNUSED in opt_peel_loop_initial_if

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with gcc-8:
 ../../../src/compiler/nir/nir_opt_if.c: In function 'opt_peel_loop_initial_if':
 ../../../src/compiler/nir/nir_opt_if.c:109:15: warning: unused variable 
'prev_block' [-Wunused-variable]
 nir_block *prev_block =
^~~~~~

Signed-off-by: Kai Wasserbäch 
---
 src/compiler/nir/nir_opt_if.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index b3d0bf1dec..dacf2d6c66 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -106,7 +106,7 @@ static bool
 opt_peel_loop_initial_if(nir_loop *loop)
 {
nir_block *header_block = nir_loop_first_block(loop);
-   nir_block *prev_block =
+   MAYBE_UNUSED nir_block *prev_block =
   nir_cf_node_as_block(nir_cf_node_prev(&loop->cf_node));
 
/* It would be insane if this were not true */
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] util: mark s as MAYBE_UNUSED in _mesa_half_to_unorm8

[Kai Wasserbäch]

Only used, when asserts are enabled.

Fixes an unused-variable warning with gcc-8:
 ../../../src/util/half_float.c: In function '_mesa_half_to_unorm8':
 ../../../src/util/half_float.c:189:14: warning: unused variable 's' 
[-Wunused-variable]
 const int s = (val >> 15) & 0x1;
       ^

Signed-off-by: Kai Wasserbäch 
---
 src/util/half_float.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/util/half_float.c b/src/util/half_float.c
index 2eff2c84f5..63aec5c5c1 100644
--- a/src/util/half_float.c
+++ b/src/util/half_float.c
@@ -28,6 +28,7 @@
 #include 
 #include "half_float.h"
 #include "rounding.h"
+#include "macros.h"
 
 typedef union { float f; int32_t i; uint32_t u; } fi_type;
 
@@ -186,7 +187,7 @@ uint8_t _mesa_half_to_unorm8(uint16_t val)
 {
const int m = val & 0x3ff;
const int e = (val >> 10) & 0x1f;
-   const int s = (val >> 15) & 0x1;
+   MAYBE_UNUSED const int s = (val >> 15) & 0x1;
 
/* v = round_to_nearest(1.mm * 2^(e-15) * 255)
 *   = round_to_nearest((1.mm * 255) * 2^(e-15))
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] vulkan/wsi: initialise image_index to 0 in x11_manage_fifo_queues

[Kai Wasserbäch]

Supresses a maybe-uninitialized warning with GCC 8.

Note: image_index should always be initialised due to the result check,
  but the compiler doesn't see that.
Signed-off-by: Kai Wasserbäch 
---
 src/vulkan/wsi/wsi_common_x11.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 7e7b3a94e4..7b930884b4 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -991,7 +991,7 @@ x11_manage_fifo_queues(void *state)
* before that point so the client should be able to acquire any image
* other than the currently presented one.
*/
-  uint32_t image_index;
+  uint32_t image_index = 0;
   result = wsi_queue_pull(&chain->present_queue, &image_index, INT64_MAX);
   assert(result != VK_TIMEOUT);
   if (result < 0) {
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/4] Fix some compile warnings

[Kai Wasserbäch]

Hey,
while building Mesa I saw several warnings scroll by and this series
addresses the first four I saw in my build log.

The changes have been compile-tested in a clean chroot (pbuilder)
environment.

If you accept the patches, please apply them for me, as I don't have
commit access for Mesa. The commits can also be found on GitLab
<https://gitlab.freedesktop.org/curan/mesa/commits/fix-some-warnings>.

Cheers,
Kai


Kai Wasserbäch (4):
  util: mark s as MAYBE_UNUSED in _mesa_half_to_unorm8
  nir: mark *prev_block as MAYBE_UNUSED in opt_peel_loop_initial_if
  vulkan/wsi: initialise image_index to 0 in x11_manage_fifo_queues
  amd/addrlib: mark returnCode as MAYBE_UNUSED in ElemGetExportNorm

 src/amd/Makefile.addrlib.am   | 1 +
 src/amd/addrlib/addrinterface.cpp | 4 +++-
 src/compiler/nir/nir_opt_if.c | 2 +-
 src/util/half_float.c | 3 ++-
 src/vulkan/wsi/wsi_common_x11.c   | 2 +-
 5 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Make sure that imm draws are flushed before other draws execute.

[Kai Wasserbäch]

Hey Mathias,
mathias.froehl...@gmx.net wrote on 02.06.2018 08:51:
> The below patch fixes a recently introduced failure of my VAO rework.
> I could finally reproduce the problem using the provided apitrace
> (thanks Kai for the hint with the lower left corner).

yw, thanks for looking into this!

> The change is slightly different than what I put initially into the
> bugreport.
> The patch survived piglit quick and dEQP in radeonsi and did not
> introduce regressions to the base version with intels CI system.
> 
> Please review!

I just confirmed that this version of the patch still resolves the bug with the
following graphics stack (fully updated Debian testing as a base):
- GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
- Mesa: Git:master/8841c2cda5 + 
<https://patchwork.freedesktop.org/patch/227095/>
- libdrm: 2.4.92-1
- LLVM: SVN:trunk/r333817 (7.0 devel)
- X.Org: 2:1.19.6-1
- Linux: 4.16.13
- Firmware (firmware-amd-graphics): 20170823-1
- libclc: Git:master/a2118d58fc
- DDX (xserver-xorg-video-amdgpu): 18.0.1-1
Therefore you can (still) have my
  Tested-by: Kai Wasserbäch 

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

[Kai Wasserbäch]

Hey Jan,
Jan Vesely wrote on 15.05.2018 04:50:
> I've pushed the patch.

thank you very much! I went ahead and closed the associated bug in the meantime.

> I've also kept the stable tag although the
> policy is (afaik) to only support llvm versions available at the point
> of mesa release. Don't be surprised to see some pushback from stable
> maintainers.

Ok, thanks for the heads-up. I won't fight too hard, since I'm only interested
in master. Though I do think it might be a good idea for at least 18.1. Anyway,
we'll see what the stable release managers think. ☺️

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

[Kai Wasserbäch]

Ping! Can somebody *please* commit this patch? It fixes an FTBFS, has two T-b
and one A-b.


Kai Wasserbäch wrote on 07.05.2018 16:48:
> Jan Vesely wrote on 02.05.2018 22:38:
>> On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote:
>>> [...]
>>
>> Thank for looking into this. We probably need CLANG_LIBS handling
>> similar to LLVM_LIBS. I agree this is the best fix for now.
>>
>> Acked-by: Jan Vesely 
>>
>> libclang.so might be a solkution, but I'm not sure how it interacts
>> with older or static build clang. It's also weird that we are linking
>> to clang here instead of clover which actually uses clang symbols.
>>
>> @Emil, are you OK with this patch?
> 
> Gentle ping.
> 
>>>>>>> -lclangDriver \
>>>>>>> -lclangSerialization \
>>>>>>> -   -lclangCodeGen \
>>>>>>
>>>>>> Is this change related?
>>>>>
>>>>> Not really, just a minor clean-up while I was busy a few lines above.
>>>>> "clangCodeGen" is already named on the first Clang library line.
>>>>
>>>> ah, all right, maybe mention it in the commit message?
>>>
>>> Do I need to resend the patch for that or can you just add a line like "This
>>> change also removes the duplicate clangCodeGen line (trivial change)." 
>>> before
>>> pushing, considering, that there are two T-b tags to be added anyway?
>>
>> I'll add it on my side before pushing the patch.
> 
> Thanks a lot!
> 
> Cheers,
> Kai
> 
> 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

[Kai Wasserbäch]

Jan Vesely wrote on 02.05.2018 22:38:
> On Wed, 2018-05-02 at 18:38 +0200, Kai Wasserbäch wrote:
>> [...]
> 
> Thank for looking into this. We probably need CLANG_LIBS handling
> similar to LLVM_LIBS. I agree this is the best fix for now.
> 
> Acked-by: Jan Vesely 
> 
> libclang.so might be a solkution, but I'm not sure how it interacts
> with older or static build clang. It's also weird that we are linking
> to clang here instead of clover which actually uses clang symbols.
> 
> @Emil, are you OK with this patch?

Gentle ping.

>>>>>>  -lclangDriver \
>>>>>>  -lclangSerialization \
>>>>>> --lclangCodeGen \
>>>>>
>>>>> Is this change related?
>>>>
>>>> Not really, just a minor clean-up while I was busy a few lines above.
>>>> "clangCodeGen" is already named on the first Clang library line.
>>>
>>> ah, all right, maybe mention it in the commit message?
>>
>> Do I need to resend the patch for that or can you just add a line like "This
>> change also removes the duplicate clangCodeGen line (trivial change)." before
>> pushing, considering, that there are two T-b tags to be added anyway?
> 
> I'll add it on my side before pushing the patch.

Thanks a lot!

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

[Kai Wasserbäch]

Hey Jan,
Jan Vesely wrote on 01.05.2018 23:59:
> On Tue, 2018-05-01 at 18:23 +0200, Kai Wasserbäch wrote:
>> Jan Vesely wrote on 01.05.2018 17:19:
>>> On Tue, 2018-05-01 at 14:14 +0200, Kai Wasserbäch wrote:
>>>> [...]
>>>>
>>>>  src/gallium/targets/opencl/Makefile.am | 3 +--
>>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/src/gallium/targets/opencl/Makefile.am 
>>>> b/src/gallium/targets/opencl/Makefile.am
>>>> index de68a93ad5..f0e1de7797 100644
>>>> --- a/src/gallium/targets/opencl/Makefile.am
>>>> +++ b/src/gallium/targets/opencl/Makefile.am
>>>> @@ -23,11 +23,10 @@ lib@OPENCL_LIBNAME@_la_LIBADD = \
>>>>$(LIBELF_LIBS) \
>>>>$(DLOPEN_LIBS) \
>>>>-lclangCodeGen \
>>>> -  -lclangFrontendTool \
>>>>-lclangFrontend \
>>>> +  -lclangFrontendTool \
>>>
>>> This is strange. Why does reordering help here? Do we use -Wl,--as-
>>> needed anywhere?
>>
>> No, not that I can see.
>>
>>> Should we use -Wl,--start-group/-Wl,--end-group for all clang libraries
>>> instead?
>>
>> Maybe? This was the simplest fix I could come up with, but if there's a
>> preference for a link group, I can give that a try as well.
> 
> So the fix is to change ordering?

yes.

> Does using groups fix the issue as well? I think that would be
> preferable, but I use split .so files, so I don't hit this issue.

I tried convincing autotools to work with those flags but failed. The only
option I see to solve this, is very messy IMHO (and would still need the
ordering fix): putting -Wl,--{start,end}-group directly into the right places in
lib@OPENCL_LIBNAME@_la_LIBADD is forbidden by automake ("error: linker flags
such as '-Wl,--start-group' belong in 'lib@OPENCL_LIBNAME@_la_LDFLAGS'") and
adding them to lib@OPENCL_LIBNAME@_la_LDFLAGS like automake is suggesting won't
work for obvious reasons. The only solution I can see is to work with
substitution because automake seems to "not see" the flags then. I could do an
unconditional replacement, but there are probably linkers with no support for
these flags, which would mean I'd have to do the ordering fix in any case and
then conditionally set "-Wl,--{start,end}-group" just for the GNU toolchain with
no immediate benefit beyond future-proofing this section.
But maybe people who are deeper into the whole autotools stuff (Emil?
Francisco?) can point me to a solution? Otherwise I'd like to return to my
original patch which fixes the FTBFS and works for now. Or maybe the library
could be linked against libclang.so (at least when --enable-llvm-shared-libs is 
set?

>>>>-lclangDriver \
>>>>-lclangSerialization \
>>>> -  -lclangCodeGen \
>>>
>>> Is this change related?
>>
>> Not really, just a minor clean-up while I was busy a few lines above.
>> "clangCodeGen" is already named on the first Clang library line.
> 
> ah, all right, maybe mention it in the commit message?

Do I need to resend the patch for that or can you just add a line like "This
change also removes the duplicate clangCodeGen line (trivial change)." before
pushing, considering, that there are two T-b tags to be added anyway?

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

[Kai Wasserbäch]

Hey Jan,
Jan Vesely wrote on 01.05.2018 17:19:
> On Tue, 2018-05-01 at 14:14 +0200, Kai Wasserbäch wrote:
>> Otherwise the build fails with an undefined reference to
>> clang::FrontendTimesIsEnabled.
>>
>> Bugzilla: https://bugs.freedesktop.org/106209
>> Cc: mesa-sta...@lists.freedesktop.org
>> Cc: Jan Vesely 
>> Signed-off-by: Kai Wasserbäch 
>> ---
>>
>> Hey,
>> this patch fixes a FTBFS for me with recent LLVM/Clang 7 revisions from
>> upstream's SVN (I use the packages from apt.llvm.org).
>>
>> If you accept it, please commit it for me, I do not have commit access.
>>
>> The CC to stable can be dropped, if stable branches are not to be
>> expected to be buildable with LLVM/Clang from SVN.
> 
> thanks for looking into this. TBH I don't understand how this patch
> works, it's dropping and reordering linked libraries.
> I've added Emil and Francisco to cc.

the removal is just the removal of a duplicate line (the first Clang library
named is already "clangCodeGen"). And AFAICT there's no "-Wl,--as-needed" in
use. At least I don't find anything in the build logs.

>>  src/gallium/targets/opencl/Makefile.am | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/targets/opencl/Makefile.am 
>> b/src/gallium/targets/opencl/Makefile.am
>> index de68a93ad5..f0e1de7797 100644
>> --- a/src/gallium/targets/opencl/Makefile.am
>> +++ b/src/gallium/targets/opencl/Makefile.am
>> @@ -23,11 +23,10 @@ lib@OPENCL_LIBNAME@_la_LIBADD = \
>>  $(LIBELF_LIBS) \
>>  $(DLOPEN_LIBS) \
>>  -lclangCodeGen \
>> --lclangFrontendTool \
>>  -lclangFrontend \
>> +-lclangFrontendTool \
> 
> This is strange. Why does reordering help here? Do we use -Wl,--as-
> needed anywhere?

No, not that I can see.

> Should we use -Wl,--start-group/-Wl,--end-group for all clang libraries
> instead?

Maybe? This was the simplest fix I could come up with, but if there's a
preference for a link group, I can give that a try as well.

>>  -lclangDriver \
>>  -lclangSerialization \
>> --lclangCodeGen \
> 
> Is this change related?

Not really, just a minor clean-up while I was busy a few lines above.
"clangCodeGen" is already named on the first Clang library line.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] opencl: autotools: Fix linking order for OpenCL target

[Kai Wasserbäch]

Otherwise the build fails with an undefined reference to
clang::FrontendTimesIsEnabled.

Bugzilla: https://bugs.freedesktop.org/106209
Cc: mesa-sta...@lists.freedesktop.org
Cc: Jan Vesely 
Signed-off-by: Kai Wasserbäch 
---

Hey,
this patch fixes a FTBFS for me with recent LLVM/Clang 7 revisions from
upstream's SVN (I use the packages from apt.llvm.org).

If you accept it, please commit it for me, I do not have commit access.

The CC to stable can be dropped, if stable branches are not to be
expected to be buildable with LLVM/Clang from SVN.

Thank you in advance for considering this patch.

Cheers,
Kai


 src/gallium/targets/opencl/Makefile.am | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/targets/opencl/Makefile.am 
b/src/gallium/targets/opencl/Makefile.am
index de68a93ad5..f0e1de7797 100644
--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -23,11 +23,10 @@ lib@OPENCL_LIBNAME@_la_LIBADD = \
$(LIBELF_LIBS) \
$(DLOPEN_LIBS) \
-lclangCodeGen \
-   -lclangFrontendTool \
-lclangFrontend \
+   -lclangFrontendTool \
-lclangDriver \
-lclangSerialization \
-   -lclangCodeGen \
-lclangParse \
-lclangSema \
-lclangAnalysis \
-- 
2.17.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: expose 0 shader binary formats for compat profiles for Qt

[Kai Wasserbäch]

Hey Marek,
you can have my
  Tested-by: Kai Wasserbäch 
for this patch.

Test case: updating libLLVM.so without rebuilding Mesa or building a new kernel
caused a white screen (plus correctly show mouse cursor) on the next launch of
SDDM. Deleting the mesa_shader_cache and qtshadercache directories for root and
my user didn't bring any changes. I'm on a Qt version < 5.9.5, which should have
the Qt fix for this issue. No error was logged to sddm.log, Xorg.0.log or dmesg.

With this patch applied SDDM starts normally after updating only libLLVM.so

The full stack (fully updated Debian testing as a base) is:
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/0c983b9094 + this patch
libdrm: 2.4.90-1
LLVM: SVN:trunk/r326425 (7.0 devel)
X.Org: 2:1.19.6-1
Linux: 4.15.7
Firmware (firmware-amd-graphics): 20170823-1
libclc: Git:master/d20b120f30
DDX (xserver-xorg-video-amdgpu): 1.4.0-1

Cheers,
Kai


Marek Olšák wrote on 23.02.2018 20:47:
> From: Marek Olšák 
> 
> Bugzilla: https://bugreports.qt.io/browse/QTBUG-66420
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105065
> Cc: "18.0" 
> ---
>  src/mesa/state_tracker/st_context.c|  2 +-
>  src/mesa/state_tracker/st_extensions.c | 14 +++---
>  src/mesa/state_tracker/st_extensions.h |  3 ++-
>  src/mesa/state_tracker/st_manager.c|  2 +-
>  4 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_context.c 
> b/src/mesa/state_tracker/st_context.c
> index e23f9fd..dfdd92f 100644
> --- a/src/mesa/state_tracker/st_context.c
> +++ b/src/mesa/state_tracker/st_context.c
> @@ -461,21 +461,21 @@ st_create_context_priv(struct gl_context *ctx, struct 
> pipe_context *pipe,
>screen->get_param(screen, PIPE_CAP_TGSI_PACK_HALF_FLOAT);
> st->has_multi_draw_indirect =
>screen->get_param(screen, PIPE_CAP_MULTI_DRAW_INDIRECT);
>  
> st->has_hw_atomics =
>screen->get_shader_param(screen, PIPE_SHADER_FRAGMENT,
> PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS)
>? true : false;
>  
> /* GL limits and extensions */
> -   st_init_limits(pipe->screen, &ctx->Const, &ctx->Extensions);
> +   st_init_limits(pipe->screen, &ctx->Const, &ctx->Extensions, ctx->API);
> st_init_extensions(pipe->screen, &ctx->Const,
>&ctx->Extensions, &st->options, ctx->API);
>  
> if (st_have_perfmon(st)) {
>ctx->Extensions.AMD_performance_monitor = GL_TRUE;
> }
>  
> /* Enable shader-based fallbacks for ARB_color_buffer_float if needed. */
> if (screen->get_param(screen, PIPE_CAP_VERTEX_COLOR_UNCLAMPED)) {
>if (!screen->get_param(screen, PIPE_CAP_VERTEX_COLOR_CLAMPED)) {
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 42d53cb..4bd5404 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -68,21 +68,22 @@ static int _clamp(int a, int min, int max)
> else
>return a;
>  }
>  
>  
>  /**
>   * Query driver to get implementation limits.
>   * Note that we have to limit/clamp against Mesa's internal limits too.
>   */
>  void st_init_limits(struct pipe_screen *screen,
> -struct gl_constants *c, struct gl_extensions *extensions)
> +struct gl_constants *c, struct gl_extensions *extensions,
> +gl_api api)
>  {
> int supported_irs;
> unsigned sh;
> boolean can_ubo = TRUE;
> int temp;
> bool ssbo_atomic = true;
>  
> c->MaxTextureLevels
>= _min(screen->get_param(screen, PIPE_CAP_MAX_TEXTURE_2D_LEVELS),
>  MAX_TEXTURE_LEVELS);
> @@ -430,22 +431,29 @@ void st_init_limits(struct pipe_screen *screen,
>   c->Program[MESA_SHADER_FRAGMENT].MaxUniformBlocks +
>   c->Program[MESA_SHADER_COMPUTE].MaxUniformBlocks;
>assert(c->MaxCombinedUniformBlocks <= MAX_COMBINED_UNIFORM_BUFFERS);
> }
>  
> c->GLSLFragCoordIsSysVal =
>screen->get_param(screen, PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL);
> c->GLSLFrontFacingIsSysVal =
>screen->get_param(screen, PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL);
>  
> -   /* GL_ARB_get_program_binary */
> -   if (screen->get_disk_shader_cache && 
> screen->get_disk_shader_cache(screen))
> +   /* GL_ARB_get_program_binary
> +*
> +* The QT framework has a bug in their shader program cache, which is 
> built
> +* on GL_ARB_get_program_binary. In an effort to allow them to fix the bug
> +* we don't enable mo

Re: [Mesa-dev] [PATCH] ac/nir: call glsl_get_sampler_dim() only once, where possible (v2)

[Kai Wasserbäch]

Ping. This patch has a T-b by Dieter Nützel (including v2), any R-b and commit
would be much appreciated.

(Timothy indicated on Wednesday he would try to commit this
(<https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=dri-devel&date=2018-01-24#t-0912>),
but I guess it must have slipped through the cracks.)


Kai Wasserbäch wrote on 23.01.2018 21:14:
> Changes since v1:
>   * Rebased on top of e68150de263156a3f3d1b609b6506c5649967f61 and
> 82adf53308c137ce0dc5f2d5da4e7cc40c5b808c.
> 
> Cc: Timothy Arceri 
> Tested-by: Dieter Nützel  (v1)
> Signed-off-by: Kai Wasserbäch 
> ---
> 
> Hey,
> if you accept this patch, please commit it for me – I do not have commit
> access. This is v2, which is needed since the above mentioned changes
> by Timothy went in first.
> 
> Thanks,
> Kai
> 
>  src/amd/common/ac_nir_to_llvm.c | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index cc3af77386..0fba5a1068 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -3620,7 +3620,9 @@ static LLVMValueRef visit_image_load(struct 
> ac_nir_context *ctx,
>   type = instr->variables[0]->deref.child->type;
>  
>   type = glsl_without_array(type);
> - if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
> +
> + const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
> + if (dim == GLSL_SAMPLER_DIM_BUF) {
>   params[0] = get_sampler_desc(ctx, instr->variables[0], 
> AC_DESC_BUFFER, NULL, true, false);
>   params[1] = LLVMBuildExtractElement(ctx->ac.builder, 
> get_src(ctx, instr->src[0]),
>   ctx->ac.i32_0, ""); /* 
> vindex */
> @@ -3634,10 +3636,10 @@ static LLVMValueRef visit_image_load(struct 
> ac_nir_context *ctx,
>   res = ac_to_integer(&ctx->ac, res);
>   } else {
>   bool is_da = glsl_sampler_type_is_array(type) ||
> -  glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_CUBE ||
> -  glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D 
> ||
> -  glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_SUBPASS ||
> -  glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_SUBPASS_MS;
> +  dim == GLSL_SAMPLER_DIM_CUBE ||
> +  dim == GLSL_SAMPLER_DIM_3D ||
> +  dim == GLSL_SAMPLER_DIM_SUBPASS ||
> +  dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
>   LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
>   LLVMValueRef glc = ctx->ac.i1false;
>   LLVMValueRef slc = ctx->ac.i1false;
> @@ -3677,12 +3679,13 @@ static void visit_image_store(struct ac_nir_context 
> *ctx,
>   char intrinsic_name[64];
>   const nir_variable *var = instr->variables[0]->var;
>   const struct glsl_type *type = glsl_without_array(var->type);
> + const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
>   LLVMValueRef glc = ctx->ac.i1false;
>   bool force_glc = ctx->ac.chip_class == SI;
>   if (force_glc)
>   glc = ctx->ac.i1true;
>  
> - if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
> + if (dim == GLSL_SAMPLER_DIM_BUF) {
>   params[0] = ac_to_float(&ctx->ac, get_src(ctx, instr->src[2])); 
> /* data */
>   params[1] = get_sampler_desc(ctx, instr->variables[0], 
> AC_DESC_BUFFER, NULL, true, true);
>   params[2] = LLVMBuildExtractElement(ctx->ac.builder, 
> get_src(ctx, instr->src[0]),
> @@ -3694,8 +3697,8 @@ static void visit_image_store(struct ac_nir_context 
> *ctx,
>  params, 6, 0);
>   } else {
>   bool is_da = glsl_sampler_type_is_array(type) ||
> -  glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_CUBE ||
> -  glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D;
> +  dim == GLSL_SAMPLER_DIM_CUBE ||
> +  dim == GLSL_SAMPLER_DIM_3D;
>   LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
>   LLVMValueRef slc = ctx->ac.i1false;
>  
> 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac/nir: call glsl_get_sampler_dim() only once, where possible (v2)

[Kai Wasserbäch]

Changes since v1:
  * Rebased on top of e68150de263156a3f3d1b609b6506c5649967f61 and
82adf53308c137ce0dc5f2d5da4e7cc40c5b808c.

Cc: Timothy Arceri 
Tested-by: Dieter Nützel  (v1)
Signed-off-by: Kai Wasserbäch 
---

Hey,
if you accept this patch, please commit it for me – I do not have commit
access. This is v2, which is needed since the above mentioned changes
by Timothy went in first.

Thanks,
Kai

 src/amd/common/ac_nir_to_llvm.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cc3af77386..0fba5a1068 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3620,7 +3620,9 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
type = instr->variables[0]->deref.child->type;
 
type = glsl_without_array(type);
-   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
+
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
+   if (dim == GLSL_SAMPLER_DIM_BUF) {
params[0] = get_sampler_desc(ctx, instr->variables[0], 
AC_DESC_BUFFER, NULL, true, false);
params[1] = LLVMBuildExtractElement(ctx->ac.builder, 
get_src(ctx, instr->src[0]),
ctx->ac.i32_0, ""); /* 
vindex */
@@ -3634,10 +3636,10 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
res = ac_to_integer(&ctx->ac, res);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
-glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D 
||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS_MS;
+dim == GLSL_SAMPLER_DIM_CUBE ||
+dim == GLSL_SAMPLER_DIM_3D ||
+dim == GLSL_SAMPLER_DIM_SUBPASS ||
+dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef glc = ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;
@@ -3677,12 +3679,13 @@ static void visit_image_store(struct ac_nir_context 
*ctx,
char intrinsic_name[64];
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = glsl_without_array(var->type);
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
LLVMValueRef glc = ctx->ac.i1false;
bool force_glc = ctx->ac.chip_class == SI;
if (force_glc)
glc = ctx->ac.i1true;
 
-   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
+   if (dim == GLSL_SAMPLER_DIM_BUF) {
params[0] = ac_to_float(&ctx->ac, get_src(ctx, instr->src[2])); 
/* data */
params[1] = get_sampler_desc(ctx, instr->variables[0], 
AC_DESC_BUFFER, NULL, true, true);
params[2] = LLVMBuildExtractElement(ctx->ac.builder, 
get_src(ctx, instr->src[0]),
@@ -3694,8 +3697,8 @@ static void visit_image_store(struct ac_nir_context *ctx,
   params, 6, 0);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
-glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D;
+dim == GLSL_SAMPLER_DIM_CUBE ||
+dim == GLSL_SAMPLER_DIM_3D;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;
 
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] ac: fix image load store for GLSL_SAMPLER_DIM_3D

[Kai Wasserbäch]

Hey,
Nicolai Hähnle wrote on 22.01.2018 14:18:
> On 20.01.2018 04:11, Timothy Arceri wrote:
>> Fixes the following piglit tests:
>>
>> arb_shader_image_load_store/layer/image3d/layered binding test
>> arb_shader_image_load_store/max-size/image3d max size test/2048x8x8x1
>> arb_shader_image_load_store/max-size/image3d max size test/8x2048x8x1
>> arb_shader_image_load_store/max-size/image3d max size test/8x8x2048x1
>> arb_shader_image_load_store/semantics/imageload/vertex shader/rgba32f/image3d
>> test
> 
> Reviewed-by: Nicolai Hähnle 
> 
> 
>> ---
>>   src/amd/common/ac_nir_to_llvm.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c 
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 781e4a905b..ac3a949bd3 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -3634,6 +3634,7 @@ static LLVMValueRef visit_image_load(struct
>> ac_nir_context *ctx,
>>   } else {
>>   bool is_da = glsl_sampler_type_is_array(type) ||
>>    glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE ||
>> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D ||
>>    glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_SUBPASS ||
>>    glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_SUBPASS_MS;
>>   LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
>> @@ -3692,7 +3693,8 @@ static void visit_image_store(struct ac_nir_context 
>> *ctx,
>>  params, 6, 0);
>>   } else {
>>   bool is_da = glsl_sampler_type_is_array(type) ||
>> - glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
>> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE ||
>> + glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_3D;
>>   LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
>>   LLVMValueRef slc = ctx->ac.i1false;

just a note: if this patch goes in before my patch
(), assuming it'll be accepted,
I'd need to do a v2 patch, which applies cleanly on top of this change. The same
applies the other way around.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac/nir: call glsl_get_sampler_dim() only once, where possible

[Kai Wasserbäch]

Signed-off-by: Kai Wasserbäch 
---

Hey,
if you accept this patch, please commit it for me – I do not have commit
access.

Thanks,
Kai


 src/amd/common/ac_nir_to_llvm.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 2aef51be85..999e095019 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3622,7 +3622,9 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
type = instr->variables[0]->deref.child->type;
 
type = glsl_without_array(type);
-   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
+
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
+   if (dim == GLSL_SAMPLER_DIM_BUF) {
params[0] = get_sampler_desc(ctx, instr->variables[0], 
AC_DESC_BUFFER, NULL, true, false);
params[1] = LLVMBuildExtractElement(ctx->ac.builder, 
get_src(ctx, instr->src[0]),
ctx->ac.i32_0, ""); /* 
vindex */
@@ -3636,9 +3638,9 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
res = ac_to_integer(&ctx->ac, res);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_SUBPASS_MS;
+dim == GLSL_SAMPLER_DIM_CUBE ||
+dim == GLSL_SAMPLER_DIM_SUBPASS ||
+dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef glc = ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;
@@ -3678,12 +3680,13 @@ static void visit_image_store(struct ac_nir_context 
*ctx,
char intrinsic_name[64];
const nir_variable *var = instr->variables[0]->var;
const struct glsl_type *type = glsl_without_array(var->type);
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
LLVMValueRef glc = ctx->ac.i1false;
bool force_glc = ctx->ac.chip_class == SI;
if (force_glc)
glc = ctx->ac.i1true;
 
-   if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF) {
+   if (dim == GLSL_SAMPLER_DIM_BUF) {
params[0] = ac_to_float(&ctx->ac, get_src(ctx, instr->src[2])); 
/* data */
params[1] = get_sampler_desc(ctx, instr->variables[0], 
AC_DESC_BUFFER, NULL, true, true);
params[2] = LLVMBuildExtractElement(ctx->ac.builder, 
get_src(ctx, instr->src[0]),
@@ -3695,7 +3698,7 @@ static void visit_image_store(struct ac_nir_context *ctx,
   params, 6, 0);
} else {
bool is_da = glsl_sampler_type_is_array(type) ||
-glsl_get_sampler_dim(type) == 
GLSL_SAMPLER_DIM_CUBE;
+dim == GLSL_SAMPLER_DIM_CUBE;
LLVMValueRef da = is_da ? ctx->ac.i1true : ctx->ac.i1false;
LLVMValueRef slc = ctx->ac.i1false;
 
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: remove second include of errors.h in src/mesa/main/glspirv.c

[Kai Wasserbäch]

Hey Ian,
Ian Romanick wrote on 12.12.2017 17:56:
> Weird that this was not noticed before... *shrug*
> 
> Reviewed-by: Ian Romanick 

thank you very much for the R-b! Can you push this for me? I don't have commit
access.

Cheers,
Kai


> On 12/12/2017 07:20 AM, Kai Wasserbäch wrote:
>> Cc: Nicolai Hähnle 
>> Fixes: 5bc03d2508 ("mesa: implement SPIR-V loading in glShaderBinary")
>> Signed-off-by: Kai Wasserbäch 
>> ---
>>  src/mesa/main/glspirv.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
>> index 7eb8f906c2..81303057d0 100644
>> --- a/src/mesa/main/glspirv.c
>> +++ b/src/mesa/main/glspirv.c
>> @@ -22,11 +22,7 @@
>>   */
>>  
>>  #include "glspirv.h"
>> -
>> -#include "errors.h"
>> -
>>  #include "errors.h"
>> -
>>  #include "util/u_atomic.h"
>>  
>>  void



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: remove second include of errors.h in src/mesa/main/glspirv.c

[Kai Wasserbäch]

Cc: Nicolai Hähnle 
Fixes: 5bc03d2508 ("mesa: implement SPIR-V loading in glShaderBinary")
Signed-off-by: Kai Wasserbäch 
---
 src/mesa/main/glspirv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
index 7eb8f906c2..81303057d0 100644
--- a/src/mesa/main/glspirv.c
+++ b/src/mesa/main/glspirv.c
@@ -22,11 +22,7 @@
  */
 
 #include "glspirv.h"
-
-#include "errors.h"
-
 #include "errors.h"
-
 #include "util/u_atomic.h"
 
 void
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: try flushing unflushed fences in si_fence_finish even when timeout == 0

[Kai Wasserbäch]

Nicolai Hähnle wrote on 22.11.2017 17:52:
> From: Nicolai Hähnle 
> 
> Under certain conditions, waiting on a GL sync objects should act like
> a flush, regardless of the timeout.
> 
> Portal 2, CS:GO, and presumably other Source engine games rely on this
> behavior and hang during loading without this fix.
> 
> Fixes: bc65dcab3bc4 ("radeonsi: avoid syncing the driver thread in 
> si_fence_finish")

Tested-by: Kai Wasserbäch 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103902
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103904




signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] docs: Point to apt.llvm.org for development snapshot packages

[Kai Wasserbäch]

Can you push for me? I don't have access.

Eric Engestrom wrote on 16.11.2017 13:04:
> On Thursday, 2017-11-16 12:58:50 +0100, Kai Wasserbäch wrote:
>> Cc: Eric Engestrom 
> 
> Thanks!
> Reviewed-by: Eric Engestrom 
> 
>> Signed-off-by: Kai Wasserbäch 
>> ---
>>  docs/llvmpipe.html | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
>> index e4676920ed..12dccb5eae 100644
>> --- a/docs/llvmpipe.html
>> +++ b/docs/llvmpipe.html
>> @@ -50,6 +50,12 @@ It's the fastest software rasterizer for Mesa.
>>  
>>   aptitude install llvm-dev
>>  
>> +   
>> +   If you want development snaptshot builds of LLVM for Debian and derived
>> +   distributions like Ubuntu, you can use the APT repository at > +   href="https://apt.llvm.org/"; title="Debian Development packages for LLVM"
>> +   >apt.llvm.org, which are maintained by Debian's LLVM maintainer.
>> +   
>> 
>> For a RPM-based distribution do:
>> 
>> -- 
>> 2.15.0



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] docs: Point to apt.llvm.org for development snapshot packages

[Kai Wasserbäch]

Cc: Eric Engestrom 
Signed-off-by: Kai Wasserbäch 
---
 docs/llvmpipe.html | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
index e4676920ed..12dccb5eae 100644
--- a/docs/llvmpipe.html
+++ b/docs/llvmpipe.html
@@ -50,6 +50,12 @@ It's the fastest software rasterizer for Mesa.
 
  aptitude install llvm-dev
 
+   
+   If you want development snaptshot builds of LLVM for Debian and derived
+   distributions like Ubuntu, you can use the APT repository at https://apt.llvm.org/"; title="Debian Development packages for LLVM"
+   >apt.llvm.org, which are maintained by Debian's LLVM maintainer.
+   

For a RPM-based distribution do:

-- 
2.15.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amd: build addrlib with C++11

[Kai Wasserbäch]

Doesn't the meson.build file need the same change?

Nicolai Hähnle wrote on 15.11.2017 12:55:
> From: Nicolai Hähnle 
> 
> It is required for LLVM anyway.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103658
> Fixes: 7f33e94e43a6 ("amd/addrlib: update to latest version")
> ---
>  src/amd/Makefile.addrlib.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/amd/Makefile.addrlib.am b/src/amd/Makefile.addrlib.am
> index 46689637f9b..90dfe963445 100644
> --- a/src/amd/Makefile.addrlib.am
> +++ b/src/amd/Makefile.addrlib.am
> @@ -26,15 +26,15 @@ addrlib_libamdgpu_addrlib_la_CPPFLAGS = \
>   -I$(srcdir)/common \
>   -I$(srcdir)/addrlib \
>   -I$(srcdir)/addrlib/core \
>   -I$(srcdir)/addrlib/inc/chip/gfx9 \
>   -I$(srcdir)/addrlib/inc/chip/r800 \
>   -I$(srcdir)/addrlib/gfx9/chip \
>   -I$(srcdir)/addrlib/r800/chip \
>   -DBRAHMA_BUILD=1
>  
>  addrlib_libamdgpu_addrlib_la_CXXFLAGS = \
> - $(VISIBILITY_CXXFLAGS)
> + $(VISIBILITY_CXXFLAGS) $(CXX11_CXXFLAGS)
>  
>  noinst_LTLIBRARIES += $(ADDRLIB_LIBS)
>  
>  addrlib_libamdgpu_addrlib_la_SOURCES = $(ADDRLIB_FILES)



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 2/2] egl: drop EGL driver `name`

[Kai Wasserbäch]

I'm still good with this, thanks for reapplying!

Eric Engestrom wrote on 14.11.2017 18:26:
> This is a revert of Marek's 2cb9ab53dd3ae6850a26 revert.
> It was needed to revert the previous commit, and didn't have any issue
> itself.
> --
> 
> The "DRI2" name was reported as confusing when printing EGL infos (one
> user reported thinking DRI3 was not working on his X server), and the
> only alternative is Haiku, which can only be used on a Haiku machine.
> 
> The name therefore doesn't add any information that the user wouldn't
> know already, so let's just drop it.
> 
> Cc: Kai Wasserbäch 
> Suggested-by: Emil Velikov 
> Related-to: b174a1ae720cb404738c ("egl: Simplify the "driver" interface")
> Signed-off-by: Eric Engestrom 
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 2 --
>  src/egl/drivers/haiku/egl_haiku.cpp | 2 --
>  src/egl/main/eglapi.c   | 3 +--
>  src/egl/main/egldriver.c| 2 --
>  src/egl/main/egldriver.h| 2 --
>  5 files changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 7c63920c54624e0e674e..3dce5f82320b2465037a 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -3269,6 +3269,4 @@ _eglInitDriver(_EGLDriver *dri2_drv)
> dri2_drv->API.GLInteropQueryDeviceInfo = dri2_interop_query_device_info;
> dri2_drv->API.GLInteropExportObject = dri2_interop_export_object;
> dri2_drv->API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
> -
> -   dri2_drv->Name = "DRI2";
>  }
> diff --git a/src/egl/drivers/haiku/egl_haiku.cpp 
> b/src/egl/drivers/haiku/egl_haiku.cpp
> index 590e43f00fb96b051fb4..0b56653395a94ac1f303 100644
> --- a/src/egl/drivers/haiku/egl_haiku.cpp
> +++ b/src/egl/drivers/haiku/egl_haiku.cpp
> @@ -325,7 +325,5 @@ _eglInitDriver(_EGLDriver *driver)
>  
>   driver->API.SwapBuffers = haiku_swap_buffers;
>  
> - driver->Name = "Haiku";
> -
>   TRACE("API Calls defined\n");
>  }
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index c1bf5bbfe19b3172429e..306db209cd94748f048f 100644
> --- a/src/egl/main/eglapi.c
> +++ b/src/egl/main/eglapi.c
> @@ -619,8 +619,7 @@ eglInitialize(EGLDisplay dpy, EGLint *major, EGLint 
> *minor)
>_eglCreateExtensionsString(disp);
>_eglCreateAPIsString(disp);
>snprintf(disp->VersionString, sizeof(disp->VersionString),
> -   "%d.%d (%s)", disp->Version / 10, disp->Version % 10,
> -   disp->Driver->Name);
> +   "%d.%d", disp->Version / 10, disp->Version % 10);
> }
>  
> /* Update applications version of major and minor if not NULL */
> diff --git a/src/egl/main/egldriver.c b/src/egl/main/egldriver.c
> index 71bfca21ed8c6a666c14..f1973bde274ec768c4cf 100644
> --- a/src/egl/main/egldriver.c
> +++ b/src/egl/main/egldriver.c
> @@ -99,8 +99,6 @@ _eglMatchDriver(_EGLDisplay *dpy)
> }
>  
> if (best_drv) {
> -  _eglLog(_EGL_DEBUG, "the best driver is %s",
> -best_drv->Name);
>dpy->Driver = best_drv;
>dpy->Initialized = EGL_TRUE;
> }
> diff --git a/src/egl/main/egldriver.h b/src/egl/main/egldriver.h
> index ba12a060cab7f7c6c223..5695fc06ffb03102cc64 100644
> --- a/src/egl/main/egldriver.h
> +++ b/src/egl/main/egldriver.h
> @@ -75,8 +75,6 @@ extern "C" {
>   */
>  struct _egl_driver
>  {
> -   const char *Name;  /**< name of this driver */
> -
> _EGLAPI API;  /**< EGL API dispatch table */
>  };
>  
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Has anyone stressed radeonsi memory?

[Kai Wasserbäch]

Hey Matias,
Matias N. Goldberg wrote on 15.11.2017 16:51:
>> Why, doesn't your distro have LLVM development packages?
> They aren't as up to date. Keeping up-to-date with everything mesa needs is 
> exhausting.
> I started compiling LLVM from source when I needed to test an LLVM patch to 
> fix a GLSL shader compiler bug.
> 
> I also compile mesa from source (rather thank using Oibaf or Padoka's PPA for 
> Ubuntu) because as a graphics dev, being able to debug inside Mesa has proven 
> to be an invaluable tool.

you seem to be using Ubuntu or another Debian derivate. In that case you can get
development snapshot packages from Debian's LLVM maintainer at
.

Cheers,
Kai

P.S.@Michel: Maybe it would be helpful to add that URL to the Mesa documentation
somewhere?



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: disambiguate driver name

[Kai Wasserbäch]

Hey Eric,
Eric Engestrom wrote on 17.10.2017 19:48:
> On Tuesday, 2017-10-17 17:20:13 +, Emil Velikov wrote:
>> [...]
>> Yes name is a bit misleading, so I'm wondering if any of the following
>> won't be better
>>  - s/DRI2/DRI/ - might be tad confusing
>>  - emit the corresponding DRI2 vs DRI3 - ideally, but might be fiddly
>> to get sorted
>>  - drop DRI2 all together - the other backends (glx yes glx and
>> gallium) are long gone
>>
>> What do you guys think?
>> Emil
> 
> I vote remove. The only alternative is Haiku, and one would know if
> that's what they were running.
> I feel like this is part of the whole driver refactor ajax did in
> b174a1ae720cb404738c "egl: Simplify the "driver" interface"
> 
> I'll send a patch removing the whole `name` thing tomorrow, if Kai
> doesn't beat me to it :P

I doubt that, since removing the Name field from _egl_driver would leave just
the _EGLAPI in it, which should mean, one could remove _egl_driver entirely.
Which is a bit more work than I have time for in the evenings at the moment. I
could maybe look at it on Sunday. But I'd hazard a guess, that you'd be way
faster than that. So feel free to send that patch.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl/dri2: disambiguate driver name (v2)

[Kai Wasserbäch]

So far the Mesa-internal EGL driver "dri2" returned "DRI2" as its driver
name. This causes confusion, because there is an X11 protocol extension
by the same name. To make matters worse, the protocol extension also has
a newer version called "DRI3", which then can lead a user to the
assumption that DRI3 is not used on the current system, even when it
should. While in truth the "DRI2" shown in the EGL version string refers
to an internal interface in Mesa, that has nothing to do with the X11
protocol extension at all.

This change attempts to make it clearer that the "dri2" name of the Mesa
EGL driver has nothing to do with the X11 protocol extension by
prepending "Mesa-" to the driver name shown in the brackets of the EGL
version string.

See the thread beginning at
<https://lists.freedesktop.org/archives/amd-gfx/2017-October/014544.html>
for the exchange that sparked this patch.

v2:
 - Fix commit message. (Michel Dänzer)
 - Don't capitalise "Mesa" in the driver name. (Eric Engestrom)
Signed-off-by: Kai Wasserbäch 
---
 src/egl/drivers/dri2/egl_dri2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 77f09271f0..8a1f5d2503 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -3260,7 +3260,7 @@ _eglBuiltInDriver(void)
dri2_drv->base.API.GLInteropExportObject = dri2_interop_export_object;
dri2_drv->base.API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
 
-   dri2_drv->base.Name = "DRI2";
+   dri2_drv->base.Name = "Mesa-DRI2";
 
return &dri2_drv->base;
 }
-- 
2.14.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: disambiguate driver name

[Kai Wasserbäch]

Hey Eric,
Eric Engestrom wrote on 17.10.2017 18:31:
> On Tuesday, 2017-10-17 15:26:00 +0000, Kai Wasserbäch wrote:
>> So far the Mesa-internal EGL driver "dri2" returned "DRI2" as its driver
>> name. This causes confusion, because there is a kernel interface by the
>> same name where a version 3 is available.
> 
> What confusion? Do you have an example?
> 
> I'm not really opposed to a change, but I don't see the benefit,
> especially of just adding this "MESA-" prefix...

well, reading „EGL version string: 1.5 (DRI2)“ when calling eglinfo I assumed
that DRI3 was somehow not working on my setup (see
<https://lists.freedesktop.org/archives/amd-gfx/2017-October/014544.html>, which
I've included in the commit message). Michel then cleared up, that the interface
meant by the EGL version string is an internal Mesa interface which has nothing
to do with the more widely known X11 protocol extension.

So I thought it best to clearly separate them. Ideally this internal interface
wouldn't be called "dri" at all, but I that's probably going a bit too far.

> (Nit: please spell it "Mesa", it's a name, not an acronym :)

Ok, I'll resend in a minute with the correction to the commit message Michel
pointed out.

Cheers,
Kai


>> This change attempts to make it clearer that the "dri2" name of the Mesa
>> EGL driver has nothing to do with that kernel interface and is rather a
>> Mesa internal versioning of an interface.
>>
>> See eg. the thread beginning at
>> <https://lists.freedesktop.org/archives/amd-gfx/2017-October/014544.html>
>> for an example.
>>
>> Signed-off-by: Kai Wasserbäch 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/dri2: disambiguate driver name

[Kai Wasserbäch]

Michel Dänzer wrote on 17.10.2017 17:42:
> On 17/10/17 05:26 PM, Kai Wasserbäch wrote:
>> So far the Mesa-internal EGL driver "dri2" returned "DRI2" as its driver
>> name. This causes confusion, because there is a kernel interface by the
>> same name where a version 3 is available.
>>
>> This change attempts to make it clearer that the "dri2" name of the Mesa
>> EGL driver has nothing to do with that kernel interface and is rather a
>> Mesa internal versioning of an interface.
> 
> DRI3 is an X11 protocol extension, not a kernel interface.

Ihrg, yes. Total brainfart there. Should I resend or can this be fixed when this
patch might be commited? As I do not have commit access somebody else would need
to do it then.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl/dri2: disambiguate driver name

[Kai Wasserbäch]

So far the Mesa-internal EGL driver "dri2" returned "DRI2" as its driver
name. This causes confusion, because there is a kernel interface by the
same name where a version 3 is available.

This change attempts to make it clearer that the "dri2" name of the Mesa
EGL driver has nothing to do with that kernel interface and is rather a
Mesa internal versioning of an interface.

See eg. the thread beginning at
<https://lists.freedesktop.org/archives/amd-gfx/2017-October/014544.html>
for an example.

Signed-off-by: Kai Wasserbäch 
---
 src/egl/drivers/dri2/egl_dri2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 77f09271f0..3991dfc84d 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -3260,7 +3260,7 @@ _eglBuiltInDriver(void)
dri2_drv->base.API.GLInteropExportObject = dri2_interop_export_object;
dri2_drv->base.API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
 
-   dri2_drv->base.Name = "DRI2";
+   dri2_drv->base.Name = "MESA-DRI2";
 
return &dri2_drv->base;
 }
-- 
2.14.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/st: Fix frontbuffer rendering regression

[Kai Wasserbäch]

Hey Thomas,
Thomas Hellstrom wrote on 07.09.2017 10:53:
> This fixes a regression introduced with commit
> eceb6710024716433069d705fbd873d6d136c2cc:
> "mesa/st: Reduce the number of frontbuffer flush calls"
> where we, after flushing the front buffer marked it as not-rendered-to,
> the idea being that it should be marked as "rendered-to" again as soon as
> any rendering was touching the front.
>
> Now the latter part never happened, because it was part of a state
> validation and we never marked that part of the state as dirty.
>
> So mark the framebuffer state dirty after a frontbuffer flush.
> (fdo bugzilla 102496)
>
> Signed-off-by: Thomas Hellstrom 
> Tested-by: Dieter Nützel 
> Tested-by: Bruce Cherniak 
> Tested-By: Gert Wollny 

I think the customary lines for bug references and fixed commits are:

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102496
 Fixes: eceb671002 (mesa/st: Reduce the number of frontbuffer flush calls)

As those get picked up by the scripts for eg. stable management. You might want
to use those tags.

Cheers,
Kai




signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: build ddebug, noop, rbug, trace as part of auxiliary

[Kai Wasserbäch]

On 06/09/17 13:11, Marek Olšák wrote:
> On Wed, Sep 6, 2017 at 1:02 PM, Marek Olšák  wrote:
>> On Wed, Sep 6, 2017 at 12:38 PM, Emil Velikov  
>> wrote:
>>> On 4 September 2017 at 21:36, Marek Olšák  wrote:
 From: Marek Olšák 

 Building gallium is faster by 7.5 seconds on a 4core/8thread 3GHz CPU.
 (gallium build time is reduced by 15% when building only radeonsi)

>>> Some of this can be attributed to a couple libraries less to link.
>>> Speaking of which, did you switch to the gold linker, it should
>>> utilise the multiple cores/threads nicely.
>>
>> Sadly no.
> 
> How do I switch to the gold linker?

Usually by appending -fuse-ld=gold to LDFLAGS (or by appending
-Wl,-fuse-ld=gold to CXXFLAGS/CFLAGS if the linker is invoked through
gcc/g++).

Cheers,
Kai
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 3/3] drirc: Add allow_glsl_builtin_variable_redeclaration for Dying Light and Dead Island Definitive Edition

[Kai Wasserbäch]

Hey,
John Brooks wrote on 15.05.2017 07:47:
> This fixes the long-standing problem with Dying Light where the game would
> produce a black screen when running under Mesa. This happened because the
> game's vertex shaders redeclare gl_VertexID, which is a GLSL builtin.
> Mesa's GLSL compiler is a little more strict than others, and would not
> compile them:
> 
> error: `gl_VertexID' redeclared
> 
> The allow_glsl_builtin_variable_redeclaration directive allows the shaders
> to compile and the game to render. The game also requires OpenGL 4.4+ (GLSL
> 440), but does not request it explicitly. It must be forced with an
> override, such as MESA_GL_VERSION_OVERRIDE=4.5 and
> MESA_GLSL_VERSION_OVERRIDE=450. A compatibility context is *not* required
> and forcing one with 4.5COMPAT or allow_higher_compat_version results in
> graphical artifacts.
> 
> [...]
> +
> +
> + value="true" />


I know this has already landed and maybe I'm missing something, but why didn't
you at least put the GLSL version requirements in the drirc as well? It should 
be
  

AFAIK there's no drirc option for the OpenGL level itself, though maybe that
should just be added as well.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Bug in 17.1.0-rc4 source packaging for swr?

[Kai Wasserbäch]

Hey,
Emil Velikov wrote on 18.05.2017 18:17:
> On 18 May 2017 at 16:34, Rowley, Timothy O  wrote:
>> We could use a gen_builder.h generated from llvm-3.9 for all current
>> versions of llvm at this time (as the changes are now just llvm IR
>> additions), but I’m not sure how to enforce that the person creating the
>> tarball has a particular version of llvm installed.
>>
> Must admit that I don't know much about LLVM or SWR, so I hope you've
> thoroughly tested LLVM 3.9 generated files built with LLVM 4.0 or
> later.
> Using LLVM 3.9 should be doable, but I'm curious if we can avoid such
> 'acrobatics' in the long run.
> 
> Any ideas, if that's at all possible?

how about the SWR maintainers provide a "golden" fallback file, that is
pre-generated and known good for all supported LLVM (right now I would guess
that to be 3.9 and 4.0) versions? That file is always shipped in the tarball.

During build there's a rule, that checks if $generator is there. If not, the
fallback file is copied to the correct name, otherwise the regular generation
takes place.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallivm: Fix build against LLVM SVN >= r302589

[Kai Wasserbäch]

Michel Dänzer wrote on 10.05.2017 10:27:
> From: Michel Dänzer 
> 
> deregisterEHFrames doesn't take any parameters anymore.
> 
> Signed-off-by: Michel Dänzer 

LGTM, CC stable?

> ---
>  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp 
> b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> index 2a388cbfaf..0e4a531089 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> @@ -342,14 +342,20 @@ class DelegatingJITMemoryManager : public 
> BaseMemoryManager {
>virtual void registerEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t 
> Size) {
>   mgr()->registerEHFrames(Addr, LoadAddr, Size);
>}
> -  virtual void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, 
> size_t Size) {
> - mgr()->deregisterEHFrames(Addr, LoadAddr, Size);
> -  }
>  #else
>virtual void registerEHFrames(llvm::StringRef SectionData) {
>   mgr()->registerEHFrames(SectionData);
>}
>  #endif
> +#if HAVE_LLVM >= 0x0500
> +  virtual void deregisterEHFrames() {
> + mgr()->deregisterEHFrames();
> +  }
> +#elif HAVE_LLVM >= 0x0304
> +  virtual void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, 
> size_t Size) {
> + mgr()->deregisterEHFrames(Addr, LoadAddr, Size);
> +  }
> +#endif
>virtual void *getPointerToNamedFunction(const std::string &Name,
>bool AbortOnFailure=true) {
>   return mgr()->getPointerToNamedFunction(Name, AbortOnFailure);
> 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] disk_cache: reduce default cache size to 5% of filesystem

[Kai Wasserbäch]

Hey,
Marek Olšák wrote on 29.04.2017 12:49:
> On Apr 29, 2017 11:27 AM, "Timothy Arceri"  wrote:
> On 29/04/17 18:44, Marek Olšák wrote:
>> [...]
>>
>> That's a good point. I didn't think of that. Still, if one game evicts all
>> entries, the cache may be almost as good as disabled.
>>
> 
> I'm happy for the default limit to be raised from 1GB. However as I replied
> in the other thread using a percentage is not a good idea at this stage IMO.
> 
> For the majority of use cases 1GB should be more than enough. Deus Ex is
> very shader heavy and when compressed it was only taking up ~30MB, so I
> wouldn't be to worried about entries getting evicted unless there is
> something on the system generating a boat load of unique shaders.
> 
> 
> 30MB is actually useful information that puts everything into perspective.
> Thanks.

just to give a bit more input here: I've been using the cache for a while now
and never cleared it manually after the unified directory structure came to be.
With several games, Wine (without nine) and various Superpositions runs
(different quality settings) – btw big thanks to the whole AMD team: I'm seeing
4043 points at 2560×1440 with medium quality settings and 2805 points with high
settings in that benchmark! – I just hit 133 MB as displayed by "du -hs" as of
today. Granted, there are a couple more MB for the user running the desktop
environment and the display manager, but last time I checked that was about 12 
MB.
And I should probably add that there are certainly stale cache files in there,
since I've rebuilt Mesa and LLVM several times.

Anyway a limit of 1 GB sounds fine by me.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] docs/features: mark KHR_no_error as started

[Kai Wasserbäch]

The OpenGL extension KHR_no_error is exposed since commit
d42d150ad26e29d9e894ba9f9e28f8134e2e5393 by Timothy Arceri. Therefore it
should be marked as "started" in the features.txt

Signed-off-by: Kai Wasserbäch 
---

Hey,
this is a rather trivial "patch" (doesn't really deserve that designation), but
I like the documentation to be in line with reality. AFAICT "started" is the
correct state for now. If it is considered "DONE" already, let me know and I
send a v2.

Cheers,
Kai

P.S.: Please push this for me, if you accept it, since I do not have commit 
access.


 docs/features.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/features.txt b/docs/features.txt
index 5f63632e82..a0d7c1be48 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -305,7 +305,7 @@ Khronos, ARB, and OES extensions that are not part of any 
OpenGL or OpenGL ES ve
   GL_ARB_texture_filter_minmax  not started
   GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+)
   GL_KHR_blend_equation_advanced_coherent   DONE (i965/gen9+)
-  GL_KHR_no_error   not started
+  GL_KHR_no_error   started (Timothy 
Arceri)
   GL_KHR_texture_compression_astc_hdr   DONE (core only)
   GL_KHR_texture_compression_astc_sliced_3d not started
   GL_OES_depth_texture_cube_map DONE (all drivers that 
support GLSL 1.30+)
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] ac, gallium: fix building with LLVM >= r298393

[Kai Wasserbäch]

Already on list by Marek <https://patchwork.freedesktop.org/patch/145440/>

Vedran Miletić wrote on 22.03.2017 16:01:
> AttributeSet got renamed to AttributeList.
> 
> Signed-off-by: Vedran Miletić 
> ---
>  src/amd/common/ac_llvm_helper.cpp | 10 --
>  src/gallium/auxiliary/gallivm/lp_bld_misc.cpp |  8 +++-
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/src/amd/common/ac_llvm_helper.cpp 
> b/src/amd/common/ac_llvm_helper.cpp
> index 4f03103..01a981b 100644
> --- a/src/amd/common/ac_llvm_helper.cpp
> +++ b/src/amd/common/ac_llvm_helper.cpp
> @@ -35,18 +35,24 @@
>  #include 
>  #include 
>  
> +#if HAVE_LLVM >= 0x0500
> +   typedef llvm::AttributeList llvm_attribute_list;
> +#else
> +   typedef llvm::AttributeSet llvm_attribute_list;
> +#endif
> +
>  void ac_add_attr_dereferenceable(LLVMValueRef val, uint64_t bytes)
>  {
> llvm::Argument *A = llvm::unwrap(val);
> llvm::AttrBuilder B;
> B.addDereferenceableAttr(bytes);
> -   A->addAttr(llvm::AttributeSet::get(A->getContext(), A->getArgNo() + 1,  
> B));
> +   A->addAttr(llvm_attribute_list::get(A->getContext(), A->getArgNo() + 1,  
> B));
>  }
>  
>  bool ac_is_sgpr_param(LLVMValueRef arg)
>  {
>   llvm::Argument *A = llvm::unwrap(arg);
> - llvm::AttributeSet AS = A->getParent()->getAttributes();
> + llvm_attribute_list AS = A->getParent()->getAttributes();
>   unsigned ArgNo = A->getArgNo();
>   return AS.hasAttribute(ArgNo + 1, llvm::Attribute::ByVal) ||
>  AS.hasAttribute(ArgNo + 1, llvm::Attribute::InReg);
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp 
> b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> index 444686f..e2ea6e8 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
> @@ -86,6 +86,12 @@
>  #  pragma pop_macro("DEBUG")
>  #endif
>  
> +#if HAVE_LLVM >= 0x0500
> +   typedef llvm::AttributeList llvm_attribute_list;
> +#else
> +   typedef llvm::AttributeSet llvm_attribute_list;
> +#endif
> +
>  #include "c11/threads.h"
>  #include "os/os_thread.h"
>  #include "pipe/p_config.h"
> @@ -754,7 +760,7 @@ lp_add_attr_dereferenceable(LLVMValueRef val, uint64_t 
> bytes)
> llvm::Argument *A = llvm::unwrap(val);
>     llvm::AttrBuilder B;
> B.addDereferenceableAttr(bytes);
> -   A->addAttr(llvm::AttributeSet::get(A->getContext(), A->getArgNo() + 1,  
> B));
> +   A->addAttr(llvm_attribute_list::get(A->getContext(), A->getArgNo() + 1,  
> B));
>  #endif
>  }
>  
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 21.03.2017 18:34:
> Quoting Kai Wasserbäch (2017-03-21 09:50:52)
>> I've just a few points, since I'm not too enthused by the prospect of having 
>> to
>> deal with yet another build system with yet another slightly different 
>> syntax.
>> But ultimately this is only a "my 2 cents" e-mail, since others are way 
>> deeper
>> involved with Mesa and their opinion is what matters in the end. Anyway, here
>> goes nothing.
>>
>> This might be a dumb question but isn't Meson (through wrap files) one of the
>> build systems that download crap from all over the internet silently? Ie. 
>> making
>> a packager's/distribution's life hell? There is
>> <https://github.com/mesonbuild/meson/wiki/Wrap-dependency-system-manual#toggling-between-distro-packages-and-embedded-source>
>> but that seems to imply a silent fallback to downloading stuff. I would 
>> rather
>> have a configure step that fails if a dependency is not met instead of 
>> building
>> something that can't be distributed. Or is there a magic 
>> "--distribution-build"
>> flag? If there isn't I would rather see a switch to CMake (as others have
>> pointed out in this thread: many projects in the vicinity of Mesa already use
>> CMake), but I get that there's a lot of hate for CMake (even though the Meson
>> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
>> would be unlikely.
> 
> I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
> aimed at windows and osx, where bundling is the norm, and not Linux and the 
> BSDs
> where it's not. What I would expect if the windows guys wanted to use wrap is
> that we would have something like this:
> 
> if host_machine.system() != 'windows'
> dep_zlib = dependency('zlib', version : '>1.0.0')
> else
> subproj_zlib = subproject('zlib')
> dep_zlib = subproj_zlib.get_variable('zlib_dep')
> endif
> 
> Which would make the dependency a hard requirement for non-windows system 
> (i.e.
> the configure fails if zlib isn't found *except* on windows), and windows 
> could
> fall back to wraps.
> 
> I have no plans to implement wrap for mesa in the port I would do, and would 
> NAK
> any patches that used wrap on Linux or BSD. The windows devs can make their 
> own
> choice on how to handle dependencies (I have no idea what their development
> environment looks like and don't want to make that choice for them). I agree
> with you it's not the way that Linux or BSD works, we have competent package
> management solutions without the need to automatically download sources.

I hope the rest of the Mesa project would follow such a rule. Because if there's
something I absolutely hate about all those "new" build systems, then it's their
tendency to just download stuff and build/include that. This seems to have risen
with Node and now spread into Rust and other parts of the FLOSS eco-system.

> As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
> and cmake are the difference between python and perl, there may be some
> superficial similarities, but they are *not* the same. One of the things I'll
> reiterate that impressed me the most about meson is that it's syntax is 
> simple,
> not Turring-complete, and opinionated.
> 
> In fact, piglit is the best reason not not use cmake I can come up with. There
> is an (admittedly clever) hack to allow building tests for each of the API's
> supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
> each API, which means you can't put things in the tests directory that can 
> only
> be run once. Every time I try to make changes to the Cmake I spend about an 
> hour
> trying to figure out why some code I've implemented doesn't work, only to
> remember that. Build systems aren't programming languages, they shouldn't be
> interesting, they should be declarative; cmake is a full scripting language 
> with
> enough warts to make bash look cuddly.

Hm, I have written a lot of CMakeFiles.txt and so far I've always been rather
happy with them. Not sure what Piglit is doing though.

>> Dylan Baker wrote on 16.03.2017 22:25:
>>> Why bother, and why would we want this?
>>>
>>> First it's written in python, which means the potential developer base
>>> is massive. And it provides a recursive view for humans, but a
>>> non-recursive view for the system. This is the best of both worlds,
>>> humans can 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kai Wasserbäch]

Hey Dylan,
I've just a few points, since I'm not too enthused by the prospect of having to
deal with yet another build system with yet another slightly different syntax.
But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
involved with Mesa and their opinion is what matters in the end. Anyway, here
goes nothing.

This might be a dumb question but isn't Meson (through wrap files) one of the
build systems that download crap from all over the internet silently? Ie. making
a packager's/distribution's life hell? There is

but that seems to imply a silent fallback to downloading stuff. I would rather
have a configure step that fails if a dependency is not met instead of building
something that can't be distributed. Or is there a magic "--distribution-build"
flag? If there isn't I would rather see a switch to CMake (as others have
pointed out in this thread: many projects in the vicinity of Mesa already use
CMake), but I get that there's a lot of hate for CMake (even though the Meson
syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
would be unlikely.

Dylan Baker wrote on 16.03.2017 22:25:
> Why bother, and why would we want this?
> 
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently.

Well, CMake (and probably others), see
, can use/generate for
ninja too.

> Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
> 
> What's different about using meson?
> 
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?

Nothing against git archive, but you then would need to maintain .gitattributes
in addition to the build system input files, correct? Right now the distribution
rules are just in the Makefile.in files, making them more visible and less
easily forgotten.

> [...]

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vulkan/wsi: Improve the DRI3 error message

[Kai Wasserbäch]

Not from my side. But I can't commit the patch for you. Jason?

Jacob Lifshay wrote on 26.02.2017 03:17:
> Just to double check, is there anything else I need to do to have this
> patch committed?
> Jacob Lifshay
> 
> On Feb 19, 2017 02:08, "Kai Wasserbäch"  wrote:
> 
>> Jason Ekstrand wrote on 19.02.2017 06:01:
>>> On Feb 18, 2017 12:37 PM, "Kai Wasserbäch" 
>>> wrote:
>>>
>>> Hey Jacob,
>>> sorry for not spotting this the first time, but I have an additional
>>> comment.
>>> Please see below.
>>>
>>> Jacob Lifshay wrote on 18.02.2017 18:48:> This commit improves the
>> message
>>> by
>>> telling them that they could probably
>>>> enable DRI3.  More importantly, it includes a little heuristic to check
>>>> to see if we're running on AMD or NVIDIA's proprietary X11 drivers and,
>>>> if we are, doesn't emit the warning.  This way, users with both a
>> discrete
>>>> card and Intel graphics don't get the warning when they're just running
>>>> on the discrete card.
>>>>
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99715
>>>> Co-authored-by: Jason Ekstrand 
>>>> ---
>>>>  src/vulkan/wsi/wsi_common_x11.c | 47 ++
>>> ++-
>>>>  1 file changed, 37 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/src/vulkan/wsi/wsi_common_x11.c
>> b/src/vulkan/wsi/wsi_common_
>>> x11.c
>>>> index 64ba921..b3a017a 100644
>>>> --- a/src/vulkan/wsi/wsi_common_x11.c
>>>> +++ b/src/vulkan/wsi/wsi_common_x11.c
>>>> @@ -49,6 +49,7 @@
>>>>  struct wsi_x11_connection {
>>>> bool has_dri3;
>>>> bool has_present;
>>>> +   bool is_proprietary_x11;
>>>>  };
>>>>
>>>>  struct wsi_x11 {
>>>> @@ -63,8 +64,8 @@ static struct wsi_x11_connection *
>>>>  wsi_x11_connection_create(const VkAllocationCallbacks *alloc,
>>>>xcb_connection_t *conn)
>>>>  {
>>>> -   xcb_query_extension_cookie_t dri3_cookie, pres_cookie;
>>>> -   xcb_query_extension_reply_t *dri3_reply, *pres_reply;
>>>> +   xcb_query_extension_cookie_t dri3_cookie, pres_cookie, amd_cookie,
>>> nv_cookie;
>>>> +   xcb_query_extension_reply_t *dri3_reply, *pres_reply, *amd_reply,
>>> *nv_reply;
>>>>
>>>> struct wsi_x11_connection *wsi_conn =
>>>>vk_alloc(alloc, sizeof(*wsi_conn), 8,
>>>> @@ -75,20 +76,39 @@ wsi_x11_connection_create(const
>> VkAllocationCallbacks
>>> *alloc,
>>>> dri3_cookie = xcb_query_extension(conn, 4, "DRI3");
>>>> pres_cookie = xcb_query_extension(conn, 7, "PRESENT");
>>>>
>>>> +   /* We try to be nice to users and emit a warning if they try to use
>> a
>>>> +* Vulkan application on a system without DRI3 enabled.  However,
>>> this ends
>>>> +* up spewing the warning when a user has, for example, both Intel
>>>> +* integrated graphics and a discrete card with proprietary driers
>>> and are
>>>> +* running on the discrete card with the proprietary DDX.  In this
>>> case, we
>>>> +* really don't want to print the warning because it just confuses
>>> users.
>>>> +* As a heuristic to detect this case, we check for a couple of
>>> proprietary
>>>> +* X11 extensions.
>>>> +*/
>>>> +   amd_cookie = xcb_query_extension(conn, 11, "ATIFGLRXDRI");
>>>> +   nv_cookie = xcb_query_extension(conn, 10, "NV-CONTROL");
>>>> +
>>>> dri3_reply = xcb_query_extension_reply(conn, dri3_cookie, NULL);
>>>> pres_reply = xcb_query_extension_reply(conn, pres_cookie, NULL);
>>>> -   if (dri3_reply == NULL || pres_reply == NULL) {
>>>> +   amd_reply = xcb_query_extension_reply(conn, amd_cookie, NULL);
>>>> +   nv_reply = xcb_query_extension_reply(conn, nv_cookie, NULL);
>>>> +   if (!dri3_reply || !pres_reply || !amd_reply || !nv_reply) {
>>>
>>> I don't feel wsi_x11_connection_create should fail if there's no
>> amd_reply
>>> or
>>> nv_reply. That should just lead to unconditionally warning, in case
>> there's
>>> no
>>> DRI3 support.
>>>
>>>
>&g

Re: [Mesa-dev] [PATCH] vulkan/wsi: Improve the DRI3 error message

[Kai Wasserbäch]

Jason Ekstrand wrote on 19.02.2017 06:01:
> On Feb 18, 2017 12:37 PM, "Kai Wasserbäch" 
> wrote:
> 
> Hey Jacob,
> sorry for not spotting this the first time, but I have an additional
> comment.
> Please see below.
> 
> Jacob Lifshay wrote on 18.02.2017 18:48:> This commit improves the message
> by
> telling them that they could probably
>> enable DRI3.  More importantly, it includes a little heuristic to check
>> to see if we're running on AMD or NVIDIA's proprietary X11 drivers and,
>> if we are, doesn't emit the warning.  This way, users with both a discrete
>> card and Intel graphics don't get the warning when they're just running
>> on the discrete card.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99715
>> Co-authored-by: Jason Ekstrand 
>> ---
>>  src/vulkan/wsi/wsi_common_x11.c | 47 ++
> ++-
>>  1 file changed, 37 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_
> x11.c
>> index 64ba921..b3a017a 100644
>> --- a/src/vulkan/wsi/wsi_common_x11.c
>> +++ b/src/vulkan/wsi/wsi_common_x11.c
>> @@ -49,6 +49,7 @@
>>  struct wsi_x11_connection {
>> bool has_dri3;
>> bool has_present;
>> +   bool is_proprietary_x11;
>>  };
>>
>>  struct wsi_x11 {
>> @@ -63,8 +64,8 @@ static struct wsi_x11_connection *
>>  wsi_x11_connection_create(const VkAllocationCallbacks *alloc,
>>xcb_connection_t *conn)
>>  {
>> -   xcb_query_extension_cookie_t dri3_cookie, pres_cookie;
>> -   xcb_query_extension_reply_t *dri3_reply, *pres_reply;
>> +   xcb_query_extension_cookie_t dri3_cookie, pres_cookie, amd_cookie,
> nv_cookie;
>> +   xcb_query_extension_reply_t *dri3_reply, *pres_reply, *amd_reply,
> *nv_reply;
>>
>> struct wsi_x11_connection *wsi_conn =
>>vk_alloc(alloc, sizeof(*wsi_conn), 8,
>> @@ -75,20 +76,39 @@ wsi_x11_connection_create(const VkAllocationCallbacks
> *alloc,
>> dri3_cookie = xcb_query_extension(conn, 4, "DRI3");
>> pres_cookie = xcb_query_extension(conn, 7, "PRESENT");
>>
>> +   /* We try to be nice to users and emit a warning if they try to use a
>> +* Vulkan application on a system without DRI3 enabled.  However,
> this ends
>> +* up spewing the warning when a user has, for example, both Intel
>> +* integrated graphics and a discrete card with proprietary driers
> and are
>> +* running on the discrete card with the proprietary DDX.  In this
> case, we
>> +* really don't want to print the warning because it just confuses
> users.
>> +* As a heuristic to detect this case, we check for a couple of
> proprietary
>> +* X11 extensions.
>> +*/
>> +   amd_cookie = xcb_query_extension(conn, 11, "ATIFGLRXDRI");
>> +   nv_cookie = xcb_query_extension(conn, 10, "NV-CONTROL");
>> +
>> dri3_reply = xcb_query_extension_reply(conn, dri3_cookie, NULL);
>> pres_reply = xcb_query_extension_reply(conn, pres_cookie, NULL);
>> -   if (dri3_reply == NULL || pres_reply == NULL) {
>> +   amd_reply = xcb_query_extension_reply(conn, amd_cookie, NULL);
>> +   nv_reply = xcb_query_extension_reply(conn, nv_cookie, NULL);
>> +   if (!dri3_reply || !pres_reply || !amd_reply || !nv_reply) {
> 
> I don't feel wsi_x11_connection_create should fail if there's no amd_reply
> or
> nv_reply. That should just lead to unconditionally warning, in case there's
> no
> DRI3 support.
> 
> 
> Of there is no reply then we either lost our connection to the X server or
> ran out of memory.  Either of those seem like a valid excuse to fail.  The
> chances of successfully connecting to X to create a swapchain at that point
> is pretty close to zero.

Fair enough.

> With that fixed, this patch is
>   Reviewed-by: Kai Wasserbäch 
> 
> Cheers,
> Kai
> 
>>free(dri3_reply);
>>free(pres_reply);
>> +  free(amd_reply);
>> +  free(nv_reply);
>>vk_free(alloc, wsi_conn);
>>return NULL;
>> }
>>
>> wsi_conn->has_dri3 = dri3_reply->present != 0;
>> wsi_conn->has_present = pres_reply->present != 0;
>> +   wsi_conn->is_proprietary_x11 = amd_reply->present ||
> nv_reply->present;
>>
>> free(dri3_reply);
>> free(pres_reply);
>> +   free(amd_reply);
>> +   free(nv_reply);
>>
>> return wsi_conn;
>>  }
>> @@ -100,

Re: [Mesa-dev] [PATCH] vulkan/wsi: Improve the DRI3 error message

[Kai Wasserbäch]

Hey Jacob,
sorry for not spotting this the first time, but I have an additional comment.
Please see below.

Jacob Lifshay wrote on 18.02.2017 18:48:> This commit improves the message by
telling them that they could probably
> enable DRI3.  More importantly, it includes a little heuristic to check
> to see if we're running on AMD or NVIDIA's proprietary X11 drivers and,
> if we are, doesn't emit the warning.  This way, users with both a discrete
> card and Intel graphics don't get the warning when they're just running
> on the discrete card.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99715
> Co-authored-by: Jason Ekstrand 
> ---
>  src/vulkan/wsi/wsi_common_x11.c | 47 
> -
>  1 file changed, 37 insertions(+), 10 deletions(-)
> 
> diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
> index 64ba921..b3a017a 100644
> --- a/src/vulkan/wsi/wsi_common_x11.c
> +++ b/src/vulkan/wsi/wsi_common_x11.c
> @@ -49,6 +49,7 @@
>  struct wsi_x11_connection {
> bool has_dri3;
> bool has_present;
> +   bool is_proprietary_x11;
>  };
>  
>  struct wsi_x11 {
> @@ -63,8 +64,8 @@ static struct wsi_x11_connection *
>  wsi_x11_connection_create(const VkAllocationCallbacks *alloc,
>xcb_connection_t *conn)
>  {
> -   xcb_query_extension_cookie_t dri3_cookie, pres_cookie;
> -   xcb_query_extension_reply_t *dri3_reply, *pres_reply;
> +   xcb_query_extension_cookie_t dri3_cookie, pres_cookie, amd_cookie, 
> nv_cookie;
> +   xcb_query_extension_reply_t *dri3_reply, *pres_reply, *amd_reply, 
> *nv_reply;
>  
> struct wsi_x11_connection *wsi_conn =
>vk_alloc(alloc, sizeof(*wsi_conn), 8,
> @@ -75,20 +76,39 @@ wsi_x11_connection_create(const VkAllocationCallbacks 
> *alloc,
> dri3_cookie = xcb_query_extension(conn, 4, "DRI3");
> pres_cookie = xcb_query_extension(conn, 7, "PRESENT");
>  
> +   /* We try to be nice to users and emit a warning if they try to use a
> +* Vulkan application on a system without DRI3 enabled.  However, this 
> ends
> +* up spewing the warning when a user has, for example, both Intel
> +* integrated graphics and a discrete card with proprietary driers and are
> +* running on the discrete card with the proprietary DDX.  In this case, 
> we
> +* really don't want to print the warning because it just confuses users.
> +* As a heuristic to detect this case, we check for a couple of 
> proprietary
> +* X11 extensions.
> +*/
> +   amd_cookie = xcb_query_extension(conn, 11, "ATIFGLRXDRI");
> +   nv_cookie = xcb_query_extension(conn, 10, "NV-CONTROL");
> +
> dri3_reply = xcb_query_extension_reply(conn, dri3_cookie, NULL);
> pres_reply = xcb_query_extension_reply(conn, pres_cookie, NULL);
> -   if (dri3_reply == NULL || pres_reply == NULL) {
> +   amd_reply = xcb_query_extension_reply(conn, amd_cookie, NULL);
> +   nv_reply = xcb_query_extension_reply(conn, nv_cookie, NULL);
> +   if (!dri3_reply || !pres_reply || !amd_reply || !nv_reply) {

I don't feel wsi_x11_connection_create should fail if there's no amd_reply or
nv_reply. That should just lead to unconditionally warning, in case there's no
DRI3 support.

With that fixed, this patch is
  Reviewed-by: Kai Wasserbäch 

Cheers,
Kai

>free(dri3_reply);
>free(pres_reply);
> +  free(amd_reply);
> +  free(nv_reply);
>vk_free(alloc, wsi_conn);
>return NULL;
> }
>  
> wsi_conn->has_dri3 = dri3_reply->present != 0;
> wsi_conn->has_present = pres_reply->present != 0;
> +   wsi_conn->is_proprietary_x11 = amd_reply->present || nv_reply->present;
>  
> free(dri3_reply);
> free(pres_reply);
> +   free(amd_reply);
> +   free(nv_reply);
>  
> return wsi_conn;
>  }
> @@ -100,6 +120,18 @@ wsi_x11_connection_destroy(const VkAllocationCallbacks 
> *alloc,
> vk_free(alloc, conn);
>  }
>  
> +static bool
> +wsi_x11_check_for_dri3(struct wsi_x11_connection *wsi_conn)
> +{
> +  if (wsi_conn->has_dri3)
> +return true;
> +  if (!wsi_conn->is_proprietary_x11) {
> +fprintf(stderr, "vulkan: No DRI3 support detected - required for 
> presentation\n");
> +"Note: you can probably enable DRI3 in your Xorg 
> config\n");
> +  }
> +  return false;
> +}
> +
>  static struct wsi_x11_connection *
>  wsi_x11_get_connection(struct wsi_device *wsi_dev,
>  const VkAllocationCallbacks *alloc,
> @@ -264,11 +296,8 @@ VkBool32 
> wsi_get_physical_device_xcb_presentation_s

Re: [Mesa-dev] [PATCH] vulkan/wsi: Improve the DRI3 error message

[Kai Wasserbäch]

ee(pres_reply);
> +   free(amd_reply);
> +   free(nv_reply);
>  
> return wsi_conn;
>  }
> @@ -100,6 +126,20 @@ wsi_x11_connection_destroy(const VkAllocationCallbacks 
> *alloc,
> vk_free(alloc, conn);
>  }
>  
> +static bool
> +wsi_x11_check_for_dri3(struct wsi_x11_connection *wsi_conn)
> +{
> +  if (wsi_conn->has_dri3)
> +return true;
> +  if (!wsi_conn->is_proprietary_x11) {
> +fprintf(stderr, "vulkan: No DRI3 support detected - required for 
> presentation\n");
> +if (wsi_conn->has_dri2)
> +  fprintf(stderr, "Note: DRI2 support detected, you can probably enable 
> DRI3 in your Xorg config;\n"
> +  "  see 
> http://askubuntu.com/questions/817226/how-to-enable-dri3-on-ubuntu-16-04\n";);
> +  }
> +  return false;
> +}
> +
>  static struct wsi_x11_connection *
>  wsi_x11_get_connection(struct wsi_device *wsi_dev,
>  const VkAllocationCallbacks *alloc,
> @@ -264,11 +304,8 @@ VkBool32 
> wsi_get_physical_device_xcb_presentation_support(
> if (!wsi_conn)
>return false;
>  
> -   if (!wsi_conn->has_dri3) {
> -  fprintf(stderr, "vulkan: No DRI3 support detected - required for 
> presentation\n");
> -  fprintf(stderr, "Note: Buggy applications may crash, if they do please 
> report to vendor\n");
> +   if (!wsi_x11_check_for_dri3(wsi_conn))
>return false;
> -   }
>  
> unsigned visual_depth;
> if (!connection_get_visualtype(connection, visual_id, &visual_depth))
> @@ -313,9 +350,7 @@ x11_surface_get_support(VkIcdSurfaceBase *icd_surface,
> if (!wsi_conn)
>return VK_ERROR_OUT_OF_HOST_MEMORY;
>  
> -   if (!wsi_conn->has_dri3) {
> -  fprintf(stderr, "vulkan: No DRI3 support detected - required for 
> presentation\n");
> -  fprintf(stderr, "Note: Buggy applications may crash, if they do please 
> report to vendor\n");
> +   if (!wsi_x11_check_for_dri3(wsi_conn)) {
>*pSupported = false;
>return VK_SUCCESS;
> }
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] radv cik fixes

[Kai Wasserbäch]

Hey Dave,
Dave Airlie wrote on 14.02.2017 07:10:
> Hey,
> 
> This is a bunch of CIK fixes I found thanks to Lyude for remote
> access to a test machine.
> 
> The main one is 1/4, it changes the memory base alignment
> so that color buffers are aligned properly.

I can confirm, that this series resolves fdo#99692 for me
(<https://bugs.freedesktop.org/show_bug.cgi?id=99692#c9>). The Talos Principle
is finally up and running with radv and no more visual corruption or VM faults
either!

You can have my
  Tested-by: Kai Wasserbäch 

Thank you so much for these patches!

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] vdpau: skip vlVdpOutputSurfacePutBitsNative with a zero-area rectangle

[Kai Wasserbäch]

Hey Marek,
Marek Olšák wrote on 12.02.2017 15:53:
> From: Marek Olšák 
> 
> This prevents errors:
> "EE r600_texture.c:1571 r600_texture_transfer_map - failed to create
>  temporary texture to hold untiled copy"
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99542
> ---
>  src/gallium/state_trackers/vdpau/output.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/gallium/state_trackers/vdpau/output.c 
> b/src/gallium/state_trackers/vdpau/output.c
> index 8b26f7a..6506280 100644
> --- a/src/gallium/state_trackers/vdpau/output.c
> +++ b/src/gallium/state_trackers/vdpau/output.c
> @@ -256,20 +256,27 @@ vlVdpOutputSurfacePutBitsNative(VdpOutputSurface 
> surface,
> pipe = vlsurface->device->context;
> if (!pipe)
>return VDP_STATUS_INVALID_HANDLE;
>  
> if (!source_data || !source_pitches)
> return VDP_STATUS_INVALID_POINTER;
>  
> pipe_mutex_lock(vlsurface->device->mutex);
>  
> dst_box = RectToPipeBox(destination_rect, 
> vlsurface->sampler_view->texture);
> +
> +   /* Check for a no-op. (application bug?) */
> +   if (!dst_box.width || !dst_box.height) {
> +  pipe_mutex_unlock(vlsurface->device->mutex);
> +  return VDP_STATUS_OK;
> +   }
> +

since this is marked as an application bug, should there be a "warn once" along
the lines of "application called vlVdpOutputSurfacePutBitsNative() with a
zero-area rectangle, this is most likely a bug"?

> pipe->texture_subdata(pipe, vlsurface->sampler_view->texture, 0,
>   PIPE_TRANSFER_WRITE, &dst_box, *source_data,
>   *source_pitches, 0);
> pipe_mutex_unlock(vlsurface->device->mutex);
>  
> return VDP_STATUS_OK;
>  }
>  
>  /**
>   * Copy image data from application memory in a specific indexed format to

In any case, this series is:
  Tested-by: Kai Wasserbäch 
  Reviewed-by: Kai Wasserbäch 

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GLSL IR & TGSI on-disk shader cache

[Kai Wasserbäch]

Hey,
Pierre-Loup A. Griffais wrote on 11.02.2017 03:44:
> On 02/10/2017 04:01 AM, Nicolai Hähnle wrote:
>> On 10.02.2017 12:46, Timothy Arceri wrote:
>>> On 10/02/17 21:35, Nicolai Hähnle wrote:
>>> [...]
>>>
 It's not even clear to me how they intend to load those precompiled
 binaries into the system. Is e.g. Steam just going to write into
 Mesa's cache directory? We can't really stop them if they really
 wanted to do that, but that seems like a pain.
>>>
>>> I believe that is the plan yes, same goes for the binary drivers.
>>>

 I agree with Matt that this is precisely what
 GL_ARB_get_program_binary was designed for.

 If people are worried about the download sizes caused by the many
 build combinations, they should look into either

 (a) compression for that purpose, or
>>> I will likely look into this once we land the initial cache. Currently
>>> there is no real information on how large this repository will grow to,
>>> so its more of a thought that a concern at this point.
>>>
>>> I don't know all the details of the planned system but hopefully this
>>> helps give a bit of a picture into how it could work.
>>
>> Cool, thanks.
> 
> ARB_get_program_binary is not useful for collection/redistribution.
> 
> It seems like regardless of any external participant to the system, being 
> robust
> against LLVM differences is something the cache needs to solve.
> 
> Ideally LLVM could expose a version string/number that's granular enough, and
> distros/users could be trusted to properly amend that version string if they
> make functional changes to something that can affect shader compilation, but
> maybe that's wishful thinking.

that version string would need to include the SVN revision, right? Otherwise all
users of LLVM trunk would be screwed*, right? At the moment that kind of
information is most often found in the package version, not what llvm-config
reports (e.g. my llvm-config says 5.0.0-devel, while it would need to say at
least something like 5.0.0-devel~svn294745). As an example, have a look at the
Debian and Ubuntu packages at  (maintained by the Debian
Developer for the in-distribution packages). And what would need to be reported
if I carry a local patch (because I might be testing a solution to a bug)? Right
now I've applied  on top of LLVM
and  (see
) as well as a revert of
7b32ae4df5bc19c378598d6a950a6019fa64ece6 (see
) on top of Mesa. At least
the patches for bug 97988 affect the generated instructions/IR.

* Sort of depends on whether the goal here is to get rid of the GLSL-source
shaders and only ship the pre-compiled ones or if it's more of a "initial speed
bump" thing. Though I honestly can't see the former working unless you redefine
Linux support in Steam as "only with SteamOS".

> I'm not so sure that a build-id is a silver bullet here either, but if you can
> rely on its existence because it's written into the binary by a part of the
> build system that no distro will ever mess with, it seems like it would work. 
> It
> would be more conservative than strictly needed, but that isn't a major issue 
> in
> the short term. It would at least allow us to get compelling data showing
> whether moving to a less granular cache key would allow us to serve
> significantly more users.

BuildIDs could be working (at least on Debian and derived distributions as well
as Fedora/Red Hat, I know the BuildIDs are added). But of course, minor changes
which might not affect the usability of the cache, would still change that ID,
so the miss chance should be pretty high – especially for people following LLVM
trunk and/or Mesa master.
At the end of the day I really don't see how Steam "pre-filling" the cache is a
good idea. At least for me it's just going to be dead data more often than not,
that has to be cleaned out on top of all the ancient libraries in the Steam
runtime, which usually prevent Steam from launching with up-to-date drivers. I'd
rather have Mesa fill it on-demand. (And yes, I know most users would stay with
their distribution's versions, but then you'll have subtle differences in
applied patches to consider and I rather not have the binary versions for all of
those in my cache. Sure BuildID solves the loading/matching, but not that you
might never be able to use the pre-loaded objects.)

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] drirc: Allow extension midshader for Divinity: Original Sin (EE)

[Kai Wasserbäch]

Hey Marek,
Marek Olšák wrote on 07.01.2017 15:48:
> Pushed.

thanks a lot!

> Can you close the bugs if it's fixed?

It is not, as you can read in a more concise form (all the info is also in the
bug report) at
<https://steamcommunity.com/app/373420/discussions/0/353915309344847166/> the
midshader extension is just one part needed to make Divinity run (in the
meantime this affects amdgpu-pro users as well, see the end of the discussion in
the Steam community forums!). On the other hand I do not believe Mesa would want
to work around these issues by implementing (a shim version of)
ARB_shading_language_include and setting „ATI Technologies, Inc.“ as the OpenGL
vendor string. So maybe it would be best to close that bug as WONTFIX, include
the link to the Steam Community forum? But that's better to be decided by a
developer more involved in Mesa, I think.

Cheers,
Kai


> On Sat, Jan 7, 2017 at 2:38 PM, Kai Wasserbäch
>  wrote:
>> See also <https://bugs.freedesktop.org/show_bug.cgi?id=93551#c27> where
>> this was first observed as a requirement.
>>
>> Signed-off-by: Kai Wasserbäch 
>> ---
>>  src/mesa/drivers/dri/common/drirc | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/common/drirc 
>> b/src/mesa/drivers/dri/common/drirc
>> index af84ee82e8..798283fd3e 100644
>> --- a/src/mesa/drivers/dri/common/drirc
>> +++ b/src/mesa/drivers/dri/common/drirc
>> @@ -100,5 +100,9 @@ TODO: document the other workarounds.
>>  
>>  
>>  
>> +
>> +> executable="EoCApp">
>> +> value="true" />
>> +
>>  
>>  
>> --
>> 2.11.0



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri: don't load .drirc from $HOME

[Kai Wasserbäch]

Hey Marek,
thanks for the changes to the documentation!

You can have my
 Reviewed-by: Kai Wasserbäch 

Cheers,
Kai


Marek Olšák wrote on 07.01.2017 15:46:
> From: Marek Olšák 
> 
> ~/.drirc is created by the driconf tool (GPL license) and it overrides
> system drirc settings and can't be changed by Mesa updates.
> This drops support for the tool. It has been a source of major pain
> for us and it continues to cause problems.
> 
> If people wanna keep this and enjoy the pain, I will make a v2 that
> applies it to radeon drivers only.
> 
> v2: update comments and docs
> ---
>  docs/application-issues.html|  3 +-
>  docs/postprocess.html   |  3 +-
>  include/GL/internal/dri_interface.h |  2 +-
>  src/mesa/drivers/dri/common/xmlconfig.c | 51 
> ++---
>  4 files changed, 18 insertions(+), 41 deletions(-)
> 
> diff --git a/docs/application-issues.html b/docs/application-issues.html
> index 6db0865..5605f33 100644
> --- a/docs/application-issues.html
> +++ b/docs/application-issues.html
> @@ -26,22 +26,21 @@ This page documents known issues with some OpenGL 
> applications.
>  
>  http://www.topogun.com/";>Topogun for Linux (version 2, at least)
>  creates a GLX visual without requesting a depth buffer.
>  This causes bad rendering if the OpenGL driver happens to choose a visual
>  without a depth buffer.
>  
>  
>  
>  Mesa 9.1.2 and later (will) support a DRI configuration option to work around
>  this issue.
> -Using the http://dri.freedesktop.org/wiki/DriConf";>driconf tool,
> -set the "Create all visuals with a depth buffer" option before running 
> Topogun.
> +Set the "always_have_depth_buffer" environment variable before running 
> Topogun.
>  Then, all GLX visuals will be created with a depth buffer.
>  
>  
>  
>  Old OpenGL games
>  
>  
>  Some old OpenGL games (approx. ten years or older) may crash during
>  start-up because of an extension string buffer-overflow problem.
>  
> diff --git a/docs/postprocess.html b/docs/postprocess.html
> index db4abec..8108179 100644
> --- a/docs/postprocess.html
> +++ b/docs/postprocess.html
> @@ -17,22 +17,21 @@
>  Gallium Post-processing
>  
>  
>  The Gallium drivers support user-defined image post-processing.
>  At the end of drawing a frame a post-processing filter can be applied to
>  the rendered image.
>  Example filters include morphological antialiasing and cell shading.
>  
>  
>  
> -The filters can be toggled per-app via driconf, or per-session via the
> -corresponding environment variables.
> +The filters can be via the corresponding environment variables.
>  
>  
>  
>  Multiple filters can be used together.
>  
>  
>  
>  PP environment variables
>  
>  
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 8922356..7468cab 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -1515,21 +1515,21 @@ struct __DRI2configQueryExtensionRec {
>  
>  typedef struct __DRIrobustnessExtensionRec __DRIrobustnessExtension;
>  struct __DRIrobustnessExtensionRec {
> __DRIextension base;
>  };
>  
>  /**
>   * DRI config options extension.
>   *
>   * This extension provides the XML string containing driver options for use 
> by
> - * the loader in supporting the driconf application.
> + * the loader.
>   */
>  #define __DRI_CONFIG_OPTIONS "DRI_ConfigOptions"
>  #define __DRI_CONFIG_OPTIONS_VERSION 1
>  
>  typedef struct __DRIconfigOptionsExtensionRec {
> __DRIextension base;
> const char *xml;
>  } __DRIconfigOptionsExtension;
>  
>  /**
> diff --git a/src/mesa/drivers/dri/common/xmlconfig.c 
> b/src/mesa/drivers/dri/common/xmlconfig.c
> index a8f7c9b..3d6cb67 100644
> --- a/src/mesa/drivers/dri/common/xmlconfig.c
> +++ b/src/mesa/drivers/dri/common/xmlconfig.c
> @@ -937,65 +937,44 @@ static void parseOneConfigFile (XML_Parser p) {
>  close (fd);
>  #undef BUF_SIZE
>  }
>  
>  #ifndef SYSCONFDIR
>  #define SYSCONFDIR "/etc"
>  #endif
>  
>  void driParseConfigFiles (driOptionCache *cache, const driOptionCache *info,
> int screenNum, const char *driverName) {
> -char *filenames[2] = { SYSCONFDIR "/drirc", NULL};
> -char *home;
> -uint32_t i;
>  struct OptConfData userData;
> +XML_Parser p;
>  
>  initOptionCache (cache, info);
>  
>  userData.cache = cache;
>  userData.screenNum = screenNum;
>  userData.driverName = driverName;
>  userData.execName = GET_PR

Re: [Mesa-dev] [PATCH] dri: don't load .drirc from $HOME

[Kai Wasserbäch]

Hey Axel,
Axel Davy wrote on 07.01.2017 14:28:
> Expecting the user to use env vars it ok for power users, but not very
> user-friendly for newbies, or just people who don't like using the command 
> line.
> And that's exactly these users who are likely to use something like driconf.

I would guess, that non-power-users play most games through Steam and there you
have the launch options setting. So no need to go to the command line. Ok, there
might be some Wine users with custom stuff out there, but then I find that many
programs require me to go to the CLI anyway if I want to contain them into a
unique prefix (which IMHO is a good idea regardless of this discussion). And
even if not: editing the .desktop file shouldn't be harder than editing 
~/.drirc.

Anyway, I have no strong feelings on this, I just prefer a system, where I can't
screw myself over because I forgot I set some option ages ago.

What I really wouldn't like is the drivers behaving differently. That's sure to
cause support trouble down the line.

Just my 2 cents, though.

Cheers,
Kai


> On 07/01/2017 14:23, Kai Wasserbäch wrote:
>> Hey Marek,
>> maybe <http://mesa3d.org/application-issues.html> should be updated then as
>> well? Just so the page doesn't recommend using driconf? Apart from that, the
>> page is basically useless anyway so maybe deleting it altogether would be 
>> best?
>> (What would be nicer to have would be a page listing all options one can set,
>> like the allow_glsl_extension_directive_midshader and similar options.)
>>
>> Apart from that I find the idea (from a user POV) good. If I want options
>> applied I can always set them on the command line while launching. And/Or 
>> send a
>> patch for the system dric if I find it important enough. Which reminds me 
>> that I
>> wanted to send one for "Divinity: Original Sin Enhanced Edition".
>>
>> Cheers,
>> Kai
>>
>>
>> Marek Olšák wrote on 07.01.2017 13:45:
>>> From: Marek Olšák 
>>>
>>> ~/.drirc is created by the driconf tool (GPL license) and it overrides
>>> system drirc settings and can't be changed by Mesa updates.
>>> This drops support for the tool. It has been a source of major pain
>>> for us and it continues to cause problems.
>>>
>>> If people wanna keep this and enjoy the pain, I will make a v2 that
>>> applies it to radeon drivers only.
>>> ---
>>>   src/mesa/drivers/dri/common/xmlconfig.c | 51 
>>> ++---
>>>   1 file changed, 15 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
>>> b/src/mesa/drivers/dri/common/xmlconfig.c
>>> index a8f7c9b..3d6cb67 100644
>>> --- a/src/mesa/drivers/dri/common/xmlconfig.c
>>> +++ b/src/mesa/drivers/dri/common/xmlconfig.c
>>> @@ -937,65 +937,44 @@ static void parseOneConfigFile (XML_Parser p) {
>>>   close (fd);
>>>   #undef BUF_SIZE
>>>   }
>>> #ifndef SYSCONFDIR
>>>   #define SYSCONFDIR "/etc"
>>>   #endif
>>> void driParseConfigFiles (driOptionCache *cache, const driOptionCache 
>>> *info,
>>> int screenNum, const char *driverName) {
>>> -char *filenames[2] = { SYSCONFDIR "/drirc", NULL};
>>> -char *home;
>>> -uint32_t i;
>>>   struct OptConfData userData;
>>> +XML_Parser p;
>>> initOptionCache (cache, info);
>>> userData.cache = cache;
>>>   userData.screenNum = screenNum;
>>>   userData.driverName = driverName;
>>>   userData.execName = GET_PROGRAM_NAME();
>>>   -if ((home = getenv ("HOME"))) {
>>> -uint32_t len = strlen (home);
>>> -filenames[1] = malloc(len + 7+1);
>>> -if (filenames[1] == NULL)
>>> -__driUtilMessage ("Can't allocate memory for %s/.drirc.", home);
>>> -else {
>>> -memcpy (filenames[1], home, len);
>>> -memcpy (filenames[1] + len, "/.drirc", 7+1);
>>> -}
>>> -}
>>> -
>>> -for (i = 0; i < 2; ++i) {
>>> -XML_Parser p;
>>> -if (filenames[i] == NULL)
>>> -continue;
>>> -
>>> -p = XML_ParserCreate (NULL); /* use encoding specified by file */
>>> -XML_SetElementHandler (p, optConfStartElem, optConfEndElem);
>>> -XML_SetUserData (p, &userData);
>>> -userData.parser = p;
>>> -userData.

[Mesa-dev] [PATCH] drirc: Allow extension midshader for Divinity: Original Sin (EE)

[Kai Wasserbäch]

See also <https://bugs.freedesktop.org/show_bug.cgi?id=93551#c27> where
this was first observed as a requirement.

Signed-off-by: Kai Wasserbäch 
---
 src/mesa/drivers/dri/common/drirc | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/drivers/dri/common/drirc 
b/src/mesa/drivers/dri/common/drirc
index af84ee82e8..798283fd3e 100644
--- a/src/mesa/drivers/dri/common/drirc
+++ b/src/mesa/drivers/dri/common/drirc
@@ -100,5 +100,9 @@ TODO: document the other workarounds.
 
 
 
+
+
+
+
 
 
-- 
2.11.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri: don't load .drirc from $HOME

[Kai Wasserbäch]

Hey Marek,
maybe <http://mesa3d.org/application-issues.html> should be updated then as
well? Just so the page doesn't recommend using driconf? Apart from that, the
page is basically useless anyway so maybe deleting it altogether would be best?
(What would be nicer to have would be a page listing all options one can set,
like the allow_glsl_extension_directive_midshader and similar options.)

Apart from that I find the idea (from a user POV) good. If I want options
applied I can always set them on the command line while launching. And/Or send a
patch for the system dric if I find it important enough. Which reminds me that I
wanted to send one for "Divinity: Original Sin Enhanced Edition".

Cheers,
Kai


Marek Olšák wrote on 07.01.2017 13:45:
> From: Marek Olšák 
> 
> ~/.drirc is created by the driconf tool (GPL license) and it overrides
> system drirc settings and can't be changed by Mesa updates.
> This drops support for the tool. It has been a source of major pain
> for us and it continues to cause problems.
> 
> If people wanna keep this and enjoy the pain, I will make a v2 that
> applies it to radeon drivers only.
> ---
>  src/mesa/drivers/dri/common/xmlconfig.c | 51 
> ++---
>  1 file changed, 15 insertions(+), 36 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/common/xmlconfig.c 
> b/src/mesa/drivers/dri/common/xmlconfig.c
> index a8f7c9b..3d6cb67 100644
> --- a/src/mesa/drivers/dri/common/xmlconfig.c
> +++ b/src/mesa/drivers/dri/common/xmlconfig.c
> @@ -937,65 +937,44 @@ static void parseOneConfigFile (XML_Parser p) {
>  close (fd);
>  #undef BUF_SIZE
>  }
>  
>  #ifndef SYSCONFDIR
>  #define SYSCONFDIR "/etc"
>  #endif
>  
>  void driParseConfigFiles (driOptionCache *cache, const driOptionCache *info,
> int screenNum, const char *driverName) {
> -char *filenames[2] = { SYSCONFDIR "/drirc", NULL};
> -char *home;
> -uint32_t i;
>  struct OptConfData userData;
> +XML_Parser p;
>  
>  initOptionCache (cache, info);
>  
>  userData.cache = cache;
>  userData.screenNum = screenNum;
>  userData.driverName = driverName;
>  userData.execName = GET_PROGRAM_NAME();
>  
> -if ((home = getenv ("HOME"))) {
> - uint32_t len = strlen (home);
> - filenames[1] = malloc(len + 7+1);
> - if (filenames[1] == NULL)
> - __driUtilMessage ("Can't allocate memory for %s/.drirc.", home);
> - else {
> - memcpy (filenames[1], home, len);
> - memcpy (filenames[1] + len, "/.drirc", 7+1);
> - }
> -}
> -
> -for (i = 0; i < 2; ++i) {
> - XML_Parser p;
> - if (filenames[i] == NULL)
> - continue;
> -
> - p = XML_ParserCreate (NULL); /* use encoding specified by file */
> - XML_SetElementHandler (p, optConfStartElem, optConfEndElem);
> - XML_SetUserData (p, &userData);
> - userData.parser = p;
> - userData.name = filenames[i];
> - userData.ignoringDevice = 0;
> - userData.ignoringApp = 0;
> - userData.inDriConf = 0;
> - userData.inDevice = 0;
> - userData.inApp = 0;
> - userData.inOption = 0;
> -
> - parseOneConfigFile (p);
> - XML_ParserFree (p);
> -}
> -
> -free(filenames[1]);
> +p = XML_ParserCreate (NULL); /* use encoding specified by file */
> +XML_SetElementHandler (p, optConfStartElem, optConfEndElem);
> +XML_SetUserData (p, &userData);
> +userData.parser = p;
> +userData.name = SYSCONFDIR "/drirc";
> +userData.ignoringDevice = 0;
> +userData.ignoringApp = 0;
> +userData.inDriConf = 0;
> +userData.inDevice = 0;
> +userData.inApp = 0;
> +userData.inOption = 0;
> +
> +parseOneConfigFile (p);
> +XML_ParserFree (p);
>  }
>  
>  void driDestroyOptionInfo (driOptionCache *info) {
>  driDestroyOptionCache (info);
>  if (info->info) {
>   uint32_t i, size = 1 << info->tableSize;
>   for (i = 0; i < size; ++i) {
>   if (info->info[i].name) {
>   free(info->info[i].name);
>   free(info->info[i].ranges);
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: fix depth transitions with layerCount = VK_REMAINING_ARRAY_LAYERS

[Kai Wasserbäch]

Hey Pierre,
this looks like it went to the wrong list. radv patches should be sent to
 AFAIK (CCed with this message).

Cheers,
Kai


Pierre-Loup A. Griffais wrote on 06.01.2017 21:57:
> Interpreting layerCount literally would try to create billions of image
> views in radv_process_depth_image_inplace().
> 
> Signed-off-by: Pierre-Loup A. Griffais 
> ---
>  src/amd/vulkan/radv_meta_decompress.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/amd/vulkan/radv_meta_decompress.c 
> b/src/amd/vulkan/radv_meta_decompress.c
> index 47ef64d..9f262e6 100644
> --- a/src/amd/vulkan/radv_meta_decompress.c
> +++ b/src/amd/vulkan/radv_meta_decompress.c
> @@ -382,7 +382,7 @@ static void radv_process_depth_image_inplace(struct 
> radv_cmd_buffer *cmd_buffer,
>  
>   radv_meta_save_graphics_reset_vport_scissor(&saved_state, cmd_buffer);
>  
> - for (uint32_t layer = 0; layer < subresourceRange->layerCount; layer++) 
> {
> + for (uint32_t layer = 0; layer < radv_get_layerCount(image, 
> subresourceRange); layer++) {
>   struct radv_image_view iview;
>  
>   radv_image_view_init(&iview, cmd_buffer->device,
> 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Clamp negative values in glGetUniformuiv

[Kai Wasserbäch]

Nicolai Hähnle wrote on 10.12.2016 19:12:
> On 10.12.2016 18:19, Kai Wasserbäch wrote:
>> Nicolai Hähnle wrote on 10.12.2016 14:54:
>>> From: Nicolai Hähnle 
>>>
>>> Section 2.2.2 (Data Conversions For State Query Commands) of the OpenGL 4.5
>>> (Compatibility Profile) spec says:
>>>
>>> "If a value is so large in magnitude that it cannot be represented by 
>>> the
>>>  returned data type, then the nearest value representable using the
>>>  requested type is returned."
>>>
>>> This is reasonably interpreted as saying that e.g. float uniforms with a
>>> negative value should be clamped to 0 when queried as an unsigned integer.
>>>
>>> Fixes GL45-CTS.gpu_shader_fp64.state_query.
>>> ---
>>>  src/mesa/main/imports.h | 17 +
>>>  src/mesa/main/uniform_query.cpp | 21 -
>>>  2 files changed, 37 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
>>> index ef7c378..2af0add 100644
>>> --- a/src/mesa/main/imports.h
>>> +++ b/src/mesa/main/imports.h
>>> @@ -158,20 +158,37 @@ static inline int IROUNDD(double d)
>>>  }
>>>
>>>  /**
>>>   * Convert float to int64 by rounding to nearest integer.
>>>   */
>>>  static inline GLint64 IROUND64(float f)
>>>  {
>>> return (GLint64) ((f >= 0.0F) ? (f + 0.5F) : (f - 0.5F));
>>>  }
>>>
>>> +/**
>>> + * Convert float to unsigned int by rounding to nearest integer, away from
>>> zero.
>>> + */
>>> +static inline unsigned int UROUND(float f)
>>> +{
>>> +   return (unsigned int) ((f >= 0.0F) ? (f + 0.5F) : 0.0F);
>>> +}
>>> +
>>> +/**
>>> + * Convert double to unsigned int by rounding to nearest integer, away from
>>> + * zero.
>>> + */
>>> +static inline unsigned int UROUNDD(double d)
>>> +{
>>> +   return (unsigned int) ((d >= 0.0) ? (d + 0.5) : 0.0);
>>> +}
>>> +
>>>
>>>  /**
>>>   * Convert positive float to int by rounding to nearest integer.
>>>   */
>>>  static inline int IROUND_POS(float f)
>>>  {
>>> assert(f >= 0.0F);
>>> return (int) (f + 0.5F);
>>>  }
>>>
>>> diff --git a/src/mesa/main/uniform_query.cpp 
>>> b/src/mesa/main/uniform_query.cpp
>>> index 3108d34..8e390cc 100644
>>> --- a/src/mesa/main/uniform_query.cpp
>>> +++ b/src/mesa/main/uniform_query.cpp
>>> @@ -415,21 +415,20 @@ _mesa_get_uniform(struct gl_context *ctx, GLuint
>>> program, GLint location,
>>>double tmp = src[sidx].f;
>>>memcpy(&dst[didx].f, &tmp, sizeof(tmp));
>>>break;
>>> }
>>> default:
>>>assert(!"Should not get here.");
>>>break;
>>> }
>>> break;
>>>  case GLSL_TYPE_INT:
>>> -case GLSL_TYPE_UINT:
>>> switch (uni->type->base_type) {
>>> case GLSL_TYPE_FLOAT:
>>>/* While the GL 3.2 core spec doesn't explicitly
>>> * state how conversion of float uniforms to integer
>>> * values works, in section 6.2 "State Tables" on
>>> * page 267 it says:
>>> *
>>> * "Unless otherwise specified, when floating
>>> *  point state is returned as integer values or
>>> *  integer state is returned as floating-point
>>> @@ -452,20 +451,40 @@ _mesa_get_uniform(struct gl_context *ctx, GLuint
>>> program, GLint location,
>>>memcpy(&tmp, &src[sidx].f, sizeof(tmp));
>>>dst[didx].i = IROUNDD(tmp);
>>>break;
>>> }
>>> default:
>>>assert(!"Should not get here.");
>>>break;
>>> }
>>> break;
>>>
>>> +case GLSL_TYPE_UINT:
>>> +   switch (uni->type->base_type) {
>>> +   case GLSL_TYPE_FLOAT:
>>> +  dst[didx].u = UROUND(src[sidx].f);
>>> +  break;
>>> +   case GLSL_TYPE_BOOL:
>

Re: [Mesa-dev] [PATCH] mesa: Clamp negative values in glGetUniformuiv

[Kai Wasserbäch]

Nicolai Hähnle wrote on 10.12.2016 14:54:
> From: Nicolai Hähnle 
> 
> Section 2.2.2 (Data Conversions For State Query Commands) of the OpenGL 4.5
> (Compatibility Profile) spec says:
> 
> "If a value is so large in magnitude that it cannot be represented by the
>  returned data type, then the nearest value representable using the
>  requested type is returned."
> 
> This is reasonably interpreted as saying that e.g. float uniforms with a
> negative value should be clamped to 0 when queried as an unsigned integer.
> 
> Fixes GL45-CTS.gpu_shader_fp64.state_query.
> ---
>  src/mesa/main/imports.h | 17 +
>  src/mesa/main/uniform_query.cpp | 21 -
>  2 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index ef7c378..2af0add 100644
> --- a/src/mesa/main/imports.h
> +++ b/src/mesa/main/imports.h
> @@ -158,20 +158,37 @@ static inline int IROUNDD(double d)
>  }
>  
>  /**
>   * Convert float to int64 by rounding to nearest integer.
>   */
>  static inline GLint64 IROUND64(float f)
>  {
> return (GLint64) ((f >= 0.0F) ? (f + 0.5F) : (f - 0.5F));
>  }
>  
> +/**
> + * Convert float to unsigned int by rounding to nearest integer, away from 
> zero.
> + */
> +static inline unsigned int UROUND(float f)
> +{
> +   return (unsigned int) ((f >= 0.0F) ? (f + 0.5F) : 0.0F);
> +}
> +
> +/**
> + * Convert double to unsigned int by rounding to nearest integer, away from
> + * zero.
> + */
> +static inline unsigned int UROUNDD(double d)
> +{
> +   return (unsigned int) ((d >= 0.0) ? (d + 0.5) : 0.0);
> +}
> +
>  
>  /**
>   * Convert positive float to int by rounding to nearest integer.
>   */
>  static inline int IROUND_POS(float f)
>  {
> assert(f >= 0.0F);
> return (int) (f + 0.5F);
>  }
>  
> diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
> index 3108d34..8e390cc 100644
> --- a/src/mesa/main/uniform_query.cpp
> +++ b/src/mesa/main/uniform_query.cpp
> @@ -415,21 +415,20 @@ _mesa_get_uniform(struct gl_context *ctx, GLuint 
> program, GLint location,
>double tmp = src[sidx].f;
>memcpy(&dst[didx].f, &tmp, sizeof(tmp));
> break;
> }
>  default:
> assert(!"Should not get here.");
> break;
>  }
>  break;
>   case GLSL_TYPE_INT:
> - case GLSL_TYPE_UINT:
>  switch (uni->type->base_type) {
>  case GLSL_TYPE_FLOAT:
> /* While the GL 3.2 core spec doesn't explicitly
>  * state how conversion of float uniforms to integer
>  * values works, in section 6.2 "State Tables" on
>  * page 267 it says:
>  *
>  * "Unless otherwise specified, when floating
>  *  point state is returned as integer values or
>  *  integer state is returned as floating-point
> @@ -452,20 +451,40 @@ _mesa_get_uniform(struct gl_context *ctx, GLuint 
> program, GLint location,
>memcpy(&tmp, &src[sidx].f, sizeof(tmp));
>dst[didx].i = IROUNDD(tmp);
> break;
> }
>  default:
> assert(!"Should not get here.");
> break;
>  }
>  break;
>  
> + case GLSL_TYPE_UINT:
> +switch (uni->type->base_type) {
> +case GLSL_TYPE_FLOAT:
> +   dst[didx].u = UROUND(src[sidx].f);
> +   break;
> +case GLSL_TYPE_BOOL:
> +   dst[didx].u = src[sidx].i ? 1 : 0;
> +   break;
> +   case GLSL_TYPE_DOUBLE: {
> +  double tmp;
> +  memcpy(&tmp, &src[sidx].f, sizeof(tmp));
> +  dst[didx].u = UROUNDD(tmp);
> +   break;
> +   }
> +default:
> +   assert(!"Should not get here.");

Shouldn't this be a call to unreachable()? (And if so, then probably change the
default a few lines below as well?)

> +   break;
> +}
> +break;
> +
>   default:
>  assert(!"Should not get here.");
>  break;
>   }
>}
>}
> }
>  }
>  
>  static void

The rest of the change looks reasonable to me.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Stable release process

[Kai Wasserbäch]

Hi everybody,
Nicolai Hähnle wrote on 18.11.2016 17:48:
> On 18.11.2016 16:56, Emil Velikov wrote:
>> On 18 November 2016 at 12:34, Marek Olšák  wrote:
>>> On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov  
>>> wrote:
>>> [...]
 Speaking of patchwork, mostly I'm fine with it. There are some
 "drawbacks" though:
  - some duplicated time will be spent tagging "self-rejected" patches.
 I already track these based from the mailing list.
  - it doesn't parse "Pick commit $sha, it addresses $issue"
 nominations, so it cannot substitute/replace the mailing list.
 In case my first point brought some "don't bother with the ML" type of
 thoughts.
  - you don't seem to be using it [1] so I'm not sure of the sudden 
 interest.
>>>
>>> Patchwork can't clear any of my patches on git push. That's normal. I
>>> do use Patchwork for reviewing patches though.
>>>
>> Seems to work fairly well here. Admittedly I have way less (and
>> smaller) patches...
> 
> Patchwork is pretty dumb about how it compares patches. If you have 
> non-standard
> git diff settings (e.g. more lines of context), it will never recognize a 
> patch.

wouldn't a tool like Phabricator be much better for reviewing and reliably
tracking whether a patch has landed or not? Especially if you use it in
combination with Arcanist? While I'm certainly not a core developer, I find
patchwork clunky. Sometimes it doesn't pick up R-bs or doesn't recognise series,
which makes seeing the actual state of a patch a bit tricky from time to time.

In addition you would get things like automatically closure of bugs, nice
referencing features and lots of other nice features. And AFAIK freedesktop.org
already has a Phabricator instance, which could be used.

Just my outside opinion, though. ;-)

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc1

[Kai Wasserbäch]

Hey Emil, hey Jason,
Emil Velikov wrote on 20.10.2016 17:28:
> On 20 October 2016 at 16:20, Jason Ekstrand  wrote:
>> On Oct 20, 2016 8:11 AM, "Emil Velikov"  wrote:
>>>
>>> On 19 October 2016 at 20:31, Jason Ekstrand  wrote:
>>>> On Wed, Oct 19, 2016 at 12:16 PM, Emil Velikov
>>>> 
>>>> wrote:
>>>>>
>>>>> On 19 October 2016 at 19:50, Kai Wasserbäch
>>>>> 
>>>>> wrote:
>>>>>> Hey Emil,
>>>>>> just curious why you did the revert
>>>>>>
>>>>>>
>>>>>> (<https://cgit.freedesktop.org/mesa/mesa/commit/?h=13.0&id=2ced8eb136528914e1bf4e000dea06a9d53c7e04>).
>>>>>> Wouldn't distros just set --disable-vulkan-icd-full-driver-path (I
>>>>>> know
>>>>>> I'm
>>>>>> doing that for Multi-Arch compatibility for my local builds)?
>>>>>>
>>>>> Yes they can, yet they shouldn't need to bother to begin with, since
>>>>> the code itself is not aimed at deployment ;-)
>>>>
>>>>
>>>> What code isn't aimed at deployment?
>>>>
>>>> Don't just go reverting commits in the release branch on your own
>>>> authority
>>>> with no discussion.  If that flag is causing problems for distros and
>>>> packagers, let's hear from them and they can tell us what they need.
>>>>
>>> I believe I mentioned it before - due to the high traffic on mesa-dev@
>>> little-to-no distro maintainers get to read upon decisions and/or cast
>>> their opinion. In most cases they'll just workout something locally
>>> and not bother (-ETIME or other) prodding upstream.
>>>
>>> I believe I explained it in length why the original and follow up are
>>> bad idea, suggested two alternative solutions and a Nack on the patch.
>>> Only to get all that fall though the cracks :-\
>>>
>>>> Also, it's not in there for developers.  It's in there for people who
>>>> want
>>>> to do a local build and have "make install" work somewhat correctly.
>>> Doing `make install' to a non-default prefix falls in the
>>> development/testing category.
>>>
>>> In either case using  LD_LIBRARY_PATH is a must _regardless_ of the
>>> software that one's building/testing. That is unless you're using
>>> chroot :-)
>>
>> ./configure --prefix=$HOME/.local
>> make
>> make install
>>
>> Works today without LD_LIBRARY_PATH
>>
> "In either case using  LD_LIBRARY_PATH is a must _regardless_ of the
> software that one's building/testing".
> 
> I realise that the Vulkan spec does not mention that, but this is a
> common practise that everyone should be using.
> 
> Mildly related: I thought you/others are using VK_ICD_FILENAMES +
> dev_icd.json. Or is that one somehow wrong/deprecated ?

maybe the solution to this discussion can be to switch the default around then?
By default you get the relative (just library name), and if you set something
like "--with-vulkan-icd-loader-path=..." you get a full path?
That way distributions don't have to do anything and developers can set it
easily enough.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc1

[Kai Wasserbäch]

Hey Emil,
just curious why you did the revert
(<https://cgit.freedesktop.org/mesa/mesa/commit/?h=13.0&id=2ced8eb136528914e1bf4e000dea06a9d53c7e04>).
Wouldn't distros just set --disable-vulkan-icd-full-driver-path (I know I'm
doing that for Multi-Arch compatibility for my local builds)?

Cheers,
Kai

P.S.: radv is doing the "just the library name" thing in any case (even on
development branches). Should that be changed then?


Emil Velikov wrote on 19.10.2016 20:44:
> The first release candidate for Mesa 13.0.0 is now available.
> 
> The plan is to have one release candidate every Friday, until the final
> release on October 28th 2016.
> 
> As a reminder, with the 13.0 branch now created, patches nominated with:
> 
> CC: 
> 
> will now be candidates only for the new 13.0 branch. To nominate patches
> for the older 12.0 branch as well, please use:
> 
> CC: "12.0 13.0" 
> 
> The expectation is that the 12.0 branch will remain alive with bi-weekly
> releases until after 13.0.1 release.
> 
> 
> Here are the people which helped shape the current release.
> 
>  1 Aaron Watry
> 10 Adam Jackson
>  1 Akihiko Odaki
> 11 Alejandro Piñeiro
>  1 Alex Deucher
>  3 Andreas Boll
> 10 Andres Gomez
>  2 Andy Furniss
>  1 Antia Puentes
> 37 Anuj Phogat
>  1 Ardinartsev Nikita
> 65 Axel Davy
>  3 Bas Nieuwenhuizen
>  1 Ben Skeggs
>  4 Ben Widawsky
>  1 Bernard Kilarski
> 19 Boyuan Zhang
>  1 Brendan King
>142 Brian Paul
>  2 Bruce Cherniak
>  2 Carl Worth
> 38 Chad Versace
> 30 Charmaine Lee
>  1 Chris Wilson
>  1 Christian Gmeiner
> 10 Christian König
>  2 Christoph Haag
>  4 Chuanbo Weng
>  4 Chuck Atkins
>  3 Colin McDonald
>  3 Connor Abbott
>  1 Daniel Czarnowski
>  1 Daniel Scharrer
>115 Dave Airlie
>  1 Dieter Nützel
>  1 Dongwon Kim
> 13 Dylan Baker
>  1 Eduardo Lima Mitev
>  7 Edward O'Callaghan
>  1 Eero Tamminen
>164 Emil Velikov
>  1 Emilio Cobos Álvarez
>126 Eric Anholt
> 37 Eric Engestrom
>  4 Francesco Ansanelli
>186 Francisco Jerez
>  6 Frank Binns
>  1 Giuseppe Bilotta
>  1 Glenn Kennard
>  1 Grazvydas Ignotas
>  1 Gregory Hainaut
>  3 Grigori Goronzy
>  1 Guillaume Charifi
>  3 Gurchetan Singh
>  2 Gurkirpal Singh
>  3 Gustaw Smolarczyk
>  5 Haixia Shi
>  8 Hans de Goede
> 12 Iago Toral Quiroga
>139 Ian Romanick
>139 Ilia Mirkin
>  3 Indrajit Das
>  2 Jakob Sinclair
>  1 James Legg
>  9 Jan Vesely
>  5 Jan Ziak
>506 Jason Ekstrand
>  1 Jimmy Berry
>  4 Jon Turney
>  7 Jonathan Gray
> 33 Jordan Justen
> 16 José Fonseca
>  8 Julien Isorce
>  3 Józef Kucia
>  6 Kai Wasserbäch
>  4 Karol Herbst
>215 Kenneth Graunke
>  1 Kevin Strasser
>  1 Kristian Høgsberg Kristensen
> 14 Kyle Brenneman
>  3 Lars Hamre
> 28 Leo Liu
> 29 Lionel Landwerlin
>  1 Marc-André Lureau
>401 Marek Olšák
>  2 Mario Kleiner
>  6 Mark Thompson
>  2 Martin Peres
>  2 Martina Kollarova
> 52 Mathias Fröhlich
> 34 Matt Turner
>  5 Matt Whitlock
> 13 Mauro Rossi
>  1 Max Staudt
>  7 Michel Dänzer
>  4 Miklós Máté
> 21 Nanley Chery
> 14 Nayan Deshmukh
> 15 Neha Bhende
>  5 Nicholas Bishop
>232 Nicolai Hähnle
>  8 Nicolas Boichat
>  3 Nicolas Koch
>  1 Niels Ole Salscheider
>  1 Nils Wallménius
> 25 Patrick Rudolph
>  1 Philipp Zabel
>  1 Pierre Moreau
>  2 Plamena Manolova
>  5 Rhys Kidd
> 84 Rob Clark
>  7 Rob Herring
>  2 Rodrigo Vivi
> 15 Roland Scheidegger
>  1 Ronie Salgado
> 10 Samuel Iglesias Gonsálvez
> 98 Samuel Pitoiset
>  5 Serge Martin
>  7 Sirisha Gandikota
>  1 Stefan Dirsch
>  1 Stencel, Joanna
>  1 Stephan Bergmann
>  4 Steven Toth
> 13 Tapani Pälli
> 20 Thomas Helland
>  1 Thomas Hellstrom
>125 Tim Rowley
>123 Timothy Arceri
>  2 Tobias Klausmann
> 13 Tom Stellard
> 15 Tomasz Figa
> 40 Topi Pohjolainen
>  1 Trevor Davenport
>  3 Vedran Miletić
>  1 Ville Syrjälä
>  4 Vinson Lee
>  1 Xu,Randy
>  2 Yaakov Selkowitz
> 10 franci...@gmail.com
>  3 sonjiang
> 
> 
> git tag: mesa-13.0.0-rc1
> 
> ftp://ftp.freedesktop.org/pub/mesa/13.0.0

Re: [Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

[Kai Wasserbäch]

Disregard this, the mbox file only contained the second patch. Sorry for the 
noise.

Kai Wasserbäch wrote on 13.10.2016 19:20:
> Dear Tom,
> just FYI: this fails to apply on top of master
> (761388a0eb586b1dcaec063ee561056ed132dc1a). git am chokes on the
> visit_image_store() hunk for me. Attached is a "refreshed" version, which
> applies for me. I hope I didn't butcher anything inadvertently.
> 
> Cheers,
> Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

[Kai Wasserbäch]

;  
>   params[0] = get_image_coords(ctx, instr, add_frag_pos);
>   params[1] = get_sampler_desc(ctx, instr->variables[0], 
> DESC_IMAGE);
>   params[2] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
> - params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
> - params[4] = da ? ctx->i32one : ctx->i32zero; /* da */
> - params[5] = LLVMConstInt(ctx->i1, 0, false);  /* glc */
> - params[6] = LLVMConstInt(ctx->i1, 0, false);  /* slc */
> + if (HAVE_LLVM <= 0x0309) {
> + params[3] = LLVMConstInt(ctx->i1, 0, false);  /* r128 */
> + params[4] = da;
> + params[5] = glc;
> + params[6] = slc;
> + } else {
> + LLVMValueRef lwe = LLVMConstInt(ctx->i1, 0, false);
> + params[3] = glc;
> + params[4] = slc;
> + params[5] = lwe;
> + params[6] = da;
> + }
>  
> - build_int_type_name(LLVMTypeOf(params[0]),
> - coords_type, sizeof(coords_type));
> + get_image_intr_name("llvm.amdgcn.image.load",
> + ctx->v4f32, /* vdata */
> + LLVMTypeOf(params[0]), /* coords */
> + LLVMTypeOf(params[1]), /* rsrc */
> + intrinsic_name, sizeof(intrinsic_name));
>  
> - snprintf(intrinsic_name, sizeof(intrinsic_name),
> - "llvm.amdgcn.image.load.%s", coords_type);
>   res = emit_llvm_intrinsic(ctx, intrinsic_name, ctx->v4f32,
>   params, 7, LLVMReadOnlyAttribute);
>   }
> @@ -2349,8 +2421,7 @@ static void visit_image_store(struct 
> nir_to_llvm_context *ctx,
> nir_intrinsic_instr *instr)
>  {
>   LLVMValueRef params[8];
> - char intrinsic_name[32];
> - char coords_type[8];
> + char intrinsic_name[64];
>   const nir_variable *var = instr->variables[0]->var;
>   LLVMValueRef i1false = LLVMConstInt(ctx->i1, 0, 0);
>   LLVMValueRef i1true = LLVMConstInt(ctx->i1, 1, 0);
> @@ -2370,23 +2441,35 @@ static void visit_image_store(struct 
> nir_to_llvm_context *ctx,
>   emit_llvm_intrinsic(ctx, 
> "llvm.amdgcn.buffer.store.format.v4f32", ctx->voidt,
>   params, 6, 0);
>   } else {
> - bool da = glsl_sampler_type_is_array(type) ||
> -   glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_CUBE;
> + bool is_da = glsl_sampler_type_is_array(type) ||
> +  glsl_get_sampler_dim(type) == 
> GLSL_SAMPLER_DIM_CUBE;
> + LLVMValueRef da = is_da ? i1true : i1false;
> + LLVMValueRef glc = i1false;
> + LLVMValueRef slc = i1false;
>  
>   params[0] = get_src(ctx, instr->src[2]);
>   params[1] = get_image_coords(ctx, instr, false); /* coords */
>   params[2] = get_sampler_desc(ctx, instr->variables[0], 
> DESC_IMAGE);
>   params[3] = LLVMConstInt(ctx->i32, 15, false); /* dmask */
> - params[4] = i1false;  /* r128 */
> - params[5] = da ? i1true : i1false; /* da */
> - params[6] = i1false;  /* glc */
> - params[7] = i1false;  /* slc */
> + if (HAVE_LLVM <= 0x0309) {
> + params[4] = i1false;  /* r128 */
> + params[5] = da;
> + params[6] = glc;
> + params[7] = slc;
> + } else {
> + LLVMValueRef lwe = i1false;
> + params[4] = glc;
> + params[5] = slc;
> + params[6] = lwe;
> + params[7] = da;
> +     }
>  
> - build_int_type_name(LLVMTypeOf(params[1]),
> - coords_type, sizeof(coords_type));
> + get_image_intr_name("llvm.amdgcn.image.store",
> + LLVMTypeOf(params[0]), /* vdata */
> + LLVMTypeOf(params[1]), /* coords */
> + LLVMTypeOf(params[2]), /* rsrc */
> + intrinsic_name, sizeof(intrinsic_name));
>  
> - snprintf(intrinsic_name, sizeof(intrinsic_name),
> -  "llvm.amdgcn.image.stor

Re: [Mesa-dev] mesamatrix.net summary problem

[Kai Wasserbäch]

You're probably overlooking GL_ARB_shader_group_vote.

Boszormenyi Zoltan wrote on 08.10.2016 17:53:
> Hi,
> 
> I just skimmed through the list of supported extensions by
> both nvc0 and radeonsi on mesamatrix and the number
> at the top of the page should be equal for them.
> 
> nvc0 supports GL_ARB_compute_variable_group_size, radeonsi doesn't.
> radeonsi supports GL_ARB_shader_stencil_export, nvc0 doesn't.
> Everything else is the same for nvc0 and radeonsi.
> 
> So, the summary seems to be broken.
> 
> Best regards,
> Zoltán Böszörményi



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Problem with RX 480 on Alien: Isolation and Dota 2

[Kai Wasserbäch]

Marek Olšák wrote on 13.09.2016 19:53:
> LLVM 64-bit:
> 
> mkdir -p build
> cd build
> cmake .. -G Ninja -DCMAKE_INSTALL_PREFIX=/usr/llvm/x86_64-linux-gnu
> -DLLVM_TARGETS_TO_BUILD="X86;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=O
>   -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON \
>   -DCMAKE_C_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG
> -fno-omit-frame-pointer" \
>   -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG
> -fno-omit-frame-pointer".
> ninja
> sudo ninja install
> 
> 
> LLVM 32-bit:
> 
> mkdir -p build32
> cd build32
> cmake .. -G Ninja -DCMAKE_INSTALL_PREFIX=/usr/llvm/i386-linux-gnu
> -DLLVM_TARGETS_TO_BUILD="X86;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON
>   -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON \
>   -DCMAKE_C_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG
> -fno-omit-frame-pointer" \
>   -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG
> -fno-omit-frame-pointer" \
>   -DLLVM_BUILD_32_BITS=ON
> ninja
> sudo ninja install
> # then add /usr/llvm/x86_64-linux-gnu and /usr/llvm/i386-linux-gnu to
> ld.conf
> 
> 
> Mesa configure helper script, it will overwrite the /usr/lib/ files on
> Ubuntu (run as-is for 64-bit, or use "-32" for 32-bit):

Just a note about Debian/Ubuntu (even though I don't think that's too
interesting for Romain):
Well, if you build for Debian or a derivative like Ubuntu and you do not need
many versions in parallel, ie. as a user, then the best option (IMHO) is using
Debian's package and building it with the current upstream (plus some odd
changes here and there for new symbols and such). LLVM you mostly don't need to
build (in that case), because you can just use the packages from apt.llvm.org,
which Sylvestre, the Debian LLVM maintainer, builds for various Debian and
Ubuntu flavours. (And that saves a lot of the rage-quit potential IMHO, since
building LLVM can take a while and fail in very inopportune moments.) That way
you can switch cleanly back to your distros packages, if something breaks (or
they catch up far enough that you want to stop building Mesa yourself).
Anyway, this is how I do my builds: LLVM only if I have to, in case apt.llvm.org
is currently outdated (happens occasionally) or I'm testing a patch for upstream
inclusion. And Mesa I build regularly by just using git-buildpackage with the
Debian package as a base and a local branch for current Mesa git plus a local
"Debian branch" including different configuration (eg. I was already building
the VA-API stuff for myself before Debian started doing it) or patches (again:
those I'm testing for upstream inclusion), if any. Mesa builds are quite fast,
only a couple of minutes in a clean chroot environment (pbuilder!), so it's not
nearly as annoying as building LLVM.
If there's interest, I could probably whip some guide up, which could be shipped
in Mesa's doc directory?


By the way, since nobody mentioned this so far: if you want OpenCL support
you're going to need to rebuild libclc as well. Your distro's libclc was built
against the LLVM it ships.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: Use enum pipe_shader_type in bind_sampler_states() (v2)

[Kai Wasserbäch]

Hey Michael,
Michael Schellenberger wrote on 26.08.2016 20:19:
> Am 26.08.2016 um 15:23 schrieb Kai Wasserbäch:
>> [...]
>> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_texture.c 
>> b/src/gallium/drivers/nouveau/nv30/nv30_texture.c
>> index 4f4f87e..e5d3db3 100644
>> --- a/src/gallium/drivers/nouveau/nv30/nv30_texture.c
>> +++ b/src/gallium/drivers/nouveau/nv30/nv30_texture.c
>> @@ -188,7 +188,7 @@ nv30_sampler_state_delete(struct pipe_context *pipe, 
>> void *hwcso)
>>  
>>  static void
>>  nv30_bind_sampler_states(struct pipe_context *pipe,
>> - unsigned shader, unsigned start_slot,
>> + enum pipe_shader_type shader, unsigned start_slot,
>>   unsigned num_samplers, void **samplers)
>>  {
>> switch (shader) {
>> @@ -198,6 +198,9 @@ nv30_bind_sampler_states(struct pipe_context *pipe,
>> case PIPE_SHADER_FRAGMENT:
>>nv30_fragtex_sampler_states_bind(pipe, num_samplers, samplers);
>>break;
>> +   default:
>> +  assert(!"unexpected shader type");
>> +  break;
> Shouldnt that be unreachable("unexpected shader type")? The break after
> that shouldnt be necessary. Same for other occurrences.

please see my discussion with Eric
(<https://lists.freedesktop.org/archives/mesa-dev/2016-August/127128.html>).

And since Samuel seemed to be ok (he gave me his R-b) with the assert() I'm
going to leave it as is. If some other change would require a v3 I could change 
it.

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev