from:"Kai Wasserbäch"

Re: [Mesa-dev] [PATCH] mesa: fix _mesa_error() compiler warnings in shaderapi.c

2015-07-23 Thread Kai Wasserbäch

Brian Paul wrote on 07/23/2015 03:58 PM:
> Fix many instances of:
> main/shaderapi.c: In function '_mesa_GetSubroutineUniformLocation':
> main/shaderapi.c:2176:7: warning: format not a string literal and no format 
> arguments [-Wformat-security]
>_mesa_error(ctx, GL_INVALID_OPERATION, api_name);
>^
> 
> Ideally, many of these error messages should be improved to indicate
> which argument is incorrect as we do in other parts of Mesa.

Reviewed-by: Kai Wasserbäch 
Tested-by: Kai Wasserbäch 

Thanks, this broke my build (with a -Werror=format-security from Debian's
default build flags).

Cheers,
Kai



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

Re: [Mesa-dev] [PATCH 1/2] glsl: enable 'shared' keyword also for layout qualifiers

2015-11-13 Thread Kai Wasserbäch

Hi Emil,
Emil Velikov wrote on 12.11.2015 18:45:
> On 12 November 2015 at 15:36, Samuel Iglesias Gonsálvez
>  wrote:
>> On 12/11/15 15:28, Timothy Arceri wrote:
>>> On 13 November 2015 12:22:39 am AEDT, "Samuel Iglesias Gonsálvez" 
>>>  wrote:
 'shared' was added in ARB_uniform_buffer_object and also used
 in ARB_shader_storage_buffer_object.
>>>
>>> Hi Samuel,
>>>
>>> Shared for UBO and SSBOs is not a key word its just an identifier for a 
>>> layout qualifier, are you sure you need to make it available for those 
>>> extensions?
>>>
>>
>> Right. Please ignore this patch.
>>
> In this case, may I suggest that you tag the patch as Rejected (or
> similar) in patchwork [1]. Afaict there are quite a few patches in
> there from yourself and fellow colleagues. Any chance someone can go
> through them and change their status appropriately ?

Since I'm reading this from time to time I was wondering whether Mesa wouldn't
be better served by Phabricator instance? Maybe Matt and Tom, who send in most
of AMD's patches for the AMDGPU backend in LLVM can weigh in here?

I'm using Phabricator myself for a big project and I must say it's really neat.
Most status/meta updates can happen automatically as you commit your changes,
the review state is tracked properly and if a patch was rejected/abandoned that
is usually also clear from the state. Ie. in most cases there is no need to have
multiple people walk through the same list of patches/bugs etc.

(Bonus: for switching over from a Bugzilla to Phabricator, there's a pretty big
precedent with complete porting tools: Wikimedia did that)

Cheers,
Kai

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

[Mesa-dev] OT: Phabricator? (was: Re: [PATCH 1/2] glsl: enable 'shared' keyword also for layout qualifiers)

2015-11-13 Thread Kai Wasserbäch

Hi Emil,
Emil Velikov wrote on 13.11.2015 13:58:
> On 13 November 2015 at 09:14, Kai Wasserbäch  
> wrote:
>> Emil Velikov wrote on 12.11.2015 18:45:
>>> On 12 November 2015 at 15:36, Samuel Iglesias Gonsálvez
>>>  wrote:
>>>> On 12/11/15 15:28, Timothy Arceri wrote:
>>>>> On 13 November 2015 12:22:39 am AEDT, "Samuel Iglesias Gonsálvez" 
>>>>>  wrote:
>>>>>> 'shared' was added in ARB_uniform_buffer_object and also used
>>>>>> in ARB_shader_storage_buffer_object.
>>>>>
>>>>> Hi Samuel,
>>>>>
>>>>> Shared for UBO and SSBOs is not a key word its just an identifier for a 
>>>>> layout qualifier, are you sure you need to make it available for those 
>>>>> extensions?
>>>>>
>>>>
>>>> Right. Please ignore this patch.
>>>>
>>> In this case, may I suggest that you tag the patch as Rejected (or
>>> similar) in patchwork [1]. Afaict there are quite a few patches in
>>> there from yourself and fellow colleagues. Any chance someone can go
>>> through them and change their status appropriately ?
>>
>> Since I'm reading this from time to time I was wondering whether Mesa 
>> wouldn't
>> be better served by Phabricator instance? Maybe Matt and Tom, who send in 
>> most
>> of AMD's patches for the AMDGPU backend in LLVM can weigh in here?
>>
>> I'm using Phabricator myself for a big project and I must say it's really 
>> neat.
>> Most status/meta updates can happen automatically as you commit your changes,
>> the review state is tracked properly and if a patch was rejected/abandoned 
>> that
>> is usually also clear from the state. Ie. in most cases there is no need to 
>> have
>> multiple people walk through the same list of patches/bugs etc.
>>
>> (Bonus: for switching over from a Bugzilla to Phabricator, there's a pretty 
>> big
>> precedent with complete porting tools: Wikimedia did that)
>>
> Regardless of how clever the tool is there is always some user
> interaction needed. Damien have been working on improving patchwork
> and I believe it will be working pretty neatly in the not too distant
> future.

sure, there'll always be some level of interaction. My point was, that
Phabricator allows me in my experience with it, to reduce the amount of direct
interactions with it.

Example: if I put up a new revision for review, I can do so with a command line
tool I use instead of a git push to some feature branch and a git send-email to
the list. If code owners are defined, these can get added automatically by the
system as subscribers/reviewers (Herald rules can do that too). If a change has
been reviewed I land it with my command line tool which automatically marks the
review correctly. If somebody has requested to do something differently I can
reply to the comments inline and/or update the change for review. It all feels
pretty natural. (See
<https://secure.phabricator.com/book/phabricator/article/differential/> and
<https://secure.phabricator.com/book/phabricator/article/arcanist_diff/> for
some details on that workflow.)

> Personally I'm not too fussed what we use - although the general
> question on X vs Y is a po-tay-to po-tah-to like case. To each their
> own :) Although I'd suspect that we can/should have a discussion on
> next XDC on topics such as these ?

I'm most likely not going to be at any XDC in the foreseeable future, but a
discussion about tools would probably best suited for a personal meeting.

Anyway, if there is more interest in Phabricator or this discussion I'm happy to
answer your questions off list or in a different thread. I'll stop posting in
this thread, since it is off-topic (sorry for that). Especially since I'm not a
major contributor to Mesa.

Cheers,
Kai

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

Re: [Mesa-dev] [PATCH] util: move etc shared code to util library

2015-02-03 Thread Kai Wasserbäch

Dave Airlie wrote on 03.02.2015 05:48:
> From: Dave Airlie 
> 
> Like the RGTC code sharing this could be done nicer in the util lib.
> 
> This slighty increase i965_dri.so size by ~100 bytes,
> but it decreases the combined gallium driver by over 1k,
> and its just nicer to avoid TAG().
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/auxiliary/util/u_format_etc.c |  22 ++--
>  src/mesa/Makefile.sources |   1 -
>  src/mesa/main/texcompress_etc.c   |  32 +++---
>  src/mesa/main/texcompress_etc_tmp.h   | 170 
> --
>  src/util/Makefile.sources |   2 +
>  src/util/format_etc.c | 136 
>  src/util/format_etc.h |  78 ++
>  7 files changed, 237 insertions(+), 204 deletions(-)
>  delete mode 100644 src/mesa/main/texcompress_etc_tmp.h
>  create mode 100644 src/util/format_etc.c
>  create mode 100644 src/util/format_etc.h
> 
> [...]
> diff --git a/src/util/format_etc.c b/src/util/format_etc.c
> new file mode 100644
> index 000..5676bbf
> --- /dev/null
> +++ b/src/util/format_etc.c
> @@ -0,0 +1,136 @@
> +/*
> + [...]
> +
> +#include "format_etc.h"
> +#define MIN2( A, B )   ( (A)<(B) ? (A) : (B) )


Shouldn't macros.h be included instead of defining MIN2 again?



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

Re: [Mesa-dev] [PATCH 2/2 v2] add visibility hidden to tls entry points

2015-02-17 Thread Kai Wasserbäch

Marc Dietrich wrote on 17.02.2015 10:05:
> Avoid redefined symbol errors in clang. Based on a suggestion from
> Rafael Ãvila de EspÃndola  in

Whoever commits this, might want to fix Rafael's name in the commit message
before doing so. It should be: Rafael Ávila de Espíndola (according to the
referenced bug).



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

Re: [Mesa-dev] [PATCH 2/2 v2] add visibility hidden to tls entrypoints

2015-02-17 Thread Kai Wasserbäch

Marc Dietrich wrote on 17.02.2015 15:58:
> Am Dienstag, 17. Februar 2015, 15:51:38 schrieb Kai Wasserbäch:
>> Marc Dietrich wrote on 17.02.2015 10:05:
>>> Avoid redefined symbol errors in clang. Based on a suggestion from
>>> Rafael Ãvila de EspÃndola  in
>>
>> Whoever commits this, might want to fix Rafael's name in the commit message
>> before doing so. It should be: Rafael Ávila de Espíndola (according to the
>> referenced bug).
> 
> AFAICT, the commit is UTF-8 encoded. It looks ok in my terminal as well as in 
> my mailer. Hexdump also shows 0xC3 0x81 for "Á". Is this a problem?

Funny, for me the „í“ in „Espíndola“ as well as the „Á“ in „Ávila“ look broken
in your commit message. And if you check out
<http://lists.freedesktop.org/archives/mesa-dev/2015-February/077068.html> it
looks broken in the ML archives too. In the e-mail I'm replying to, looks fine
(except for the original quote, of course).

Anyway, nothing too serious, but since it happened to my name as well during a
commit, I thought I point it out.



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

Re: [Mesa-dev] [PATCH] osmesa: add gallium include dirs to Makefile.am

2015-02-23 Thread Kai Wasserbäch

Thanks Brian, this fixes the build for me. You can have my
 Tested-by: Kai Wasserbäch 
for this patch.


Brian Paul wrote on 23.02.2015 16:39:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89260
> ---
>  src/mesa/drivers/osmesa/Makefile.am | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/mesa/drivers/osmesa/Makefile.am 
> b/src/mesa/drivers/osmesa/Makefile.am
> index 589b5ee..60048cc 100644
> --- a/src/mesa/drivers/osmesa/Makefile.am
> +++ b/src/mesa/drivers/osmesa/Makefile.am
> @@ -26,6 +26,8 @@ EXTRA_DIST = osmesa.def SConscript
>  AM_CPPFLAGS = \
>   -I$(top_srcdir)/include \
>   -I$(top_srcdir)/src \
> + -I$(top_srcdir)/src/gallium/include \
> + -I$(top_srcdir)/src/gallium/auxiliary \
>   -I$(top_srcdir)/src/mapi \
>   -I$(top_builddir)/src/mapi \
>   -I$(top_srcdir)/src/mesa/ \
> 



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

Re: [Mesa-dev] [PATCH 3/3] radeonsi/compute: Enable PIPE_SHADER_CAP_DOUBLES

2015-02-27 Thread Kai Wasserbäch

Should GL_ARB_gpu_shader_fp64 be marked as done for radeonsi in GL3.txt then? Or
is PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED a must as well (I don't think so and
maybe PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED could be enabled as well?).

Cheers,
Kai


Tom Stellard wrote on 27.02.2015 02:06:
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 26182c2..c7a7622 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -360,8 +360,11 @@ static int si_get_shader_param(struct pipe_screen* 
> pscreen, unsigned shader, enu
>   return PIPE_SHADER_IR_NATIVE;
>  #endif
>   case PIPE_SHADER_CAP_DOUBLES:
> - return 0; /* XXX: Enable doubles once the compiler can
> -  handle them. */
> +#if HAVE_LLVM >= 0x0307
> + return 1;
> +#else
> + return 0;
> +#endif
>   case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE: {
>   uint64_t max_const_buffer_size;
>   pscreen->get_compute_param(pscreen,
> 

-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: ax_check_python_mako_module.m4 sets output variable

2015-03-03 Thread Kai Wasserbäch

Samuel Iglesias Gonsalvez wrote on 03.03.2015 08:56:
> This output variables gives more flexibility for future changes
> in autoconf to detect if it is needed to auto-generate files and
> check for the auto-generation dependencies.
> 
> It is still returning error when Python is not installed.
> 
> Signed-off-by: Samuel Iglesias Gonsalvez 
> ---
>  configure.ac  | 9 -
>  m4/ax_check_python_mako_module.m4 | 4 ++--
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 2ba79ef..ff7d6c9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -114,7 +114,14 @@ if test "x$INDENT" != "xcat"; then
>  fi
>  fi
>  
> -AX_CHECK_PYTHON_MAKO_MODULE(0.3.4)
> +PYTHON_MAKO_REQUIRED=0.3.4

Can you put that up into the section where all the other minimum versions are
defined? That would be more consistent.

Cheers,
Kai



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

Re: [Mesa-dev] [PATCH] configure: ax_check_python_mako_module.m4 sets output variable

2015-03-04 Thread Kai Wasserbäch

Samuel Iglesias Gonsálvez wrote on 04.03.2015 07:54:
> On Tue, 2015-03-03 at 16:50 +0100, Kai Wasserbäch wrote:
>> Samuel Iglesias Gonsalvez wrote on 03.03.2015 08:56:
>>> This output variables gives more flexibility for future changes
>>> in autoconf to detect if it is needed to auto-generate files and
>>> check for the auto-generation dependencies.
>>>
>>> It is still returning error when Python is not installed.
>>>
>>> Signed-off-by: Samuel Iglesias Gonsalvez 
>>> ---
>>>  configure.ac  | 9 -
>>>  m4/ax_check_python_mako_module.m4 | 4 ++--
>>>  2 files changed, 10 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 2ba79ef..ff7d6c9 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -114,7 +114,14 @@ if test "x$INDENT" != "xcat"; then
>>>  fi
>>>  fi
>>>  
>>> -AX_CHECK_PYTHON_MAKO_MODULE(0.3.4)
>>> +PYTHON_MAKO_REQUIRED=0.3.4
>>
>> Can you put that up into the section where all the other minimum versions are
>> defined? That would be more consistent.
>>
> 
> Yeah, I'll do it. Has this patch your R-b with this change?

Sure:
  Reviewed-by: Kai Wasserbäch 

Bonus nit: can we change the subject to something like:
 configure: Introduce new output variable to ax_check_python_mako_module.m4

Cheers,
Kai



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

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

2017-02-11 Thread 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 2/2] vdpau: skip vlVdpOutputSurfacePutBitsNative with a zero-area rectangle

2017-02-12 Thread 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] radv cik fixes

2017-02-14 Thread 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] vulkan/wsi: Improve the DRI3 error message

2017-02-18 Thread 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] [PATCH] vulkan/wsi: Improve the DRI3 error message

2017-02-18 Thread 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

2017-02-19 Thread 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

2017-02-26 Thread 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 01/18] gallium/util: clear up that debug_get_flags_option returns a 64-bit mask

2015-07-28 Thread Kai Wasserbäch

Marek Olšák wrote on 28.07.2015 12:05:
> From: Marek Olšák 
> 
> ---
>  src/gallium/auxiliary/util/u_debug.c | 8 
>  src/gallium/auxiliary/util/u_debug.h | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_debug.c 
> b/src/gallium/auxiliary/util/u_debug.c
> index cf6eca7..b4503de 100644
> --- a/src/gallium/auxiliary/util/u_debug.c
> +++ b/src/gallium/auxiliary/util/u_debug.c
> @@ -256,12 +256,12 @@ static boolean str_has_option(const char *str, const 
> char *name)
> return FALSE;
>  }
>  
> -unsigned long
> +uint64_t
>  debug_get_flags_option(const char *name, 
> const struct debug_named_value *flags,
> -   unsigned long dfault)
> +   uint64_t dfault)

Since you already touch this, maybe fix the typo as well? (s/dfault/default/)

>  {
> -   unsigned long result;
> +   uint64_t result;
> const char *str;
> const struct debug_named_value *orig = flags;
> unsigned namealign = 0;
> @@ -276,7 +276,7 @@ debug_get_flags_option(const char *name,
>   namealign = MAX2(namealign, strlen(flags->name));
>for (flags = orig; flags->name; ++flags)
>   _debug_printf("| %*s [0x%0*lx]%s%s\n", namealign, flags->name,
> -  (int)sizeof(unsigned long)*CHAR_BIT/4, flags->value,
> +  (int)sizeof(uint64_t)*CHAR_BIT/4, flags->value,
>flags->desc ? " " : "", flags->desc ? flags->desc : 
> "");
> }
> else {
> diff --git a/src/gallium/auxiliary/util/u_debug.h 
> b/src/gallium/auxiliary/util/u_debug.h
> index b4286d3..926063a 100644
> --- a/src/gallium/auxiliary/util/u_debug.h
> +++ b/src/gallium/auxiliary/util/u_debug.h
> @@ -269,7 +269,7 @@ void _debug_assert_fail(const char *expr,
>  struct debug_named_value
>  {
> const char *name;
> -   unsigned long value;
> +   uint64_t value;
> const char *desc;
>  };
>  
> @@ -377,10 +377,10 @@ debug_get_bool_option(const char *name, boolean dfault);
>  long
>  debug_get_num_option(const char *name, long dfault);
>  
> -unsigned long
> +uint64_t
>  debug_get_flags_option(const char *name, 
> const struct debug_named_value *flags,
> -   unsigned long dfault);
> +   uint64_t dfault);
>  
>  #define DEBUG_GET_ONCE_BOOL_OPTION(sufix, name, dfault) \
>  static boolean \

The receiving variables in the callers should probably be fixed up as well,
right? Most of them seem to be unsigned long or just unsigned. (E.g. in
debug_flags in r600_common_screen is an unsigned)
But maybe that can be ignored?

Though somebody with deeper knowledge of the code should give you a R-b, you can
have mine, for what it is worth, with the callers fixed:
Reviewed-by: Kai Wasserbäch 

Cheers,
Kai



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

Re: [Mesa-dev] [PATCH 01/18] gallium/util: clear up that debug_get_flags_option returns a 64-bit mask

2015-07-28 Thread Kai Wasserbäch

Brian Paul wrote on 28.07.2015 18:40:
> On 07/28/2015 10:35 AM, Kai Wasserbäch wrote:
>> Marek Olšák wrote on 28.07.2015 12:05:
>>> From: Marek Olšák 
>>>
>>> ---
>>>   src/gallium/auxiliary/util/u_debug.c | 8 
>>>   src/gallium/auxiliary/util/u_debug.h | 6 +++---
>>>   2 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/src/gallium/auxiliary/util/u_debug.c
>>> b/src/gallium/auxiliary/util/u_debug.c
>>> index cf6eca7..b4503de 100644
>>> --- a/src/gallium/auxiliary/util/u_debug.c
>>> +++ b/src/gallium/auxiliary/util/u_debug.c
>>> @@ -256,12 +256,12 @@ static boolean str_has_option(const char *str, const
>>> char *name)
>>>  return FALSE;
>>>   }
>>>
>>> -unsigned long
>>> +uint64_t
>>>   debug_get_flags_option(const char *name,
>>>  const struct debug_named_value *flags,
>>> -   unsigned long dfault)
>>> +   uint64_t dfault)
>>
>> Since you already touch this, maybe fix the typo as well? (s/dfault/default/)
> 
> Can't.  'default' is a C reserved word. :)
> 
> In other places you'll see 'templat' instead of 'template' for similar reasons
> with C++.

Ahrg, yes. Totally went for the "typo". Not the first time I stumbled over one
of these. Sorry for the noise.



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

Re: [Mesa-dev] [PATCH 01/18] gallium/util: clear up that debug_get_flags_option returns a 64-bit mask

2015-07-29 Thread Kai Wasserbäch

Marek Olšák wrote on 28.07.2015 21:42:
> On Tue, Jul 28, 2015 at 6:35 PM, Kai Wasserbäch
>  wrote:
>> Marek Olšák wrote on 28.07.2015 12:05:
>>> From: Marek Olšák 
>>>
>>> ---
>>>  src/gallium/auxiliary/util/u_debug.c | 8 
>>>  src/gallium/auxiliary/util/u_debug.h | 6 +++---
>>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> The receiving variables in the callers should probably be fixed up as well,
>> right? Most of them seem to be unsigned long or just unsigned. (E.g. in
>> debug_flags in r600_common_screen is an unsigned)
>> But maybe that can be ignored?
>>
>> Though somebody with deeper knowledge of the code should give you a R-b, you 
>> can
>> have mine, for what it is worth, with the callers fixed:
>> Reviewed-by: Kai Wasserbäch 
> 
> The type of r600_common_screen::debug_flags is changed by a later patch.
> 
> I don't think the callers need updating if they don't use the higher
> bits. The behavior remains the same. For radeon, the first patch using
> the higher bits updates the type as well.

Ok, I would have done it in this patch. Anyway, after your explanation your
patch seems fine as is.

Cheers,
Kai



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

[Mesa-dev] [PATCH] docs: trivial cleanup of GL3.txt, remove redundant radeonsi entries.

2015-07-30 Thread Kai Wasserbäch

Follow-up to 1b2b0e42ce47bfd1fcb5513ed2c23b9bb7a5a5b8

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

Please commit this for me, if this is accepted. Thanks.

 docs/GL3.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 0220f24..8124383 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -96,7 +96,7 @@ GL 4.0, GLSL 4.00 --- all DONE: nvc0, radeonsi
 
   GL_ARB_draw_buffers_blendDONE (i965, nv50, r600, 
llvmpipe, softpipe)
   GL_ARB_draw_indirect DONE (i965, r600, 
llvmpipe, softpipe)
-  GL_ARB_gpu_shader5   DONE (i965, radeonsi)
+  GL_ARB_gpu_shader5   DONE (i965)
   - 'precise' qualifierDONE
   - Dynamically uniform sampler array indices  DONE (r600, softpipe)
   - Dynamically uniform UBO array indices  DONE (r600)
@@ -110,7 +110,7 @@ GL 4.0, GLSL 4.00 --- all DONE: nvc0, radeonsi
   - Interpolation functionsDONE (r600)
   - New overload resolution rules  DONE
   GL_ARB_gpu_shader_fp64   DONE (llvmpipe, 
softpipe)
-  GL_ARB_sample_shadingDONE (i965, nv50, r600, 
radeonsi)
+  GL_ARB_sample_shadingDONE (i965, nv50, r600)
   GL_ARB_shader_subroutine DONE (i965, nv50, r600, 
llvmpipe, softpipe)
   GL_ARB_tessellation_shader   DONE ()
   GL_ARB_texture_buffer_object_rgb32   DONE (i965, r600, 
llvmpipe, softpipe)
-- 
2.4.6

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

[Mesa-dev] [PATCH] glsl: check if return_deref in lower_subroutine_visitor::visit_leave isn't NULL

2015-08-14 Thread Kai Wasserbäch

Fixes a crash in Piglit's
spec@arb_shader_subroutine@lin...@no-mutual-recursion.vert for me.

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

Hey everyone,
I ran the Piglit quick test suite afterwards and haven't observed any
regressions over my previous quick run, but the crash went away. The test
itself passes now! Instead of

| Program received signal SIGSEGV, Segmentation fault.
| (anonymous namespace)::lower_subroutine_visitor::visit_leave 
(this=0x7fffdab0, ir=0xb1af58) at 
../../../../src/glsl/lower_subroutine.cpp:102

I'm seeing the (expected)

| Failed to link: error: function `void impl_b(int)' has static recursion.
| error: function `void impl_a(int)' has static recursion.
|
| Failed to link vertex shader 
/tests/spec/arb_shader_subroutine/linker/no-mutual-recursion.vert:
 
| PIGLIT: {"result": "pass" }

The builds used in both runs have been done in a clean pbuilder chroot (the
same for both builds). Ie. there weren't any other differences between the two
Piglit runs besides the addition of the patch in the latest Mesa build.

If you accept this patch, please commit it for me, as I don't have commit
access.

Thanks,
Kai


 src/glsl/lower_subroutine.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/lower_subroutine.cpp b/src/glsl/lower_subroutine.cpp
index b29912a..c1aed61 100644
--- a/src/glsl/lower_subroutine.cpp
+++ b/src/glsl/lower_subroutine.cpp
@@ -98,7 +98,7 @@ lower_subroutine_visitor::visit_leave(ir_call *ir)
   else
  last_branch = if_tree(equal(subr_to_int(var), lc), new_call, 
last_branch);
 
-  if (s > 0)
+  if (return_deref && s > 0)
 return_deref = return_deref->clone(mem_ctx, NULL);
}
if (last_branch)
-- 
2.5.0

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

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

2016-09-13 Thread 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] mesamatrix.net summary problem

2016-10-08 Thread 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] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

2016-10-13 Thread 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] [PATCH 2/2] radv: Use new image load/store intrinsic signatures

2016-10-13 Thread 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

[Mesa-dev] [PATCH 2/2] st/va: Remove unused variable coded_size from vlVaEndPicture()

2016-08-20 Thread Kai Wasserbäch

Removes the following GCC warning:
 ../../../../../src/gallium/state_trackers/va/picture.c:542:17: warning:
  unused variable 'coded_size' [-Wunused-variable]
unsigned int coded_size;
 ^~

Signed-off-by: Kai Wasserbäch 
---
 src/gallium/state_trackers/va/picture.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index bbb5595..a283e83 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -539,7 +539,6 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
vlVaContext *context;
vlVaBuffer *coded_buf;
vlVaSurface *surf;
-   unsigned int coded_size;
void *feedback;
 
if (!ctx)
-- 
2.8.1

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

[Mesa-dev] [PATCH 0/2] st/va: minor clean-ups

2016-08-20 Thread Kai Wasserbäch

Hey,
just noticed a duplicate call to context->decoder->end_frame() while looking
through the recent changes. This is just a trivial clean-up and no functional
change is intended. And while I was there, I also noticed an unused variable,
which the second patch removes.

Cheers,
Kai

P.S.: If this "series" gets accepted, please commit it for me, since I do not
have commit access.


Kai Wasserbäch (3):
  st/va: Remove else case in vlVaEndPicture() made superfluous by
c59628d11b
  st/va: Remove unused variable coded_size from vlVaEndPicture()

 src/gallium/state_trackers/va/picture.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

-- 
2.8.1

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

[Mesa-dev] [PATCH 1/2] st/va: Remove else case in vlVaEndPicture() made superfluous by c59628d11b

2016-08-20 Thread Kai Wasserbäch

Commit c59628d11b134fc016388a170880f7646e100d6f made the else statement
and duplication of the context->decoder->end_frame() call superfluous.

Cc: Boyuan Zhang 
Signed-off-by: Kai Wasserbäch 
---
 src/gallium/state_trackers/va/picture.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 87567be..bbb5595 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -576,11 +576,9 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
context_id)
   surf->frame_num_cnt = context->desc.h264enc.frame_num_cnt;
   surf->feedback = feedback;
   surf->coded_buf = coded_buf;
-  context->decoder->end_frame(context->decoder, context->target, 
&context->desc.base);
}
-   else
-  context->decoder->end_frame(context->decoder, context->target, 
&context->desc.base);
 
+   context->decoder->end_frame(context->decoder, context->target, 
&context->desc.base);
pipe_mutex_unlock(drv->mutex);
return VA_STATUS_SUCCESS;
 }
-- 
2.8.1

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

Re: [Mesa-dev] [PATCH 0/2] st/va: minor clean-ups

2016-08-23 Thread Kai Wasserbäch

Hey Boyuan, hey Christian,
Zhang, Boyuan wrote on 22.08.2016 22:52:
> Thanks for cleaning up the codes. The duplicated end_frame and unused 
> variable are due to the new patch submitted last Friday. I have reviewed both 
> patches.

thanks for your reviews! Just in case you missed my postscript in the cover
letter: either of you needs to commit these changes since I do not have commit
access.

Thanks again,
Kai


> -Original Message-----
> From: Kai Wasserbäch [mailto:k...@dev.carbon-project.org] 
> Sent: August-20-16 12:15 PM
> To: mesa-dev@lists.freedesktop.org
> Cc: Zhang, Boyuan
> Subject: [PATCH 0/2] st/va: minor clean-ups
> 
> Hey,
> just noticed a duplicate call to context->decoder->end_frame() while looking 
> through the recent changes. This is just a trivial clean-up and no functional 
> change is intended. And while I was there, I also noticed an unused variable, 
> which the second patch removes.
> 
> Cheers,
> Kai
> 
> P.S.: If this "series" gets accepted, please commit it for me, since I do not 
> have commit access.
> 
> 
> Kai Wasserbäch (3):
>   st/va: Remove else case in vlVaEndPicture() made superfluous by
> c59628d11b
>   st/va: Remove unused variable coded_size from vlVaEndPicture()
> 
>  src/gallium/state_trackers/va/picture.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 



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] radeonsi: add support for cull distances.

2016-08-23 Thread Kai Wasserbäch

Hey Dave,
Dave Airlie wrote on 23.08.2016 03:28:
> From: Dave Airlie 
> 
> This should be all that is required for cull distances to work
> on radeonsi.

in case this is indeed enough to enable ARB_cull_distance, mind adding that to
GL3.txt and the release notes?

> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c  | 3 ++-
>  src/gallium/drivers/radeonsi/si_state.c | 8 
>  2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 62b62db..14b0b80 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -436,7 +436,6 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
> pipe_cap param)
>   case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
>   case PIPE_CAP_VERTEXID_NOBASE:
>   case PIPE_CAP_QUERY_BUFFER_OBJECT:
> - case PIPE_CAP_CULL_DISTANCE:
>   case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
>   case PIPE_CAP_TGSI_VOTE:
>   case PIPE_CAP_MAX_WINDOW_RECTANGLES:
> @@ -447,6 +446,8 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
> pipe_cap param)
>   case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
>   return sscreen->has_draw_indirect_multi;
>  
> + case PIPE_CAP_CULL_DISTANCE:
> + return 1;
>   case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
>   return 30;

Hm, shouldn't the PIPE_CAP_CULL_DISTANCE just be moved up to the long list of
supported features with boolean caps at the beginning of si_get_param()?
(Instead of creating another "true segment"?)

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] gallium: Use enum pipe_shader_type in bind_sampler_states()

2016-08-26 Thread Kai Wasserbäch

Cc: Brian Paul 
Signed-off-by: Kai Wasserbäch 
---

Hi Brian,
is this what you had in mind? If so, I was wondering whether virgl_encode.c
would need to be updated as well. Doesn't seem like it, since the functions
there map everything to uint32_t or some other standard type.

Another point are the switch statements nouveau uses. To silence the -Wswitch
warning of GCC I stuck a default case with two asserts at the end of them. But
maybe it would be better to use an if...else for nv30 and nv50.

Cheers,
Kai

P.S.: If this is the right direction, I can do the remaining stuff as well.
P.P.S.: If this patch is accepted, please commit it for me, as I do not have
commit access.


 src/gallium/auxiliary/cso_cache/cso_context.c |  7 ---
 src/gallium/auxiliary/cso_cache/cso_context.h |  5 +++--
 src/gallium/auxiliary/draw/draw_pipe_aaline.c |  9 ++---
 src/gallium/auxiliary/draw/draw_pipe_pstipple.c   |  7 ---
 src/gallium/drivers/ddebug/dd_context.c   |  3 ++-
 src/gallium/drivers/freedreno/a2xx/fd2_texture.c  |  2 +-
 src/gallium/drivers/freedreno/a3xx/fd3_texture.c  |  2 +-
 src/gallium/drivers/freedreno/a4xx/fd4_texture.c  |  2 +-
 src/gallium/drivers/freedreno/freedreno_texture.c |  2 +-
 src/gallium/drivers/i915/i915_state.c |  3 ++-
 src/gallium/drivers/ilo/ilo_state.c   |  3 ++-
 src/gallium/drivers/llvmpipe/lp_state_sampler.c   |  2 +-
 src/gallium/drivers/noop/noop_state.c |  3 ++-
 src/gallium/drivers/nouveau/nv30/nv30_texture.c   |  6 +-
 src/gallium/drivers/nouveau/nv50/nv50_state.c |  6 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 12 +---
 src/gallium/drivers/r300/r300_state.c |  2 +-
 src/gallium/drivers/r600/r600_state_common.c  |  2 +-
 src/gallium/drivers/radeonsi/si_descriptors.c |  3 ++-
 src/gallium/drivers/rbug/rbug_context.c   |  3 ++-
 src/gallium/drivers/softpipe/sp_state_sampler.c   |  2 +-
 src/gallium/drivers/svga/svga_pipe_sampler.c  |  2 +-
 src/gallium/drivers/swr/swr_state.cpp |  2 +-
 src/gallium/drivers/trace/tr_context.c|  2 +-
 src/gallium/drivers/vc4/vc4_state.c   |  2 +-
 src/gallium/drivers/virgl/virgl_context.c |  3 ++-
 src/gallium/include/pipe/p_context.h  |  5 +++--
 src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
 28 files changed, 66 insertions(+), 38 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 4a54cff..6ffcce4 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -316,7 +316,7 @@ void cso_destroy_context( struct cso_context *ctx )
  static struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS] 
= { NULL };
  static void *zeros[PIPE_MAX_SAMPLERS] = { NULL };
  struct pipe_screen *scr = ctx->pipe->screen;
- unsigned sh;
+ enum pipe_shader_type sh;
  for (sh = 0; sh < PIPE_SHADER_TYPES; sh++) {
 int maxsam = scr->get_shader_param(scr, sh,

PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
@@ -1207,7 +1207,8 @@ cso_single_sampler(struct cso_context *ctx, unsigned 
shader_stage,
  * Send staged sampler state to the driver.
  */
 void
-cso_single_sampler_done(struct cso_context *ctx, unsigned shader_stage)
+cso_single_sampler_done(struct cso_context *ctx,
+enum pipe_shader_type shader_stage)
 {
struct sampler_info *info = &ctx->samplers[shader_stage];
const unsigned old_nr_samplers = info->nr_samplers;
@@ -1233,7 +1234,7 @@ cso_single_sampler_done(struct cso_context *ctx, unsigned 
shader_stage)
  */
 enum pipe_error
 cso_set_samplers(struct cso_context *ctx,
- unsigned shader_stage,
+ enum pipe_shader_type shader_stage,
  unsigned nr,
  const struct pipe_sampler_state **templates)
 {
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
b/src/gallium/auxiliary/cso_cache/cso_context.h
index a4309c7..5c9cb5a 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -60,7 +60,7 @@ enum pipe_error cso_set_rasterizer( struct cso_context *cso,
 
 enum pipe_error
 cso_set_samplers(struct cso_context *cso,
- unsigned shader_stage,
+ enum pipe_shader_type shader_stage,
  unsigned count,
  const struct pipe_sampler_state **states);
 
@@ -73,7 +73,8 @@ cso_single_sampler(struct cso_context *cso, unsigned 
shader_stage,
unsigned idx, const struct pipe_sampler_state *states);
 
 void
-cso_single_sampler_done(struct cso_context *cso, unsigned shader_stage);
+cso_single_sampler_done(struct cso_context *cso,
+enum pipe_shader_type shader_stage);
 
 
 enum pipe_er

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

2016-08-26 Thread Kai Wasserbäch

Hey Brian,
Brian Paul wrote on 26.08.2016 14:50:
> On 08/26/2016 05:58 AM, Kai Wasserbäch wrote:
>> Cc: Brian Paul 
>> Signed-off-by: Kai Wasserbäch 
>> ---
>>
>> Hi Brian,
>> is this what you had in mind? If so, I was wondering whether virgl_encode.c
>> would need to be updated as well. Doesn't seem like it, since the functions
>> there map everything to uint32_t or some other standard type.
>>
>> Another point are the switch statements nouveau uses. To silence the -Wswitch
>> warning of GCC I stuck a default case with two asserts at the end of them. 
>> But
>> maybe it would be better to use an if...else for nv30 and nv50.
> 
> I think one assertion is enough.  It's up to the nouveau developers whether 
> they
> want to do more.

ok, then I'll go for the generic "unhandled type" assert.

>> Cheers,
>> Kai
>>
>> P.S.: If this is the right direction, I can do the remaining stuff as well.
> 
> I think there was another person interested so feel free to share the task.

Eric, I'm sorry I didn't see your message before I had prepared this patch and
sent it. If I should leave the rest alone, just give me a shout. Would be
unfortunate if we did the same task twice.

> BTW, looks like pipe_screen::get_compiler_options() has another unsigned -->
> enum candidate.
> 
> 
>> P.P.S.: If this patch is accepted, please commit it for me, as I do not have
>> commit access.
> 
> Looks good.  Just a few minor comments below.

v2 will arrive shortly.

Thanks for the review,
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] gallium: Use enum pipe_shader_type in bind_sampler_states() (v2)

2016-08-26 Thread Kai Wasserbäch

v1 → v2:
 - Fixed indentation (noted by Brian Paul)
 - Removed second assert from nouveau's switch statements (suggested by
   Brian Paul)

Signed-off-by: Kai Wasserbäch 
---
 src/gallium/auxiliary/cso_cache/cso_context.c |  7 ---
 src/gallium/auxiliary/cso_cache/cso_context.h |  5 +++--
 src/gallium/auxiliary/draw/draw_pipe_aaline.c |  9 ++---
 src/gallium/auxiliary/draw/draw_pipe_pstipple.c   |  7 ---
 src/gallium/drivers/ddebug/dd_context.c   |  3 ++-
 src/gallium/drivers/freedreno/a2xx/fd2_texture.c  |  2 +-
 src/gallium/drivers/freedreno/a3xx/fd3_texture.c  |  2 +-
 src/gallium/drivers/freedreno/a4xx/fd4_texture.c  |  2 +-
 src/gallium/drivers/freedreno/freedreno_texture.c |  2 +-
 src/gallium/drivers/i915/i915_state.c |  3 ++-
 src/gallium/drivers/ilo/ilo_state.c   |  3 ++-
 src/gallium/drivers/llvmpipe/lp_state_sampler.c   |  2 +-
 src/gallium/drivers/noop/noop_state.c |  3 ++-
 src/gallium/drivers/nouveau/nv30/nv30_texture.c   |  5 -
 src/gallium/drivers/nouveau/nv50/nv50_state.c |  5 -
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 11 ---
 src/gallium/drivers/r300/r300_state.c |  2 +-
 src/gallium/drivers/r600/r600_state_common.c  |  2 +-
 src/gallium/drivers/radeonsi/si_descriptors.c |  3 ++-
 src/gallium/drivers/rbug/rbug_context.c   |  3 ++-
 src/gallium/drivers/softpipe/sp_state_sampler.c   |  2 +-
 src/gallium/drivers/svga/svga_pipe_sampler.c  |  2 +-
 src/gallium/drivers/swr/swr_state.cpp |  2 +-
 src/gallium/drivers/trace/tr_context.c|  2 +-
 src/gallium/drivers/vc4/vc4_state.c   |  2 +-
 src/gallium/drivers/virgl/virgl_context.c |  3 ++-
 src/gallium/include/pipe/p_context.h  |  5 +++--
 src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
 28 files changed, 63 insertions(+), 38 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 4a54cff..6ffcce4 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -316,7 +316,7 @@ void cso_destroy_context( struct cso_context *ctx )
  static struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS] 
= { NULL };
  static void *zeros[PIPE_MAX_SAMPLERS] = { NULL };
  struct pipe_screen *scr = ctx->pipe->screen;
- unsigned sh;
+ enum pipe_shader_type sh;
  for (sh = 0; sh < PIPE_SHADER_TYPES; sh++) {
 int maxsam = scr->get_shader_param(scr, sh,

PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
@@ -1207,7 +1207,8 @@ cso_single_sampler(struct cso_context *ctx, unsigned 
shader_stage,
  * Send staged sampler state to the driver.
  */
 void
-cso_single_sampler_done(struct cso_context *ctx, unsigned shader_stage)
+cso_single_sampler_done(struct cso_context *ctx,
+enum pipe_shader_type shader_stage)
 {
struct sampler_info *info = &ctx->samplers[shader_stage];
const unsigned old_nr_samplers = info->nr_samplers;
@@ -1233,7 +1234,7 @@ cso_single_sampler_done(struct cso_context *ctx, unsigned 
shader_stage)
  */
 enum pipe_error
 cso_set_samplers(struct cso_context *ctx,
- unsigned shader_stage,
+ enum pipe_shader_type shader_stage,
  unsigned nr,
  const struct pipe_sampler_state **templates)
 {
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
b/src/gallium/auxiliary/cso_cache/cso_context.h
index a4309c7..5c9cb5a 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -60,7 +60,7 @@ enum pipe_error cso_set_rasterizer( struct cso_context *cso,
 
 enum pipe_error
 cso_set_samplers(struct cso_context *cso,
- unsigned shader_stage,
+ enum pipe_shader_type shader_stage,
  unsigned count,
  const struct pipe_sampler_state **states);
 
@@ -73,7 +73,8 @@ cso_single_sampler(struct cso_context *cso, unsigned 
shader_stage,
unsigned idx, const struct pipe_sampler_state *states);
 
 void
-cso_single_sampler_done(struct cso_context *cso, unsigned shader_stage);
+cso_single_sampler_done(struct cso_context *cso,
+enum pipe_shader_type shader_stage);
 
 
 enum pipe_error cso_set_vertex_elements(struct cso_context *ctx,
diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index a5f0723..1ea77da 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -118,10 +118,12 @@ struct aaline_stage
void (*driver_bind_fs_state)(struct pipe_context *, void *);
void (*driver_delete_fs_state)(struct pipe_context *, void *);
 
-   void (*driver_bind_sampler_

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

2016-08-26 Thread Kai Wasserbäch

Hey Samuel,
Samuel Pitoiset wrote on 26.08.2016 15:54:
> On 08/26/2016 01:58 PM, Kai Wasserbäch wrote:
>> [...]
>> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_texture.c
>> b/src/gallium/drivers/nouveau/nv30/nv30_texture.c
>> index 4f4f87e..dc1a476 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,10 @@ nv30_bind_sampler_states(struct pipe_context *pipe,
>> case PIPE_SHADER_FRAGMENT:
>>nv30_fragtex_sampler_states_bind(pipe, num_samplers, samplers);
>>break;
>> +   default:
>> +  assert(shader <= PIPE_SHADER_TYPES);
>> +  assert(!"invalid/unhandled type");
> 
> assert(!"invalid PIPE_SHADER type"); is enough here.
> Please apply the same change for nv50 and nvc0 as well.

Is v2 – with a slightly different assert message – ok 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] gallium: Use enum pipe_shader_type in bind_sampler_states()

2016-08-26 Thread Kai Wasserbäch

Hey Eric,
Eric Engestrom wrote on 26.08.2016 15:49:
> On Fri, Aug 26, 2016 at 03:14:57PM +0200, Kai Wasserbäch wrote:
>> Brian Paul wrote on 26.08.2016 14:50:
>>> On 08/26/2016 05:58 AM, Kai Wasserbäch wrote:
>>>> Cc: Brian Paul 
>>>> Signed-off-by: Kai Wasserbäch 
>>>> ---
>>>>
>>>> Hi Brian,
>>>> is this what you had in mind? If so, I was wondering whether virgl_encode.c
>>>> would need to be updated as well. Doesn't seem like it, since the functions
>>>> there map everything to uint32_t or some other standard type.
>>>>
>>>> Another point are the switch statements nouveau uses. To silence the 
>>>> -Wswitch
>>>> warning of GCC I stuck a default case with two asserts at the end of them. 
>>>> But
>>>> maybe it would be better to use an if...else for nv30 and nv50.
>>>
>>> I think one assertion is enough.  It's up to the nouveau developers whether 
>>> they
>>> want to do more.
>>
>> ok, then I'll go for the generic "unhandled type" assert.
> 
> I would've gone with `unreachable()`, since nothing outside the
> enum range should ever get in.

Do you feel strongly about that and require a v3? Personally I think the
assert() is better since the function could be called with another enum member
value, which still is unhandled by the switch().

>>>> Cheers,
>>>> Kai
>>>>
>>>> P.S.: If this is the right direction, I can do the remaining stuff as well.
>>>
>>> I think there was another person interested so feel free to share the task.
>>
>> Eric, I'm sorry I didn't see your message before I had prepared this patch 
>> and
>> sent it. If I should leave the rest alone, just give me a shout. Would be
>> unfortunate if we did the same task twice.
> 
> No worries, I also saw your message after having sent my reply on
> Brian's comment, so I'm no better xD
> 
> I also have other ideas of things I could do, so I'll leave this
> "int to enum" task to you :)

Ok, I'll prepare the other patches as well. (I'll probably sent them out 
tomorrow.)

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 4/4] gallium: Use enum pipe_shader_type in set_shader_images()

2016-08-27 Thread Kai Wasserbäch

Signed-off-by: Kai Wasserbäch 
---
 src/gallium/auxiliary/cso_cache/cso_context.c | 3 ++-
 src/gallium/auxiliary/cso_cache/cso_context.h | 3 ++-
 src/gallium/drivers/ddebug/dd_context.c   | 3 ++-
 src/gallium/drivers/ilo/ilo_state.c   | 2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 3 ++-
 src/gallium/drivers/radeonsi/si_descriptors.c | 3 ++-
 src/gallium/drivers/softpipe/sp_state_image.c | 2 +-
 src/gallium/drivers/trace/tr_context.c| 2 +-
 src/gallium/include/pipe/p_context.h  | 3 ++-
 src/mesa/state_tracker/st_atom_image.c| 2 +-
 10 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 5e6b36e..127e071 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -1360,7 +1360,8 @@ cso_restore_fragment_sampler_views(struct cso_context 
*ctx)
 
 
 void
-cso_set_shader_images(struct cso_context *ctx, unsigned shader_stage,
+cso_set_shader_images(struct cso_context *ctx,
+  enum pipe_shader_type shader_stage,
   unsigned start, unsigned count,
   struct pipe_image_view *images)
 {
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
b/src/gallium/auxiliary/cso_cache/cso_context.h
index 27863f4..29e5e33 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -196,7 +196,8 @@ cso_set_sampler_views(struct cso_context *cso,
 /* shader images */
 
 void
-cso_set_shader_images(struct cso_context *cso, unsigned shader_stage,
+cso_set_shader_images(struct cso_context *cso,
+  enum pipe_shader_type shader_stage,
   unsigned start, unsigned count,
   struct pipe_image_view *views);
 
diff --git a/src/gallium/drivers/ddebug/dd_context.c 
b/src/gallium/drivers/ddebug/dd_context.c
index 50edfd7..4bcbbff 100644
--- a/src/gallium/drivers/ddebug/dd_context.c
+++ b/src/gallium/drivers/ddebug/dd_context.c
@@ -521,7 +521,8 @@ dd_context_set_sampler_views(struct pipe_context *_pipe,
 }
 
 static void
-dd_context_set_shader_images(struct pipe_context *_pipe, unsigned shader,
+dd_context_set_shader_images(struct pipe_context *_pipe,
+ enum pipe_shader_type shader,
  unsigned start, unsigned num,
  const struct pipe_image_view *views)
 {
diff --git a/src/gallium/drivers/ilo/ilo_state.c 
b/src/gallium/drivers/ilo/ilo_state.c
index 0ae32c7..95b292a 100644
--- a/src/gallium/drivers/ilo/ilo_state.c
+++ b/src/gallium/drivers/ilo/ilo_state.c
@@ -1853,7 +1853,7 @@ ilo_set_sampler_views(struct pipe_context *pipe, enum 
pipe_shader_type shader,
 }
 
 static void
-ilo_set_shader_images(struct pipe_context *pipe, unsigned shader,
+ilo_set_shader_images(struct pipe_context *pipe, enum pipe_shader_type shader,
   unsigned start, unsigned count,
   const struct pipe_image_view *views)
 {
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
index ee1e184..6aaada4 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
@@ -1344,7 +1344,8 @@ nvc0_bind_images_range(struct nvc0_context *nvc0, const 
unsigned s,
 }
 
 static void
-nvc0_set_shader_images(struct pipe_context *pipe, unsigned shader,
+nvc0_set_shader_images(struct pipe_context *pipe,
+   enum pipe_shader_type shader,
unsigned start, unsigned nr,
const struct pipe_image_view *images)
 {
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index dfd0607..eb0e5fa 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -704,7 +704,8 @@ static void si_set_shader_image(struct si_context *ctx,
 }
 
 static void
-si_set_shader_images(struct pipe_context *pipe, unsigned shader,
+si_set_shader_images(struct pipe_context *pipe,
+enum pipe_shader_type shader,
 unsigned start_slot, unsigned count,
 const struct pipe_image_view *views)
 {
diff --git a/src/gallium/drivers/softpipe/sp_state_image.c 
b/src/gallium/drivers/softpipe/sp_state_image.c
index c5ef466..38e5cd4 100644
--- a/src/gallium/drivers/softpipe/sp_state_image.c
+++ b/src/gallium/drivers/softpipe/sp_state_image.c
@@ -27,7 +27,7 @@
 #include "sp_buffer.h"
 
 static void softpipe_set_shader_images(struct pipe_context *pipe,
-   unsigned shader,
+   enum pipe_shader_type shader,
unsigned start,
un

[Mesa-dev] [PATCH 2/4] gallium: Use enum pipe_shader_type in set_sampler_views()

2016-08-27 Thread Kai Wasserbäch

Signed-off-by: Kai Wasserbäch 
---
 src/gallium/auxiliary/cso_cache/cso_context.c | 2 +-
 src/gallium/auxiliary/cso_cache/cso_context.h | 2 +-
 src/gallium/auxiliary/draw/draw_context.c | 4 ++--
 src/gallium/auxiliary/draw/draw_context.h | 4 ++--
 src/gallium/auxiliary/draw/draw_pipe_aaline.c | 3 ++-
 src/gallium/auxiliary/draw/draw_pipe_pstipple.c   | 9 +
 src/gallium/drivers/ddebug/dd_context.c   | 3 ++-
 src/gallium/drivers/freedreno/a4xx/fd4_texture.c  | 2 +-
 src/gallium/drivers/freedreno/freedreno_texture.c | 2 +-
 src/gallium/drivers/freedreno/freedreno_texture.h | 3 ++-
 src/gallium/drivers/i915/i915_state.c | 2 +-
 src/gallium/drivers/ilo/ilo_state.c   | 5 -
 src/gallium/drivers/llvmpipe/lp_state_sampler.c   | 2 +-
 src/gallium/drivers/noop/noop_state.c | 3 ++-
 src/gallium/drivers/nouveau/nv30/nv30_fragtex.c   | 2 +-
 src/gallium/drivers/nouveau/nv50/nv50_state.c | 2 +-
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 2 +-
 src/gallium/drivers/r300/r300_state.c | 3 ++-
 src/gallium/drivers/r600/r600_state_common.c  | 3 ++-
 src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
 src/gallium/drivers/rbug/rbug_context.c   | 2 +-
 src/gallium/drivers/softpipe/sp_state.h   | 2 +-
 src/gallium/drivers/softpipe/sp_state_sampler.c   | 2 +-
 src/gallium/drivers/svga/svga_pipe_sampler.c  | 2 +-
 src/gallium/drivers/swr/swr_state.cpp | 2 +-
 src/gallium/drivers/trace/tr_context.c| 2 +-
 src/gallium/drivers/vc4/vc4_state.c   | 5 +++--
 src/gallium/drivers/virgl/virgl_context.c | 2 +-
 src/gallium/include/pipe/p_context.h  | 3 ++-
 src/mesa/state_tracker/st_atom_constbuf.c | 2 +-
 src/mesa/state_tracker/st_atom_texture.c  | 2 +-
 src/mesa/state_tracker/st_context.h   | 2 +-
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 6 +++---
 34 files changed, 54 insertions(+), 42 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 6ffcce4..5e6b36e 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -1284,7 +1284,7 @@ cso_restore_fragment_samplers(struct cso_context *ctx)
 
 void
 cso_set_sampler_views(struct cso_context *ctx,
-  unsigned shader_stage,
+  enum pipe_shader_type shader_stage,
   unsigned count,
   struct pipe_sampler_view **views)
 {
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
b/src/gallium/auxiliary/cso_cache/cso_context.h
index 5c9cb5a..27863f4 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -188,7 +188,7 @@ void cso_restore_state(struct cso_context *cso);
 
 void
 cso_set_sampler_views(struct cso_context *cso,
-  unsigned shader_stage,
+  enum pipe_shader_type shader_stage,
   unsigned count,
   struct pipe_sampler_view **views);
 
diff --git a/src/gallium/auxiliary/draw/draw_context.c 
b/src/gallium/auxiliary/draw/draw_context.c
index 6305761..56abcff 100644
--- a/src/gallium/auxiliary/draw/draw_context.c
+++ b/src/gallium/auxiliary/draw/draw_context.c
@@ -964,7 +964,7 @@ draw_set_mapped_so_targets(struct draw_context *draw,
 
 void
 draw_set_sampler_views(struct draw_context *draw,
-   unsigned shader_stage,
+   enum pipe_shader_type shader_stage,
struct pipe_sampler_view **views,
unsigned num)
 {
@@ -985,7 +985,7 @@ draw_set_sampler_views(struct draw_context *draw,
 
 void
 draw_set_samplers(struct draw_context *draw,
-  unsigned shader_stage,
+  enum pipe_shader_type shader_stage,
   struct pipe_sampler_state **samplers,
   unsigned num)
 {
diff --git a/src/gallium/auxiliary/draw/draw_context.h 
b/src/gallium/auxiliary/draw/draw_context.h
index 9167ffd..145fc2e 100644
--- a/src/gallium/auxiliary/draw/draw_context.h
+++ b/src/gallium/auxiliary/draw/draw_context.h
@@ -167,12 +167,12 @@ draw_buffer(struct draw_context *draw,
 
 void
 draw_set_sampler_views(struct draw_context *draw,
-   unsigned shader_stage,
+   enum pipe_shader_type shader_stage,
struct pipe_sampler_view **views,
unsigned num);
 void
 draw_set_samplers(struct draw_context *draw,
-  unsigned shader_stage,
+  enum pipe_shader_type shader_stage,
   struct pipe_sampler_state **samplers,
   unsigned num);
 
diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw

[Mesa-dev] [PATCH 3/4] gallium: Use enum pipe_shader_type in set_shader_buffers()

2016-08-27 Thread Kai Wasserbäch

Signed-off-by: Kai Wasserbäch 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 2 +-
 src/gallium/drivers/radeonsi/si_descriptors.c | 8 +---
 src/gallium/drivers/softpipe/sp_state_image.c | 2 +-
 src/gallium/drivers/trace/tr_context.c| 2 +-
 src/gallium/include/pipe/p_context.h  | 3 ++-
 src/mesa/state_tracker/st_atom_atomicbuf.c| 2 +-
 src/mesa/state_tracker/st_atom_storagebuf.c   | 2 +-
 7 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
index c9b0e3f..ee1e184 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_state.c
@@ -1409,7 +1409,7 @@ nvc0_bind_buffers_range(struct nvc0_context *nvc0, const 
unsigned t,
 
 static void
 nvc0_set_shader_buffers(struct pipe_context *pipe,
-unsigned shader,
+enum pipe_shader_type shader,
 unsigned start, unsigned nr,
 const struct pipe_shader_buffer *buffers)
 {
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 573c8a8..dfd0607 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -1060,19 +1060,21 @@ static void si_pipe_set_constant_buffer(struct 
pipe_context *ctx,
 /* SHADER BUFFERS */
 
 static unsigned
-si_shader_buffer_descriptors_idx(unsigned shader)
+si_shader_buffer_descriptors_idx(enum pipe_shader_type shader)
 {
return SI_DESCS_FIRST_SHADER + shader * SI_NUM_SHADER_DESCS +
   SI_SHADER_DESCS_SHADER_BUFFERS;
 }
 
 static struct si_descriptors *
-si_shader_buffer_descriptors(struct si_context *sctx, unsigned shader)
+si_shader_buffer_descriptors(struct si_context *sctx,
+ enum pipe_shader_type shader)
 {
return &sctx->descriptors[si_shader_buffer_descriptors_idx(shader)];
 }
 
-static void si_set_shader_buffers(struct pipe_context *ctx, unsigned shader,
+static void si_set_shader_buffers(struct pipe_context *ctx,
+ enum pipe_shader_type shader,
  unsigned start_slot, unsigned count,
  const struct pipe_shader_buffer *sbuffers)
 {
diff --git a/src/gallium/drivers/softpipe/sp_state_image.c 
b/src/gallium/drivers/softpipe/sp_state_image.c
index 553a76a..c5ef466 100644
--- a/src/gallium/drivers/softpipe/sp_state_image.c
+++ b/src/gallium/drivers/softpipe/sp_state_image.c
@@ -53,7 +53,7 @@ static void softpipe_set_shader_images(struct pipe_context 
*pipe,
 }
 
 static void softpipe_set_shader_buffers(struct pipe_context *pipe,
-unsigned shader,
+enum pipe_shader_type shader,
 unsigned start,
 unsigned num,
 const struct pipe_shader_buffer 
*buffers)
diff --git a/src/gallium/drivers/trace/tr_context.c 
b/src/gallium/drivers/trace/tr_context.c
index a648297..61b69c2 100644
--- a/src/gallium/drivers/trace/tr_context.c
+++ b/src/gallium/drivers/trace/tr_context.c
@@ -1711,7 +1711,7 @@ trace_context_set_tess_state(struct pipe_context 
*_context,
 
 
 static void trace_context_set_shader_buffers(struct pipe_context *_context,
- unsigned shader,
+ enum pipe_shader_type shader,
  unsigned start, unsigned nr,
  const struct pipe_shader_buffer 
*buffers)
 {
diff --git a/src/gallium/include/pipe/p_context.h 
b/src/gallium/include/pipe/p_context.h
index b74679d..bea1924 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -314,7 +314,8 @@ struct pipe_context {
 *   unless it's NULL, in which case no buffers will
 *   be bound.
 */
-   void (*set_shader_buffers)(struct pipe_context *, unsigned shader,
+   void (*set_shader_buffers)(struct pipe_context *,
+  enum pipe_shader_type shader,
   unsigned start_slot, unsigned count,
   const struct pipe_shader_buffer *buffers);
 
diff --git a/src/mesa/state_tracker/st_atom_atomicbuf.c 
b/src/mesa/state_tracker/st_atom_atomicbuf.c
index 7dde76a..f48ae61 100644
--- a/src/mesa/state_tracker/st_atom_atomicbuf.c
+++ b/src/mesa/state_tracker/st_atom_atomicbuf.c
@@ -43,7 +43,7 @@
 static void
 st_bind_atomics(struct st_context *st,
 struct gl_shader_program *prog,
-unsigned shader_type)
+enum pipe_shader_type shader_type)
 {
unsigned i;
 
diff --git a/src/mesa/state_tracker/st_atom_storage

[Mesa-dev] [PATCH 0/4] gallium clean-up (unsigned to enum pipe_shader_type)

2016-08-27 Thread Kai Wasserbäch

Hey everybody,
here is the complete series to switch from "unsigned shader" to
"enum pipe_shader_type" in the functions defined in p_context.h.

Please review and – if this series gets accepted – commit it for me, since I
do not have access for that.
Patch 1 already carries the R-b by Samuel.

All patches survived a compile run and 3D is still working on my
radeonsi-powered ASIC. ;-)

Cheers,
Kai

P.S.: By the way: there some other functions like get_shader_param, which also
could use this treatment. Not sure if I get around to this soon.


Kai Wasserbäch (4):
  gallium: Use enum pipe_shader_type in bind_sampler_states() (v2)
  gallium: Use enum pipe_shader_type in set_sampler_views()
  gallium: Use enum pipe_shader_type in set_shader_buffers()
  gallium: Use enum pipe_shader_type in set_shader_images()

 src/gallium/auxiliary/cso_cache/cso_context.c | 12 +++-
 src/gallium/auxiliary/cso_cache/cso_context.h | 10 ++
 src/gallium/auxiliary/draw/draw_context.c |  4 ++--
 src/gallium/auxiliary/draw/draw_context.h |  4 ++--
 src/gallium/auxiliary/draw/draw_pipe_aaline.c | 12 
 src/gallium/auxiliary/draw/draw_pipe_pstipple.c   | 16 +---
 src/gallium/drivers/ddebug/dd_context.c   |  9 ++---
 src/gallium/drivers/freedreno/a2xx/fd2_texture.c  |  2 +-
 src/gallium/drivers/freedreno/a3xx/fd3_texture.c  |  2 +-
 src/gallium/drivers/freedreno/a4xx/fd4_texture.c  |  4 ++--
 src/gallium/drivers/freedreno/freedreno_texture.c |  4 ++--
 src/gallium/drivers/freedreno/freedreno_texture.h |  3 ++-
 src/gallium/drivers/i915/i915_state.c |  5 +++--
 src/gallium/drivers/ilo/ilo_state.c   | 10 +++---
 src/gallium/drivers/llvmpipe/lp_state_sampler.c   |  4 ++--
 src/gallium/drivers/noop/noop_state.c |  6 --
 src/gallium/drivers/nouveau/nv30/nv30_fragtex.c   |  2 +-
 src/gallium/drivers/nouveau/nv30/nv30_texture.c   |  5 -
 src/gallium/drivers/nouveau/nv50/nv50_state.c |  7 +--
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 18 --
 src/gallium/drivers/r300/r300_state.c |  5 +++--
 src/gallium/drivers/r600/r600_state_common.c  |  5 +++--
 src/gallium/drivers/radeonsi/si_descriptors.c | 16 ++--
 src/gallium/drivers/rbug/rbug_context.c   |  5 +++--
 src/gallium/drivers/softpipe/sp_state.h   |  2 +-
 src/gallium/drivers/softpipe/sp_state_image.c |  4 ++--
 src/gallium/drivers/softpipe/sp_state_sampler.c   |  4 ++--
 src/gallium/drivers/svga/svga_pipe_sampler.c  |  4 ++--
 src/gallium/drivers/swr/swr_state.cpp |  4 ++--
 src/gallium/drivers/trace/tr_context.c|  8 
 src/gallium/drivers/vc4/vc4_state.c   |  7 ---
 src/gallium/drivers/virgl/virgl_context.c |  5 +++--
 src/gallium/include/pipe/p_context.h  | 14 +-
 src/mesa/state_tracker/st_atom_atomicbuf.c|  2 +-
 src/mesa/state_tracker/st_atom_constbuf.c |  2 +-
 src/mesa/state_tracker/st_atom_image.c|  2 +-
 src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
 src/mesa/state_tracker/st_atom_storagebuf.c   |  2 +-
 src/mesa/state_tracker/st_atom_texture.c  |  2 +-
 src/mesa/state_tracker/st_context.h   |  2 +-
 src/mesa/state_tracker/st_glsl_to_nir.cpp |  2 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp|  6 +++---
 42 files changed, 145 insertions(+), 99 deletions(-)

-- 
2.9.3

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

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

2016-08-27 Thread Kai Wasserbäch

v1 → v2:
 - Fixed indentation (noted by Brian Paul)
 - Removed second assert from nouveau's switch statements (suggested by
   Brian Paul)

Reviewed-by: Samuel Pitoiset 
Signed-off-by: Kai Wasserbäch 
---
 src/gallium/auxiliary/cso_cache/cso_context.c |  7 ---
 src/gallium/auxiliary/cso_cache/cso_context.h |  5 +++--
 src/gallium/auxiliary/draw/draw_pipe_aaline.c |  9 ++---
 src/gallium/auxiliary/draw/draw_pipe_pstipple.c   |  7 ---
 src/gallium/drivers/ddebug/dd_context.c   |  3 ++-
 src/gallium/drivers/freedreno/a2xx/fd2_texture.c  |  2 +-
 src/gallium/drivers/freedreno/a3xx/fd3_texture.c  |  2 +-
 src/gallium/drivers/freedreno/a4xx/fd4_texture.c  |  2 +-
 src/gallium/drivers/freedreno/freedreno_texture.c |  2 +-
 src/gallium/drivers/i915/i915_state.c |  3 ++-
 src/gallium/drivers/ilo/ilo_state.c   |  3 ++-
 src/gallium/drivers/llvmpipe/lp_state_sampler.c   |  2 +-
 src/gallium/drivers/noop/noop_state.c |  3 ++-
 src/gallium/drivers/nouveau/nv30/nv30_texture.c   |  5 -
 src/gallium/drivers/nouveau/nv50/nv50_state.c |  5 -
 src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 11 ---
 src/gallium/drivers/r300/r300_state.c |  2 +-
 src/gallium/drivers/r600/r600_state_common.c  |  2 +-
 src/gallium/drivers/radeonsi/si_descriptors.c |  3 ++-
 src/gallium/drivers/rbug/rbug_context.c   |  3 ++-
 src/gallium/drivers/softpipe/sp_state_sampler.c   |  2 +-
 src/gallium/drivers/svga/svga_pipe_sampler.c  |  2 +-
 src/gallium/drivers/swr/swr_state.cpp |  2 +-
 src/gallium/drivers/trace/tr_context.c|  2 +-
 src/gallium/drivers/vc4/vc4_state.c   |  2 +-
 src/gallium/drivers/virgl/virgl_context.c |  3 ++-
 src/gallium/include/pipe/p_context.h  |  5 +++--
 src/mesa/state_tracker/st_atom_sampler.c  |  2 +-
 28 files changed, 63 insertions(+), 38 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 4a54cff..6ffcce4 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -316,7 +316,7 @@ void cso_destroy_context( struct cso_context *ctx )
  static struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS] 
= { NULL };
  static void *zeros[PIPE_MAX_SAMPLERS] = { NULL };
  struct pipe_screen *scr = ctx->pipe->screen;
- unsigned sh;
+ enum pipe_shader_type sh;
  for (sh = 0; sh < PIPE_SHADER_TYPES; sh++) {
 int maxsam = scr->get_shader_param(scr, sh,

PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
@@ -1207,7 +1207,8 @@ cso_single_sampler(struct cso_context *ctx, unsigned 
shader_stage,
  * Send staged sampler state to the driver.
  */
 void
-cso_single_sampler_done(struct cso_context *ctx, unsigned shader_stage)
+cso_single_sampler_done(struct cso_context *ctx,
+enum pipe_shader_type shader_stage)
 {
struct sampler_info *info = &ctx->samplers[shader_stage];
const unsigned old_nr_samplers = info->nr_samplers;
@@ -1233,7 +1234,7 @@ cso_single_sampler_done(struct cso_context *ctx, unsigned 
shader_stage)
  */
 enum pipe_error
 cso_set_samplers(struct cso_context *ctx,
- unsigned shader_stage,
+ enum pipe_shader_type shader_stage,
  unsigned nr,
  const struct pipe_sampler_state **templates)
 {
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
b/src/gallium/auxiliary/cso_cache/cso_context.h
index a4309c7..5c9cb5a 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -60,7 +60,7 @@ enum pipe_error cso_set_rasterizer( struct cso_context *cso,
 
 enum pipe_error
 cso_set_samplers(struct cso_context *cso,
- unsigned shader_stage,
+ enum pipe_shader_type shader_stage,
  unsigned count,
  const struct pipe_sampler_state **states);
 
@@ -73,7 +73,8 @@ cso_single_sampler(struct cso_context *cso, unsigned 
shader_stage,
unsigned idx, const struct pipe_sampler_state *states);
 
 void
-cso_single_sampler_done(struct cso_context *cso, unsigned shader_stage);
+cso_single_sampler_done(struct cso_context *cso,
+enum pipe_shader_type shader_stage);
 
 
 enum pipe_error cso_set_vertex_elements(struct cso_context *ctx,
diff --git a/src/gallium/auxiliary/draw/draw_pipe_aaline.c 
b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
index a5f0723..1ea77da 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_aaline.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_aaline.c
@@ -118,10 +118,12 @@ struct aaline_stage
void (*driver_bind_fs_state)(struct pipe_context *, void *);
void (*driver_delete_fs_state)(struct pipe_context *, void *);
 
-   void (

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

2016-08-27 Thread Kai Wasserbäch

Hey Samuel,
Samuel Pitoiset wrote on 26.08.2016 20:22:
> On 08/26/2016 04:17 PM, Kai Wasserbäch wrote:
>> Hey Samuel,
>> Samuel Pitoiset wrote on 26.08.2016 15:54:
>>> On 08/26/2016 01:58 PM, Kai Wasserbäch wrote:
>>>> [...]
>>>> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_texture.c
>>>> b/src/gallium/drivers/nouveau/nv30/nv30_texture.c
>>>> index 4f4f87e..dc1a476 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,10 @@ nv30_bind_sampler_states(struct pipe_context *pipe,
>>>> case PIPE_SHADER_FRAGMENT:
>>>>nv30_fragtex_sampler_states_bind(pipe, num_samplers, samplers);
>>>>break;
>>>> +   default:
>>>> +  assert(shader <= PIPE_SHADER_TYPES);
>>>> +  assert(!"invalid/unhandled type");
>>>
>>> assert(!"invalid PIPE_SHADER type"); is enough here.
>>> Please apply the same change for nv50 and nvc0 as well.
>>
>> Is v2 – with a slightly different assert message – ok then?
> 
> Yeah, I wouldn't worry about it, it's fine by me.
> 
> Just make sure it compiles, it should but who knows. :)
> 
> Reviewed-by: Samuel Pitoiset 

thanks for the review! I've sent the complete series and would appreciate
further R-bs (and the subsequent commit). ;-)

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)

2016-08-27 Thread 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

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

2016-10-19 Thread 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] [ANNOUNCE] mesa 13.0.0-rc1

2016-10-20 Thread 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] Stable release process

2016-11-18 Thread 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] [PATCH] mesa: Clamp negative values in glGetUniformuiv

2016-12-10 Thread 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] [PATCH] mesa: Clamp negative values in glGetUniformuiv

2016-12-10 Thread 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:
>

[Mesa-dev] [PATCH] Ensure we find the linker scripts in out-of-tree builds.

2013-10-26 Thread Kai Wasserbäch

Signed-off-by: Kai Wasserbäch 
Cc: thomas.stell...@amd.com
---
Hi Tom,
the patches you sent seem to work, but only for in-tree builds. If you push
them out, please also fold the following patch into that series, that ensures
out-of-tree builds work as well.

If ran a full out-of-tree build in a clean pbuilder build environment; didn't
run-test the resulting binaries yet.

Kind regards,
Kai Wasserbäch

P.S.: Just for your reference: this is a follow-up to the discussion on IRC
yesterday.


 src/gallium/targets/egl-static/Makefile.am  | 2 +-
 src/gallium/targets/pipe-loader/Makefile.am | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/targets/egl-static/Makefile.am 
b/src/gallium/targets/egl-static/Makefile.am
index e7fc11b..760c477 100644
--- a/src/gallium/targets/egl-static/Makefile.am
+++ b/src/gallium/targets/egl-static/Makefile.am
@@ -30,7 +30,7 @@
 #
 include $(top_srcdir)/src/gallium/Automake.inc
 
-LDFLAGS+=-Wl,egl.link
+LDFLAGS += -Wl,$(top_srcdir)/src/gallium/targets/egl-static/egl.link
 
 AM_CFLAGS = $(PTHREAD_CFLAGS)
 AM_CPPFLAGS = \
diff --git a/src/gallium/targets/pipe-loader/Makefile.am 
b/src/gallium/targets/pipe-loader/Makefile.am
index 8e2002c..970ff0e 100644
--- a/src/gallium/targets/pipe-loader/Makefile.am
+++ b/src/gallium/targets/pipe-loader/Makefile.am
@@ -22,7 +22,7 @@
 
 include $(top_srcdir)/src/gallium/Automake.inc
 
-LDFLAGS+=-Wl,pipe.link
+LDFLAGS += -Wl,$(top_srcdir)/src/gallium/targets/pipe-loader/pipe.link
 
 AM_CPPFLAGS = \
$(GALLIUM_CFLAGS) \
-- 
1.8.4.rc3

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

[Mesa-dev] [PATCH] radeonsi: Allow longer intrinsic names

2013-10-27 Thread Kai Wasserbäch

Fixes a boat load of Piglit tests for me, which crashed like fdo#70913
before.

Thanks to Michel Dänzer for the tip.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70913
Signed-off-by: Kai Wasserbäch 
---
 src/gallium/drivers/radeonsi/radeonsi_shader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c 
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 9f81a7b..dff8be0 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
@@ -1425,7 +1425,7 @@ static void build_tex_intrinsic(const struct 
lp_build_tgsi_action * action,
struct lp_build_emit_data * emit_data)
 {
struct lp_build_context * base = &bld_base->base;
-   char intr_name[23];
+   char intr_name[127];
 
sprintf(intr_name, "%sv%ui32", action->intr_name,
LLVMGetVectorSize(LLVMTypeOf(emit_data->args[0])));
-- 
1.8.4.rc3

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

Re: [Mesa-dev] [PATCH] radeonsi: Allow longer intrinsic names

2013-10-29 Thread Kai Wasserbäch

Tom Stellard schrieb am 29.10.2013 17:48:
> On Sun, Oct 27, 2013 at 07:36:07PM +0100, Kai Wasserbäch wrote:
>> Fixes a boat load of Piglit tests for me, which crashed like fdo#70913
>> before.
>>
>> Thanks to Michel Dänzer for the tip.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70913
>> Signed-off-by: Kai Wasserbäch 
> 
> This looks OK to me, which intrinsic names were too long?

In this particular instance (see the backtrace
<https://bugs.freedesktop.org/attachment.cgi?id=88177> (#11)) and all other
similar crashes I saw "llvm.SI.imageload.v4i3".

> Reviewed-by: Tom Stellard 

Thanks for the review! As I don't have commit access, you – or someone else with
the appropriate rights – would need to commit this fix on my behalf. Thanks in
advance for that!

>> ---
>>  src/gallium/drivers/radeonsi/radeonsi_shader.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c 
>> b/src/gallium/drivers/radeonsi/radeonsi_shader.c
>> index 9f81a7b..dff8be0 100644
>> --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c
>> +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c
>> @@ -1425,7 +1425,7 @@ static void build_tex_intrinsic(const struct 
>> lp_build_tgsi_action * action,
>>  struct lp_build_emit_data * emit_data)
>>  {
>>  struct lp_build_context * base = &bld_base->base;
>> -char intr_name[23];
>> +char intr_name[127];
>>  
>>  sprintf(intr_name, "%sv%ui32", action->intr_name,
>>  LLVMGetVectorSize(LLVMTypeOf(emit_data->args[0])));
>> -- 
>> 1.8.4.rc3



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

Re: [Mesa-dev] Fix crashes with static LLVM

2013-11-06 Thread Kai Wasserbäch

Dear Tom,
Tom Stellard schrieb am 06.11.2013 01:24:
> On Wed, Oct 23, 2013 at 04:26:18PM -0400, Tom Stellard wrote:
>> The attached patches introduce linker scripts to the pipe-loader and
>> egl-static targets.  The linker scripts prevents these targets from
>> exporting LLVM (and other) symbols that they shouldn't be.  This fixes
>> several crashes in the radeon drivers when statically linking LLVM.
>>
>> With these patches: clover, glamor, and the egl demos from the mesa-demo 
>> repo all
>> work for me with statically linked LLVM, but I would like to get 
>> confirmation that
>> this works for other people too, so if you care about these use cases, 
>> please test
>> and let me know the results.
>>
> 
> I have gotten some positive feedback on these patches from testers, so
> if there are no objections, I will push these tomorrow.

by now I can give you a Tested-by as I've used these patches for almost two
weeks and various builds. Please don't forget to include my fix for out-of-tree
builds ([0]), when you push this series.

Thanks,
Kai


[0] 



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

Re: [Mesa-dev] libxatracker: automake and spurious symbols

2014-04-05 Thread Kai Wasserbäch

Dear Emil,
Emil Velikov schrieb am 05.04.2014 04:10:
> On 01/04/14 01:32, Emil Velikov wrote:
>> On 29/03/14 14:24, Kai Wasserbäch wrote:
>>> Emil Velikov schrieb am 29.03.2014 14:21:
>>>> On 29/03/14 12:37, Kai Wasserbäch wrote:
>>>>> I tried a version script and and -export-symbols-regex '^xa_.*$$', which 
>>>>> really
>>>>> got added to the linking command, according to the build log, but didn't 
>>>>> have
>>>>> any impact on the actually exported symbols. I'm probably missing 
>>>>> something as
>>>>> I'm not too well versed in how to do things with Automake.
>>>>>
>>>> Strange... things were working fine last time I've checked. While I try to
>>>> reproduce what build options are you using, LLVM version ? Can I take a 
>>>> look
>>>> at the patch that you've used ?
>>>
>>> Sure. I've tried several variants of the attached
>>> "0001-Build-libxatracker-Only-export-our-own-symbols.patch", where I 
>>> replaced
>>> "LDFLAGS" with "AM_LDFLAGS" and "libxatracker_la_LDFLAGS". The last didn't 
>>> work
>>> at all and Automake warned, that no library is using the name 
>>> libxatracker_la,
>>> even though just a few lines up there was "libxatracker_la_SOURCES". I also
>>> tried listing all symbols explicitly in the version script, but that didn't
>>> change anything either.
>>>
>>> The second approach was really just patching the Makefile to add the
>>> -export-symbols-regex '^xa_.*$'
>>> to the LDFLAGS. I did it the same way, it's used with the OMX stuff, see the
>>> attached patch 
>>> "0001-Build-libxatracker-pass-export-symbols-regex-to-link.patch"
>>>
>> The key issue with your approach is that you're restricting the exported
>> symbols at the wrong "level". One should work on the finished target, as this
>> is where all the linking (inc. the one against LLVM) happens. I will prep a
>> series that clears the exported symbols in a more consistent way all across
>> all gallium targets.
>>
> 
> https://github.com/evelikov/Mesa/ branch exported-symbol-cleanup
> 
> Feel free to checkout and give it a test.

I'm currently unable to build Mesa, since I'm seeing build failures due to a
missing symbols:
> Making all in opencl
> make[4]: Entering directory 
> `/tmp/buildd/mesa-10.2~20140405.1.git4ccff1499c/build/dri/src/gallium/targets/opencl'
> /bin/bash ../../../../libtool  --tag=CXX   --mode=link g++  -g -O2 
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
> -Wall -Wall -fno-strict-aliasing -fno-builtin-memcmp  -L/usr/lib/llvm-3.5/lib 
>  -no-undefined -version-number 1:0 
> -Wl,--version-script=../../../../../../src/gallium/targets/opencl/opencl.sym 
> -Wl,--gc-sections -Wl,--no-undefined -Wl,-z,relro -o libMesaOpenCL.la -rpath 
> /usr/lib/x86_64-linux-gnu  
> ../../../../src/gallium/auxiliary/pipe-loader/libpipe_loader_client.la 
> ../../../../src/gallium/winsys/sw/null/libws_null.la 
> ../../../../src/gallium/state_trackers/clover/libclover.la 
> ../../../../src/gallium/auxiliary/libgallium.la -lxcb-dri2 -lxcb   -ldrm
> -ldl -lclangCodeGen -lclangFrontendTool -lclangFrontend -lclangDriver 
> -lclangSerialization -lclangCodeGen -lclangParse -lclangSema -lclangAnalysis 
> -lclangAST -lclangEdit -lclangLex -lclangBasic -lLLVMR600CodeGen 
> -lLLVMR600Desc -lLLVMR600Info -lLLVMR600AsmPrinter -lLLVMOption 
> -lLLVMIRReader -lLLVMAsm
Parser -lLLVMInstrumentation -lLLVMLinker -lLLVMipo -lLLVMVectorize -lLLVMMCJIT 
-lLLVMRuntimeDyld -lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser 
-lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser 
-lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT 
-lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine 
-lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC 
-lLLVMObject -lLLVMBitReader -lLLVMCore -lLLVMSupport -lpthread -lffi -ledit 
-ltinfo -ldl -lm   ../../../../src/gallium/winsys/sw/dri/libswdri.la 
../../../../src/gallium/winsys/sw/xlib/libws_xlib.la -lX11 -lXext -lXfixes 
-ldrm   
> libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o 
> /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o  -Wl,--whole-archive 
> ../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_client.a 
> ../../../../src/gallium/winsys/sw/null/.libs/libws_null.a 
> ../../../../src

Re: [Mesa-dev] [PIGLIT,radeonsi] crash in spec/glsl-1.50/execution/geometry/max-input-components – who's bug is it?

2014-04-16 Thread Kai Wasserbäch

Michel Dänzer schrieb am 15.04.2014 09:27:
> On 23.03.2014 04:53, Kai Wasserbäch wrote:
>> Dear Mesa devs,
>> I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash 
>> happens
>> in _int_malloc, but since that is certainly one of the more often used
>> functions, I'm not yet convinced, the fault lies indeed with eglibc.
>>
>> Therefore I'm attaching the full backtrace of the crash in
>> spec/glsl-1.50/execution/geometry/max-input-components (it takes a very long
>> time until the crash actually happens, Piglit recorded an execution time of
>> 1538.0506579875946) and hope you can point me to the right bug tracker.
>>
>> I'm unable to tell, whether this is a regression or not, since today was the
>> first time I was able to run a full Piglit quick test, without crashing my X 
>> on
>> this machine with the radeonsi.
> 
> It's not a regression. If you build LLVM with assertions enabled, you get:
> 
> shader_runner:
> /home/daenzer/src/llvm-git/llvm/lib/CodeGen/RegAllocGreedy.cpp:2268:
> unsigned int
> {anonymous}::RAGreedy::selectOrSplitImpl(llvm::LiveInterval&,
> llvm::SmallVectorImpl&,
> {anonymous}::RAGreedy::SmallVirtRegSet&, unsigned int): Assertion
> `NewVRegs.empty() && "Cannot append to existing NewVRegs"' failed.
> 
> So this is an LLVM issue. It might be worth testing if Tom's register
> spilling patches help.

Can you point me to those patches? Preferrably as a branch, but ML is ok as 
well.

Thanks,
Kai

P.S.: Sorry for not coming back with a Valgrind log, but after waiting for
almost twelve hours I killed the job and didn't have time to start a new one.



-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PIGLIT,radeonsi] crash in spec/glsl-1.50/execution/geometry/max-input-components fixed (was: crash in spec/glsl-1.50/execution/geometry/max-input-components – who's bug is it?)

2014-04-18 Thread Kai Wasserbäch

Hi there,
Tom Stellard schrieb am 16.04.2014 17:07:
> On Wed, Apr 16, 2014 at 02:36:19PM +0200, Kai Wasserbäch wrote:
>> Michel Dänzer schrieb am 15.04.2014 09:27:
>>> On 23.03.2014 04:53, Kai Wasserbäch wrote:
>>>> Dear Mesa devs,
>>>> I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash 
>>>> happens
>>>> in _int_malloc, but since that is certainly one of the more often used
>>>> functions, I'm not yet convinced, the fault lies indeed with eglibc.
>>>>
>>>> Therefore I'm attaching the full backtrace of the crash in
>>>> spec/glsl-1.50/execution/geometry/max-input-components (it takes a very 
>>>> long
>>>> time until the crash actually happens, Piglit recorded an execution time of
>>>> 1538.0506579875946) and hope you can point me to the right bug tracker.
>>>>
>>>> I'm unable to tell, whether this is a regression or not, since today was 
>>>> the
>>>> first time I was able to run a full Piglit quick test, without crashing my 
>>>> X on
>>>> this machine with the radeonsi.
>>>
>>> It's not a regression. If you build LLVM with assertions enabled, you get:
>>>
>>> shader_runner:
>>> /home/daenzer/src/llvm-git/llvm/lib/CodeGen/RegAllocGreedy.cpp:2268:
>>> unsigned int
>>> {anonymous}::RAGreedy::selectOrSplitImpl(llvm::LiveInterval&,
>>> llvm::SmallVectorImpl&,
>>> {anonymous}::RAGreedy::SmallVirtRegSet&, unsigned int): Assertion
>>> `NewVRegs.empty() && "Cannot append to existing NewVRegs"' failed.
>>>
>>> So this is an LLVM issue. It might be worth testing if Tom's register
>>> spilling patches help.
>>
>> Can you point me to those patches? Preferrably as a branch, but ML is ok as 
>> well.
>>
> 
> Here is the branch: 
> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

I've just rerun the Piglit test
(spec/glsl-1.50/execution/geometry/max-input-components) with the patches from
the si-spill-fixes branch (I needed to massage them a bit into applying on top
of LLVM's SVN revision 206583, but that was straight forward enough) and can
report, that the crash is gone. The test (still) fails, however:

$ gdb --args /build/bin/shader_runner
/local.git/tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test
-auto
[GNU GDB boilerplate]
Reading symbols from /build/bin/shader_runner...done.
(gdb) r
Starting program: /build/bin/shader_runner
/local.git/tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test
-auto
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x70081700 (LWP 24909)]
Probe color at (0,0)
  Expected: 0.00 1.00 0.00 1.00
  Observed: 0.00 0.00 0.00 0.00
PIGLIT: {'result': 'fail' }
[Thread 0x70081700 (LWP 24909) exited]
[Inferior 1 (process 24905) exited with code 01]


The stack used for this test is a bit farther ahead as well, in case that makes
a difference, I'm detailing it below:
GPU: "PITCAIRN" (ChipID = 0x6819)
Linux: 3.14.0
libdrm: Git:master/libdrm-2.4.53
LLVM: SVN:trunk/r206583
libclc: Git:master/1e278a7b04
Mesa: Git:master/352e06ddea
GLAMOR: Git:master/a4fbc7732a (Standalone)
DDX: Git:master/ea6d0affe5
X: 2:1.15.0.901-1

Thank you for pointing me in the right direction; if you should need me to run
another test, please let me know.

Cheers,
Kai

P.S.: Any idea, when the si-spill-fixes branch is going to land upstream?



-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PIGLIT, radeonsi] crash in spec/glsl-1.50/execution/geometry/max-input-components fixed

2014-04-19 Thread Kai Wasserbäch

Hello Tom,
Tom Stellard schrieb am 19.04.2014 06:37:
> On Fri, Apr 18, 2014 at 06:59:37PM +0200, Kai Wasserbäch wrote:
>> Tom Stellard schrieb am 16.04.2014 17:07:
>>> Here is the branch: 
>>> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes

I noticed, that the patches add a SI_SPILL_V96 instruction and while all others
are added to getNumSubRegsForSpillOp() as well as
SIInstrInfo::expandPostRAPseudo(), both in lib/Target/R600/SIInstrInfo.cpp, I
don't see the V96 case covered. Is this an oversight or am I missing something
(entirely possible, since my LLVM knowledge is very limited)? I just thought I
bring it up, in case that's something you'd like to fix before pushing it out.

> Thanks for tracking this down.  I've been trying to find a good test
> case for register spilling and this looks like it might be it.  Most of
> the register spilling bugs come from proprietary games that I don't have
> access to.  I will try to look at this on Monday.

I'm glad I could help. If you know of a specific game, maybe ping me privately
and if I have it, I'm willing to test those as well.

>> P.S.: Any idea, when the si-spill-fixes branch is going to land upstream?
>>
> 
> As soon as I can verify that it is working.

Ok, fair enough. ;-) (Just wanted to know how long I've to keep building LLVM
myself :-p)

Cheers,
Kai

-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] libxatracker: automake and spurious symbols

2014-04-27 Thread Kai Wasserbäch

Dear Emil,
Emil Velikov schrieb am 25.04.2014 20:59:
> [snip]
>
> Did you manage to try any of the suggestions - was it a llvm/clang issue or
> mesa ? Please open a bugreport if you're still having issues building the
> opencl library.

I managed to build Mesa again, seems to have been an issue with LLVM. I need to
try a build with your branch on top again. I'll try that in the coming week.

Cheers,
Kai



-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCHES 0/9] Draw Indirect and Cube Map Arrays for RadeonSI

2014-04-27 Thread Kai Wasserbäch

Hi Marek,
could you add the progress to GL3.txt, please? (In patches 2 and 9.)

Thank you,
Kai


Marek Olšák schrieb am 26.04.2014 15:27:
> Hi everyone,
> 
> This series adds support for ARB_texture_cube_map_array and ARB_draw_indirect 
> to the radeonsi driver. There is also Gallium infrastructure support for 
> ARB_draw_indirect. As usual, the first patch is unrelated to the rest of the 
> series. ;)
> 
> Please review.
> 
> Christoph Bumiller (3):
>   gallium: add PIPE_BIND_COMMAND_ARGS_BUFFER
>   gallium: add facilities for indirect drawing
>   st/mesa: add support for indirect drawing
> 
> Marek Olšák (6):
>   configure.ac: radeonsi requires EGL_DRM and GBM
>   radeonsi: implement ARB_texture_cube_map_array
>   gallium/u_vbuf: get draw info from an indirect buffer if there's any
>   radeonsi: use an SGPR instead of VGT_INDX_OFFSET
>   radeonsi: don't add info->start to the index buffer offset
>   radeonsi: implement ARB_draw_indirect
> 
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] targets/opencl: Fix (static) linking with LLVM

2014-05-18 Thread Kai Wasserbäch

Without this, I get linking failures (static linking).

The static linking is sort of required for me, because otherwise Steam and
applications using the Steam runtime regularily fail because my LLVM was
compiled and linked against a newer libgcc_s, libstdc++, etc. and uses
features from those newer versions. And instead of just not starting, my
X starts crashing, whenever libGL fails to load a (32 bit) driver.

Since I hate crashes of X and I don't think Valve/Steam will behave like
a proper distribution soon (rebuilds versus current Debian Testing, since
they base their Steam OS off that), I need a radeonsi which carries its
own LLVM within and doesn't care about what the runtime sets.

Signed-off-by: Kai Wasserbäch 
---
 src/gallium/targets/opencl/Makefile.am |2 ++
 1 file changed, 2 insertions(+)

--- a/src/gallium/targets/opencl/Makefile.am
+++ b/src/gallium/targets/opencl/Makefile.am
@@ -31,6 +31,8 @@ lib@OPENCL_LIBNAME@_la_LIBADD = \
-lclangEdit \
-lclangLex \
-lclangBasic \
+   -lLLVMObjCARCOpts \
+   -lLLVMProfileData \
$(LLVM_LIBS)
 
 if HAVE_DRI
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] targets/opencl: Fix (static) linking with LLVM (v2)

2014-05-19 Thread Kai Wasserbäch

Without this, I get linking failures (static linking).

The static linking is sort of required for me, because otherwise Steam and
applications using the Steam runtime regularily fail because my LLVM was
compiled and linked against a newer libgcc_s, libstdc++, etc. and uses
features from those newer versions. And instead of Steam just not
starting, my X starts crashing, whenever libGL fails to load a (32 bit)
driver.

Since I hate crashes of X and I don't think Valve/Steam will behave like
a proper distribution soon (rebuilds versus current Debian Testing, since
they base their Steam OS off that), I need a radeonsi which carries its
own LLVM within and doesn't care about what the runtime sets. This means
linking Mesa statically.

v1 → v2: Move logic to configure.ac

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

Dear Emil,
I hope this is the right place for adding the two additional modules.

If you accept this patch, please push it for me, I don't have commit access.

Cheers,
Kai



 configure.ac | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/configure.ac b/configure.ac
index 4e4d761..b4920ba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1658,6 +1658,13 @@ if test "x$enable_gallium_llvm" = xyes; then
 if $LLVM_CONFIG --components | grep -qw 'option'; then
 LLVM_COMPONENTS="${LLVM_COMPONENTS} option"
 fi
+# Current OpenCL/Clover and LLVM 3.5 require ObjCARCOpts and 
ProfileData
+if $LLVM_CONFIG --components | grep -qw 'objcarcopts'; then
+LLVM_COMPONENTS="${LLVM_COMPONENTS} objcarcopts"
+fi
+if $LLVM_CONFIG --components | grep -qw 'profiledata'; then
+LLVM_COMPONENTS="${LLVM_COMPONENTS} profiledata"
+fi
 fi
 DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT 
-DLLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
 MESA_LLVM=1
-- 
2.0.0.rc2

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

Re: [Mesa-dev] [PATCH] targets/opencl: Fix (static) linking with LLVM

2014-05-19 Thread Kai Wasserbäch

Michel Dänzer schrieb am 19.05.2014 04:12:
> On 18.05.2014 18:37, Kai Wasserbäch wrote:
>>
>> And instead of just not starting, my X starts crashing, whenever
>> libGL fails to load a (32 bit) driver.
> 
> FWIW, some potential alternatives for avoiding the X crashes:
> 
> With current xserver Git master, you can pass the -iglx parameter to
> Xorg to prohibit GLX indirect rendering.
> 
> Or just make sure the 32-bit swrast_dri.so works.

Thanks a lot for those pointers. I think my swrast failed because it had picked
up some newer SO_VERSION as well. Which would bring me back to static linking.

Kind regards,
Kai Wasserbäch



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

Re: [Mesa-dev] [PATCH] targets/opencl: Fix (static) linking with LLVM

2014-05-28 Thread Kai Wasserbäch

[Just a short note, as I can't test Mesa any longer, since I have a new Radeon,
which is "no business case" for the FLOSS driver.]

terminfo rings a bell, IIRC there was a Mesa bug about this some while back; for
myself at least I just added the terminfo stuff to my Mesa build (again IIRC,
that problem came up a while back for me).

Cheers,
Kai



-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] build: Fix FTBFS bug introduced by ee55500c22

2014-02-19 Thread Kai Wasserbäch

The referenced commit set the with_dri_drivers variable to "yes" in the
auto case, which is an unknown classic DRI driver and leads to a FTBFS.

CC: Emil Velikov 
Signed-off-by: Kai Wasserbäch 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 8390d27..ad00d93 100644
--- a/configure.ac
+++ b/configure.ac
@@ -955,7 +955,7 @@ no) ;;
 auto)
 # classic DRI drivers
 if test "x$enable_opengl" = xyes; then
-with_dri_drivers="yes"
+with_dri_drivers="swrast,i915,i965,radeon,r200,nouveau"
 fi
 ;;
 esac
-- 
1.8.5.3

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

Re: [Mesa-dev] [PIGLIT,radeonsi] crash in spec/glsl-1.50/execution/geometry/max-input-components – who's bug is it?

2014-03-25 Thread Kai Wasserbäch

Brian Paul schrieb am 24.03.2014 15:45:
> On 03/22/2014 01:53 PM, Kai Wasserbäch wrote:
>> Dear Mesa devs,
>> I'm not sure whether this is a bug in Mesa, LLVM or in eglibc. The crash 
>> happens
>> in _int_malloc, but since that is certainly one of the more often used
>> functions, I'm not yet convinced, the fault lies indeed with eglibc.
>>
>> Therefore I'm attaching the full backtrace of the crash in
>> spec/glsl-1.50/execution/geometry/max-input-components (it takes a very long
>> time until the crash actually happens, Piglit recorded an execution time of
>> 1538.0506579875946) and hope you can point me to the right bug tracker.
>>
>> I'm unable to tell, whether this is a regression or not, since today was the
>> first time I was able to run a full Piglit quick test, without crashing my X 
>> on
>> this machine with the radeonsi.
>>
>> My graphics stack is:
>> GPU: "PITCAIRN" (ChipID = 0x6819)
>> Linux: 3.13.6
>> libdrm: 2.4.52-1
>> LLVM: SVN:trunk/r204517
>> libclc: Git:master/1e278a7b04
>> Mesa: Git:master/4c79f088c0
>> GLAMOR: Git:master/a4fbc7732a (Standalone)
>> DDX: Git:master/ea6d0affe5
>> X: 1.15.0-2
>>
>> Let me know if you need further information.
> 
> While it would take even longer, running with valgrind might help to isolate 
> the
> location of a memory error.

Ok, I'll do that over the weekend, since I haven't been able to get the output
within five hours yesterday in the evening. If there is a particular set of
options I should pass to valgrind, please let me know.

Cheers,
Kai



-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] libxatracker: automake and spurious symbols

2014-03-29 Thread Kai Wasserbäch

Hi Emil,
Emil Velikov schrieb am 29.03.2014 14:21:
> On 29/03/14 12:37, Kai Wasserbäch wrote:
>> I saw one of your patches currently in review touching the Makefile.am of
>> libxatracker. Can you squeeze in another patch, that ensures, that the 
>> library
>> only exports its own symbols and not the entirety of LLVM as well? Because
>> somewhere between 4c79f088c0 and 9b6b084eb7, that started to happen. My
>> 4c79f088c0 build only exported symbols for xa_* functions, the current build 
>> of
>> 9b6b084eb7 adds some ten thousand LLVM symbols.
>>
> Yes that is the privilege of using LLVM, you export the whole LLVM world as
> soon as you go anywhere near it :P
> 
> My initial plan was to do another round of "cleanup the exported symbols"
> but got sidetracked by stripping out duplication and making sure that the
> libraries just work (tm).
> 
>> I tried a version script and and -export-symbols-regex '^xa_.*$$', which 
>> really
>> got added to the linking command, according to the build log, but didn't have
>> any impact on the actually exported symbols. I'm probably missing something 
>> as
>> I'm not too well versed in how to do things with Automake.
>>
> Strange... things were working fine last time I've checked. While I try to
> reproduce what build options are you using, LLVM version ? Can I take a look
> at the patch that you've used ?

Sure. I've tried several variants of the attached
"0001-Build-libxatracker-Only-export-our-own-symbols.patch", where I replaced
"LDFLAGS" with "AM_LDFLAGS" and "libxatracker_la_LDFLAGS". The last didn't work
at all and Automake warned, that no library is using the name libxatracker_la,
even though just a few lines up there was "libxatracker_la_SOURCES". I also
tried listing all symbols explicitly in the version script, but that didn't
change anything either.

The second approach was really just patching the Makefile to add the
-export-symbols-regex '^xa_.*$'
to the LDFLAGS. I did it the same way, it's used with the OMX stuff, see the
attached patch "0001-Build-libxatracker-pass-export-symbols-regex-to-link.patch"

As far as my build goes, I'm using the following configure options (basically
what Debian's mesa package uses, except, that I'm using a development snapshot
of LLVM 3.5, and compile LLVM in statically – I was unable to configure Mesa
against Debian's LLVM package for dynamic linking, unless I would patch the
configure.ac):
configure --prefix=/usr --mandir=\${prefix}/share/man \
  --infodir=\${prefix}/share/info --sysconfdir=/etc \
  --libdir=\${prefix}/lib/x86_64-linux-gnu \
  --localstatedir=/var --disable-silent-rules \
  --build=x86_64-linux-gnu --enable-dri --with-dri-drivers=" nouveau i915 i965
r200 radeon" \
  --with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri \

--with-dri-searchpath='/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri'
 \
  --enable-osmesa --enable-glx-tls --enable-shared-glapi --enable-texture-float
--enable-xa \
  --disable-xvmc --enable-driglx-direct --enable-dri3 --with-egl-platforms="x11
drm wayland" \
  --enable-opencl --enable-opencl-icd --enable-gallium-llvm --enable-vdpau \
  --with-gallium-drivers=" nouveau svga swrast r600 r300 radeonsi" 
--enable-gles1 \
  --enable-gles2 --enable-openvg --enable-gallium-egl \
  CFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -Wall" \
  CPPFLAGS="-D_FORTIFY_SOURCE=2" \
  CXXFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -Wall" \
  FFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4" \
  GCJFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4"
LDFLAGS="-Wl,-z,relro"  \
  --disable-llvm-shared-libs \
  ac_cv_path_LLVM_CONFIG=llvm-config-3.5

LLVM is at SVN:trunk/r204915 (the packages from <http://llvm.org/apt>, which are
maintained by Debian's LLVM maintainer).

> Btw. feel free Cc the ML as other people may have spotted/resolved this
> (kind of) issue(s). Even if I cocked up something I do not mind being called
> out :)

Done.

> ...
> Hmm I cannot see how any of the commits in that range may be causing such
> problem. Can you please confirm that it's not a "stale file" issue - git
> clean -nxd should help out.

Yes, I'm sure of that. I'm always building in a clean chroot with pbuilder. No
stale files around.

> P.S. Why does BlunderBird throws a hissy fit when replying to a signed emails.
> It's not like it's a "new and unknown thing". Am I asking for too much ?

Do you have Enigmail installed?

Cheers,
Kai



-- 

Kai Wa

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

2019-01-19 Thread 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

[Mesa-dev] [PATCH] Fix commit f9caabe8f1bff86d19b53d9ecba5c72b238d9e23

2015-09-12 Thread Kai Wasserbäch

One place in r600_llvm.c was forgotten when replacing
R600_UCP_CONST_BUFFER with R600_BUFFER_INFO_CONST_BUFFER.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91985
CC: Dave Airlie 
Signed-off-by: Kai Wasserbäch 
---

Hi,
this fixes a FTBFS after the commit mentioned above. If you accept this patch,
please commit it for me, as I do not have commit access.

Cheers,
Kai

 src/gallium/drivers/r600/r600_llvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/r600_llvm.c 
b/src/gallium/drivers/r600/r600_llvm.c
index 3362fd0..372cd41 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -22,7 +22,7 @@
 #if defined R600_USE_LLVM || defined HAVE_OPENCL
 
 #define CONSTANT_BUFFER_0_ADDR_SPACE 8
-#define CONSTANT_BUFFER_1_ADDR_SPACE (CONSTANT_BUFFER_0_ADDR_SPACE + 
R600_UCP_CONST_BUFFER)
+#define CONSTANT_BUFFER_1_ADDR_SPACE (CONSTANT_BUFFER_0_ADDR_SPACE + 
R600_BUFFER_INFO_CONST_BUFFER)
 #define LLVM_R600_BUFFER_INFO_CONST_BUFFER \
(CONSTANT_BUFFER_0_ADDR_SPACE + R600_BUFFER_INFO_CONST_BUFFER)
 
-- 
2.5.1

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

Re: [Mesa-dev] [PATCH 06/11] st/mesa: add atomic buffer support

2015-09-27 Thread Kai Wasserbäch

Ilia Mirkin wrote on 27.09.2015 08:33:
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/Makefile.sources|   1 +
>  src/mesa/program/ir_to_mesa.cpp  |   4 +-
>  src/mesa/state_tracker/st_atom.c |   5 +
>  src/mesa/state_tracker/st_atom.h |   5 +
>  src/mesa/state_tracker/st_atom_atomicbuf.c   | 151 
> +++
>  src/mesa/state_tracker/st_cb_bufferobjects.c |   3 +
>  src/mesa/state_tracker/st_context.c  |   1 +
>  src/mesa/state_tracker/st_context.h  |   1 +
>  src/mesa/state_tracker/st_extensions.c   |  15 +++
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 133 +--
>  10 files changed, 310 insertions(+), 9 deletions(-)
>  create mode 100644 src/mesa/state_tracker/st_atom_atomicbuf.c
> 
> [...]
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> index 633e90f..28c9637 100644
> --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> @@ -261,6 +261,8 @@ public:
> [...]
>  
>  void
> +glsl_to_tgsi_visitor::visit_atomic_counter_intrinsic(ir_call *ir)
> +{
> +   const char *callee = ir->callee->function_name();
> +   ir_dereference *deref = static_cast(
> +  ir->actual_parameters.get_head());
> +   ir_variable *location = deref->variable_referenced();
> +
> +   /* XXX use accept */
> +   st_src_reg buffer(
> + PROGRAM_SAMPLER, location->data.binding /* XXX */, 
> GLSL_TYPE_ATOMIC_UINT);
> +
> +   /* Calculate the surface offset */
> +   st_src_reg offset;
> +   ir_dereference_array *deref_array = deref->as_dereference_array();
> +
> +   if (deref_array) {
> +  offset = get_temp(glsl_type::uint_type);
> +
> +  deref_array->array_index->accept(this);
> +
> +  emit_asm(ir, TGSI_OPCODE_MUL, st_dst_reg(offset),
> +   this->result, st_src_reg_for_int(ATOMIC_COUNTER_SIZE));
> +  emit_asm(ir, TGSI_OPCODE_ADD, st_dst_reg(offset),
> +   offset, st_src_reg_for_int(location->data.atomic.offset));
> +   } else {
> +  offset = st_src_reg_for_int(location->data.atomic.offset);
> +   }
> +
> +   ir->return_deref->accept(this);
> +   st_dst_reg dst(this->result);
> +   dst.writemask = WRITEMASK_X;
> +
> +   glsl_to_tgsi_instruction *inst;
> +
> +   if (!strcmp("__intrinsic_atomic_read", callee)) {
> +  inst = emit_asm(ir, TGSI_OPCODE_LOAD, dst, offset);
> +  inst->buffer = buffer;
> +   } else if (!strcmp("__intrinsic_atomic_increment", callee)) {
> +  inst = emit_asm(ir, TGSI_OPCODE_ATOMUADD, dst, offset,
> +  st_src_reg_for_int(1));
> +  inst->buffer = buffer;
> +   } else if (!strcmp("__intrinsic_atomic_predecrement", callee)) {
> +  inst = emit_asm(ir, TGSI_OPCODE_ATOMUADD, dst, offset,
> +  st_src_reg_for_int(-1));
> +  inst->buffer = buffer;
> +  emit_asm(ir, TGSI_OPCODE_ADD, dst, this->result, 
> st_src_reg_for_int(-1));
> +   }
> +}
> +
> +void
>  glsl_to_tgsi_visitor::visit(ir_call *ir)
>  {
> glsl_to_tgsi_instruction *call_inst;
> ir_function_signature *sig = ir->callee;
> +   const char *callee = sig->function_name();
> function_entry *entry = get_function_signature(sig);
> int i;
>  
> +   /* Filter out intrinsics */
> +   if (!strcmp("__intrinsic_atomic_read", callee) ||
> +   !strcmp("__intrinsic_atomic_increment", callee) ||
> +   !strcmp("__intrinsic_atomic_predecrement", callee)) {
> +  visit_atomic_counter_intrinsic(ir);
> +  return;
> +   }

You're doing the same string comparison two times in a row (if you match here).
Wouldn't it be cheaper to cache the result und pass it in to
visit_atomic_counter_intrinsic()?

I was thinking of something like

unsigned atomic_intr_type = 0;
if(!strcmp("__intrinsic_atomic_read", callee))
  atomic_intr_type = 1;
else if(!strcmp("__intrinsic_atomic_increment", callee))
  atomic_intr_type = 2;
else if(!strcmp("__intrinsic_atomic_predecrement", callee))
  atomic_intr_type = 3;

if(atomic_intr_type) {
  visit_atomic_counter_intrinsic(ir, atomic_intr_type);
  return;
}

Obviously visit_atomic_counter_intrinsic() would need to take that parameter and
then replace the respective if block with a check for the right code.


This is just a suggestion and I might be totally missing something here. ;-)

Cheers,
Kai



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

Re: [Mesa-dev] [PATCH 4/4] st/mesa: enable AoA for gallium drivers reporting GLSL 1.30

2016-02-05 Thread Kai Wasserbäch

Hey Dave,
can you mention

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92059

A large part of the problems with Middle-earth: Shadow of Mordor stem from
radeonsi not having AoA, which should be fixed by this, right?

Cheers,
Kai


Dave Airlie wrote on 05.02.2016 04:40:
> From: Dave Airlie 
> 
> Signed-off-by: Dave Airlie 
> ---
>  docs/GL3.txt   | 2 +-
>  docs/relnotes/11.2.0.html  | 1 +
>  src/mesa/state_tracker/st_extensions.c | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index 7623ada..44a3ec7 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -149,7 +149,7 @@ GL 4.2, GLSL 4.20:
>  
>  GL 4.3, GLSL 4.30:
>  
> -  GL_ARB_arrays_of_arrays  DONE (i965)
> +  GL_ARB_arrays_of_arrays  DONE (all drivers 
> that support GLSL 1.30)
>GL_ARB_ES3_compatibility DONE (all drivers 
> that support GLSL 3.30)
>GL_ARB_clear_buffer_object   DONE (all drivers)
>GL_ARB_compute_shaderDONE (i965)
> diff --git a/docs/relnotes/11.2.0.html b/docs/relnotes/11.2.0.html
> index 404e293..348a782 100644
> --- a/docs/relnotes/11.2.0.html
> +++ b/docs/relnotes/11.2.0.html
> @@ -44,6 +44,7 @@ Note: some of the new features are only available with 
> certain drivers.
>  
>  
>  
> +GL_ARB_arrays_of_arrays on all gallium drivers that provide GLSL 
> 1.30
>  GL_ARB_base_instance on freedreno/a4xx
>  GL_ARB_compute_shader on i965
>  GL_ARB_copy_image on r600
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index d066784..c8a42a2 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -805,6 +805,7 @@ void st_init_extensions(struct pipe_screen *screen,
>}
>  
>extensions->EXT_shader_integer_mix = GL_TRUE;
> +  extensions->ARB_arrays_of_arrays = GL_TRUE;
> } else {
>/* Optional integer support for GLSL 1.2. */
>if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
> 



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

Re: [Mesa-dev] [PATCH] mesa/extensions: Fix NVX_gpu_memory_info lexicographical order.

2016-02-06 Thread Kai Wasserbäch

Hey Vinson,
I would say the test is wrong. If I sort as a human, "NV_" comes before "NVX_".

And running this through sort (the tool), it agrees:

$ echo -e "NVX_gpu_memory_info\nNV_blend_square" | sort -d
NV_blend_square
NVX_gpu_memory_info

From src/mesa/main/tests/mesa_extensions.cpp I'm seeing that you don't actually
check the dictionary order but rather the character value. So it depends whether
you want to make humans or a simple test happy. ;-) But that's to decide for
people more involved in Mesa.

Cheers,
Kai


Vinson Lee wrote on 06.02.2016 08:30:
> Fixes MesaExtensionsTest.AlphabeticallySorted.
> 
> Fixes: 1d79b9958090 ("mesa: implement GL_NVX_gpu_memory_info (v2)")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94016
> Signed-off-by: Vinson Lee 
> ---
>  src/mesa/main/extensions_table.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index ded6f2c..d1e3a99 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -273,6 +273,8 @@ EXT(MESA_texture_signed_rgba, 
> EXT_texture_snorm
>  EXT(MESA_window_pos , dummy_true 
> , GLL,  x ,  x ,  x , 2000)
>  EXT(MESA_ycbcr_texture  , MESA_ycbcr_texture 
> , GLL, GLC,  x ,  x , 2002)
>  
> +EXT(NVX_gpu_memory_info , NVX_gpu_memory_info
> , GLL, GLC,  x ,  x , 2013)
> +
>  EXT(NV_blend_square , dummy_true 
> , GLL,  x ,  x ,  x , 1999)
>  EXT(NV_conditional_render   , NV_conditional_render  
> , GLL, GLC,  x ,  x , 2008)
>  EXT(NV_depth_clamp  , ARB_depth_clamp
> , GLL, GLC,  x ,  x , 2001)
> @@ -293,7 +295,6 @@ EXT(NV_texture_barrier  , 
> NV_texture_barrier
>  EXT(NV_texture_env_combine4 , NV_texture_env_combine4
> , GLL,  x ,  x ,  x , 1999)
>  EXT(NV_texture_rectangle, NV_texture_rectangle   
> , GLL,  x ,  x ,  x , 2000)
>  EXT(NV_vdpau_interop, NV_vdpau_interop   
> , GLL, GLC,  x ,  x , 2010)
> -EXT(NVX_gpu_memory_info , NVX_gpu_memory_info
> , GLL, GLC,  x ,  x , 2013)
>  
>  EXT(OES_EGL_image   , OES_EGL_image  
> , GLL, GLC, ES1, ES2, 2006) /* FIXME: Mesa expects GL_OES_EGL_image 
> to be available in OpenGL contexts. */
>  EXT(OES_EGL_image_external  , OES_EGL_image_external 
> ,  x ,  x , ES1, ES2, 2010)
> 



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] i965/build: Fix FTBFS due to incorrect variable initialisation

2016-04-21 Thread Kai Wasserbäch

Broken since b27c85c4c089109339fc37135d0a4d2574024632

Cc: Rob Herring 
Cc: Emil Velikov 
Signed-off-by: Kai Wasserbäch 
---

Hi,
without this I'm getting error during autoreconf:
 src/mesa/drivers/dri/i965/Makefile.am:57: error: BUILT_SOURCES must be set 
with '=' before using '+='
 src/mesa/drivers/dri/i965/Makefile.am:58: error: CLEANFILES must be set with 
'=' before using '+='

Please push this for me, if you accept it.

Cheers,
Kai


 src/mesa/drivers/dri/i965/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index c7f055d..ba3aa26 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -54,8 +54,8 @@ libi965_compiler_la_SOURCES = \
$(i965_compiler_FILES) \
$(i965_compiler_GENERATED_FILES)
 
-BUILT_SOURCES += $(i965_compiler_GENERATED_FILES)
-CLEANFILES += $(BUILT_SOURCES)
+BUILT_SOURCES = $(i965_compiler_GENERATED_FILES)
+CLEANFILES = $(BUILT_SOURCES)
 
 TEST_LIBS = \
libi965_compiler.la \
-- 
2.8.0.rc3

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

Re: [Mesa-dev] [PATCH 5/5] clover: Add environment variables for dumping kernel code v2

2014-10-09 Thread Kai Wasserbäch

Tom Stellard wrote on 09.10.2014 17:07:
> There are two debug variables:
> 
> CLOVER_DEBUG which you can set to any combination of llvm,clc,asm
> (separated by commas) to dump llvm IR, OpenCL C, and native assembly.
> 
> CLOVER_DEBUG_FILE which you can set to a file name for dumping output
> instead of stderr.  If you set this variable, the output will be split
> into three separate files with different suffixes: .cl for OpenCL C,
> .ll for LLVM IR, and .asm for native assembly.  Note that when data
> is written, it is always appended to the files.
> 
> v2:
>   - Code cleanups
>   - Add CLOVER_DEBUG_FILE environment variable for dumping to a file.
> ---
>  .../state_trackers/clover/llvm/invocation.cpp  | 92 
> +++---
>  1 file changed, 82 insertions(+), 10 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 6349769..b7edcac 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -61,6 +61,8 @@
>  #include 
>  #include 
>  #include 
> +#include "llvm/Transforms/Utils/Cloning.h"

Shouldn't this be: #include 

> +

Is the additional blank line required/intended?


Cheers,
Kai



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

Re: [Mesa-dev] [PATCH 00/14] [v2] Famous Gallium Nine

2014-10-21 Thread Kai Wasserbäch

Hello,
according to  DRI3 is mandatory. But AFAICT you only
enforce "has Gallium3D drivers" in the configure checks introduced in
.

I would find it better, if configure died, in case I'm trying to build something
that's not going to work.

Cheers,
Kai

P.S.: Sorry for answering to the cover letter, but I didn't see the patch
referenced above in my inbox.


David Heidelberger wrote on 20.10.2014 14:37:
> Hello.
> 
> Sending second and improved set of Nine patches.
> 
>  - few of them are dropped
>[PATCH 06/16] gallium: add blending to pipe blit (only for Nouveau)
>[PATCH 07/16] util: dlopen change to RTLD_NOW and LOCAL (not needed)
>  - some of them are already improved (v2)
>  - there was few lines of code leaked between commits,
>which are now fixed
> 
> You can get all important information about Nine from [1].
> Because Nine commit is too big, you can check all commits
> including big (about 1M) Nine commit here [2].
> 
> I think there maybe lot of places for improvements and hidden bugs,
> so please review carefully and we'll try fix and improve anything
> which will be needed :)
> 
> [1] https://wiki.ixit.cz/d3d9 (used self-signed cert)
> [2] https://github.com/iXit/Mesa-3D/commits/for-upstream-2
> 
> Axel Davy (2):
>   nine: Add drirc options (v2)
>   nine: Implement threadpool
> 
> Christoph Bumiller (10):
>   tgsi/ureg: add ureg_UARL shortcut
>   mesa/gallium: API settings / rasterization rules
>   gallium/drivers: use API settings / rasterization rules
>   winsys/sw/wrapper: hook up is_displaytarget_format_supported
>   gallium/auxiliary: implement sw_probe_wrapped
>   gallium/draw: support hack to disable clipping (v2)
>   configure: add configurable pipe-driver location
>   gallium/auxiliary: add inc and dec alternative with return
>   gallium/auxiliary: add contained and rect checks (v2)
>   gallium/auxiliary: add dump functions for Nine
> 
> David Heidelberger (1):
>   gallium/auxiliary: Prefer intrinsics to handrolled atomic ops for
> Linux (v2)
> 
> Joakim Sindholt (1):
>   nine: Add state tracker nine for Direct3D9
> 
>  [diffstat]



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

Re: [Mesa-dev] [PATCH 00/14] [v2] Famous Gallium Nine

2014-10-23 Thread Kai Wasserbäch

Axel Davy wrote on 22.10.2014 07:41:
> On 21/10/2014 18:30, Kai Wasserbäch wrote :
>> Hello,
>> according to <https://wiki.ixit.cz/d3d9> DRI3 is mandatory. But AFAICT you 
>> only
>> enforce "has Gallium3D drivers" in the configure checks introduced in
>> <https://github.com/iXit/Mesa-3D/commit/9671cfd9bdad5c310b34c57befcfd7c43034b925>.
>>
>>
>> I would find it better, if configure died, in case I'm trying to build 
>> something
>> that's not going to work.
>>
>> Cheers,
>> Kai
>>
> Gallium nine doesn't depend on DRI3.
> However for now, the implementation Wine side that makes use of it uses DRI3.
> The interface between Mesa and Wine makes it possible to implement non-DRI3
> backends.

Ok; maybe change the Wiki then?

> Thus I think it's ok the Mesa part builds, even if no non-DRI3 backend exists
> yet and that DRI3 is not available on the system.

Yes, that's fine, though maybe some warning could be nice.

Cheers,
Kai



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

Re: [Mesa-dev] [PATCH RFC 1/1] configure: Drop LLVM_COMPONENTS

2014-10-23 Thread Kai Wasserbäch

You can have my
Tested-by: Kai Wasserbäch 
for that, since it is essentially the same as attachment 108315 from bug 85380.
Please add a reference to that bug report.

And now I abuse this to send a ping for the fix for bug 70410 (there should be a
patch for this on the list): can we add "--system-libs" to the llvm-config
invocation for LLVM_LIBS as well?

Thanks, Jan, for fixing this so quickly!

Cheers,
Kai


Jan Vesely wrote on 23.10.2014 21:58:
> Use -Wl,--as-needed instead
> This should fix the problem of using llvm split libraries.
> Since the component split may change it's safer to list everything and let
> linker filter out the unneeded ones.
> 
> 
> CC: Tom Stellard 
> CC: Emil Velikov 
> CC: k...@dev.carbon-project.org
> Signed-off-by: Jan Vesely 
> ---
> I'm not sure whether -Wl,--as-needed is supported by all build systems that 
> emsa targets, or I need to add a test for it.
> 
>  configure.ac | 40 +++-
>  1 file changed, 7 insertions(+), 33 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 03f1bca..39dfd32 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1694,7 +1694,7 @@ if test "x$enable_gallium_llvm" = xyes; then
>  
>  if test "x$LLVM_CONFIG" != xno; then
>  LLVM_VERSION=`$LLVM_CONFIG --version | egrep -o '^[[0-9.]]+'`
> -LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
> +LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags -Wl,--as-needed`
>  LLVM_BINDIR=`$LLVM_CONFIG --bindir`
>  LLVM_CPPFLAGS=`strip_unwanted_llvm_flags "$LLVM_CONFIG --cppflags"`
>  LLVM_CFLAGS=$LLVM_CPPFLAGS   # CPPFLAGS seem to be sufficient
> @@ -1724,29 +1724,6 @@ if test "x$enable_gallium_llvm" = xyes; then
>  AC_MSG_ERROR([LLVM 
> $LLVM_REQUIRED_VERSION_MAJOR.$LLVM_REQUIRED_VERSION_MINOR or newer is 
> required])
>  fi
>  
> -LLVM_COMPONENTS="engine bitwriter"
> -if $LLVM_CONFIG --components | grep -qw 'mcjit'; then
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} mcjit"
> -fi
> -
> -if test "x$enable_opencl" = xyes; then
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} ipo linker instrumentation"
> -# LLVM 3.3 >= 177971 requires IRReader
> -if $LLVM_CONFIG --components | grep -qw 'irreader'; then
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} irreader"
> -fi
> -# LLVM 3.4 requires Option
> -if $LLVM_CONFIG --components | grep -qw 'option'; then
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} option"
> -fi
> -# Current OpenCL/Clover and LLVM 3.5 require ObjCARCOpts and 
> ProfileData
> -if $LLVM_CONFIG --components | grep -qw 'objcarcopts'; then
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} objcarcopts"
> -fi
> -if $LLVM_CONFIG --components | grep -qw 'profiledata'; then
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} profiledata"
> -fi
> -fi
>  DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VERSION_INT 
> -DLLVM_VERSION_PATCH=$LLVM_VERSION_PATCH"
>  MESA_LLVM=1
>  
> @@ -1873,7 +1850,6 @@ radeon_llvm_check() {
>sources with the --enable-experimental-targets=R600
>configure flag])
>  fi
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} r600 bitreader ipo"
>  NEED_RADEON_LLVM=yes
>  if test "x$have_libelf" != xyes; then
> AC_MSG_ERROR([$1 requires libelf when using llvm])
> @@ -1916,14 +1892,10 @@ if test -n "$with_gallium_drivers"; then
>  gallium_require_drm_loader
>  if test "x$enable_r600_llvm" = xyes -o "x$enable_opencl" = xyes; 
> then
>  radeon_llvm_check "r600g"
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} bitreader asmparser"
>  fi
>  if test "x$enable_r600_llvm" = xyes; then
>  USE_R600_LLVM_COMPILER=yes;
>  fi
> -if test "x$enable_opencl" = xyes; then
> -LLVM_COMPONENTS="${LLVM_COMPONENTS} bitreader asmparser"
> -fi
>  ;;
>  xradeonsi)
>  HAVE_GALLIUM_RADEONSI=yes
> @@ -1969,16 +1941,18 @@ if test -n "$with_gallium_drivers"; then
>  done
>  fi
>  
> -dnl Set LLVM_LIBS - This is done after the driver configuration so
> -dnl that drivers can add add

Re: [Mesa-dev] [PATCH WIP 1/1] configure: include llvm systemlibs when using static llvm

2014-10-24 Thread Kai Wasserbäch

Hi Jan,
Jan Vesely wrote on 24.10.2014 19:03:
> -Wl,--exclude-libs prevents automatic export of symbols
> 
> 
> CC: Kai Wasserbach 
> CC: Emil Velikov 
> Signed-off-by: Jan Vesely 
> ---
> 
> Kai,
> can you try this patch with your setup, and check whether LLVM symbols are
> exported from mesa library? (and it's still working)

with this patch applied on top of attachment 108315, I get the following build
error:
> /usr/bin/ld: cannot find exclude-libs: No such file or directory
> collect2: error: ld returned 1 exit status
> Makefile:894: recipe for target 'pipe_r600.la' failed
> make[4]: *** [pipe_r600.la] Error 1
> make[4]: *** Waiting for unfinished jobs
> /usr/bin/ld: cannot find exclude-libs: No such file or directory
> collect2: error: ld returned 1 exit status
> Makefile:900: recipe for target 'pipe_swrast.la' failed
> make[4]: *** [pipe_swrast.la] Error 1
> /usr/bin/ld: cannot find exclude-libs: No such file or directory
> collect2: error: ld returned 1 exit status
> Makefile:903: recipe for target 'pipe_vmwgfx.la' failed
> make[4]: *** [pipe_vmwgfx.la] Error 1
> /usr/bin/ld: cannot find exclude-libs: No such file or directory
> collect2: error: ld returned 1 exit status
> Makefile:897: recipe for target 'pipe_radeonsi.la' failed
> make[4]: *** [pipe_radeonsi.la] Error 1
> /usr/bin/ld: cannot find exclude-libs: No such file or directory
> collect2: error: ld returned 1 exit status
> Makefile:888: recipe for target 'pipe_nouveau.la' failed
> make[4]: *** [pipe_nouveau.la] Error 1
> /usr/bin/ld: cannot find exclude-libs: No such file or directory
> collect2: error: ld returned 1 exit status
> Makefile:891: recipe for target 'pipe_r300.la' failed
> make[4]: *** [pipe_r300.la] Error 1
> make[4]: Leaving directory 
> '/tmp/buildd/mesa-10.4~20141024.1.git5fc0e11053/build/dri/src/gallium/targets/pipe-loader'
> Makefile:558: recipe for target 'all-recursive' failed
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory 
> '/tmp/buildd/mesa-10.4~20141024.1.git5fc0e11053/build/dri/src/gallium'
> Makefile:521: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory 
> '/tmp/buildd/mesa-10.4~20141024.1.git5fc0e11053/build/dri/src'
> Makefile:589: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory 
> '/tmp/buildd/mesa-10.4~20141024.1.git5fc0e11053/build/dri'
> debian/rules:204: recipe for target 'debian/stamp/x86_64-linux-gnu-build-dri' 
> failed
> make: *** [debian/stamp/x86_64-linux-gnu-build-dri] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2

You can find the full build log attached to this e-mail.

Cheers,
Kai


mesa.amd64.priv.log.xz
Description: application/xz


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

Re: [Mesa-dev] [PATCH WIP 1/1] configure: include llvm systemlibs when using static llvm

2014-10-26 Thread Kai Wasserbäch

Hi Jan,
Jan Vesely wrote on 24.10.2014 23:30:
> On Fri, 2014-10-24 at 22:42 +0200, Kai Wasserbäch wrote:
>> Jan Vesely wrote on 24.10.2014 19:03:
>>> -Wl,--exclude-libs prevents automatic export of symbols
>>>
>>>
>>> CC: Kai Wasserbach 
>>> CC: Emil Velikov 
>>> Signed-off-by: Jan Vesely 
>>> ---
>>>
>>> Kai,
>>> can you try this patch with your setup, and check whether LLVM symbols are
>>> exported from mesa library? (and it's still working)
>>
>> with this patch applied on top of attachment 108315, I get the following 
>> build
> 
> yeah, that's because the correct form should be "-Wl,--exclude-libs
> ALL",
> sorry about that

this still fails with (though I might have done something wrong in changing the
patch):
> //usrusr//binbin//ld:ld :cannot  cannotfind  findrelro : relro:No  Nosuch  
> suchfile  fileor  ordirectory 
> directory
> /usr/bin/ld: cannot find relro: No such file or directory
> /usr/bin/ld: cannot find relro: No such file or directory
> /usr/bin/ld: cannot find relro: No such file or directory
> /usr/bin/ld: cannot find relro: No such file or directory
> collect2: error: ld returned 1 exit status
> collect2: error: ld returned 1 exit status
> collect2: error: ld returned 1 exit status
> collect2: error: ld returned 1 exit status
> collect2: error: ld returned 1 exit status
> collect2: error: ld returned 1 exit status
> Makefile:900: recipe for target 'pipe_swrast.la' failed
> make[4]: *** [pipe_swrast.la] Error 1
> make[4]: *** Waiting for unfinished jobs
> Makefile:888: recipe for target 'pipe_nouveau.la' failed
> make[4]: *** [pipe_nouveau.la] Error 1
> Makefile:903: recipe for target 'pipe_vmwgfx.la' failed
> make[4]: *** [pipe_vmwgfx.la] Error 1
> Makefile:897: recipe for target 'pipe_radeonsi.la' failed
> make[4]: *** [pipe_radeonsi.la] Error 1
> Makefile:891: recipe for target 'pipe_r300.la' failed
> make[4]: *** [pipe_r300.la] Error 1
> Makefile:894: recipe for target 'pipe_r600.la' failed
> make[4]: *** [pipe_r600.la] Error 1
> make[4]: Leaving directory 
> '/tmp/buildd/mesa-10.4~20141024.1.git5fc0e11053/build/dri/src/gallium/targets/pipe-loader'
> Makefile:558: recipe for target 'all-recursive' failed
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory 
> '/tmp/buildd/mesa-10.4~20141024.1.git5fc0e11053/build/dri/src/gallium'
> Makefile:521: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory 
> '/tmp/buildd/mesa-10.4~20141024.1.git5fc0e11053/build/dri/src'
> Makefile:589: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory 
> '/tmp/buildd/mesa-10.4~20141024.1.git5fc0e11053/build/dri'
> debian/rules:204: recipe for target 'debian/stamp/x86_64-linux-gnu-build-dri' 
> failed
> make: *** [debian/stamp/x86_64-linux-gnu-build-dri] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> E: Failed autobuilding of package

I've attached the full build log and the updated patch.

Cheers,
Kai


mesa.amd64.priv.log.xz
Description: application/xz
From - Fri Oct 24 22:18:06 2014
X-Mozilla-Keys: nonjunk $label1
Return-Path: 
Delivered-To: k...@dev.carbon-project.org
Received: from localhost (localhost [127.0.0.1])
	by blackmesa.kw-serverwartung.de (Postfix) with ESMTP id DB9237B8125
	for ; Fri, 24 Oct 2014 17:04:19 + (UTC)
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 required=6.31 tests=[BAYES_50=0.8]
	autolearn=disabled
Received: from blackmesa.kw-serverwartung.de ([127.0.0.1])
	by localhost (blackmesa.kw-serverwartung.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ekSZzeX1iK0v for ;
	Fri, 24 Oct 2014 17:03:36 + (UTC)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by blackmesa.kw-serverwartung.de (Postfix) with ESMTPS id DBA2B7B8123
	for ; Fri, 24 Oct 2014 17:03:15 + (UTC)
Received: by mail-qg0-f45.google.com with SMTP id q107so1304450qgd.4
for ; Fri, 24 Oct 2014 10:03:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:sender:from:to:cc:subject:date:message-id;
bh=rp7WBeN8JtJiQAtYFq+yuZpe2gtCDSJ4n+5pk9pchxo=;
b=EpTog9PGhLxsepsEWpx9Ln+sNL6e42C3oKMsDQ5sqKt27x28sS90TguaOh1ggQlRz1
 fukEXmvq26L4x1+4LKRbNBkDFAEMbRx8QWbwzti6e01JcPfSuk5HoDAcKqqWaHRRkBqg
 6hGjVrFRJGJ6jHhpsN1mTIsfNPVtciYBuIpAd

Re: [Mesa-dev] [PATCH WIP 1/1] configure: include llvm systemlibs when using static llvm

2014-10-27 Thread Kai Wasserbäch

Hi Jan,
Jan Vesely wrote on 26.10.2014 20:36:
> On Fri, 2014-10-24 at 23:54 +, Emil Velikov wrote:
>> On 24/10/14 17:03, Jan Vesely wrote:
>>> -Wl,--exclude-libs prevents automatic export of symbols
>>>
>>>
>>> CC: Kai Wasserbach 
>>> CC: Emil Velikov 
>>> Signed-off-by: Jan Vesely 
>>> ---
>>>
>>> Kai,
>>> can you try this patch with your setup, and check whether LLVM symbols are
>>> exported from mesa library? (and it's still working)
>>>
>>> Emil,
>>> would it help to have --exclude-libs ALL enabled globally?
>>>
>> Haven't really looked up on the documentation about it, yet there should
>> be no (unneeded) exported symbols thanks to the version scripts.
>> As such I'm not entirely sure what this patch (attempts to) resolve :(
> 
> you are right. I don't know why I thought it was still a problem.
> In that case the attached patch should fix compiling with llvm static
> libs (#70410)

this patch on top of attachment 108315 from bug 85380 gives a successful build
with current Git HEAD (1a170980a0) and LLVM r220648 from SVN.

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

Cheers,
Kai


mesa.amd64.upl.log.xz
Description: application/xz


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

Re: [Mesa-dev] tinderbox build regression

2014-11-16 Thread Kai Wasserbäch

Dear Dave,
Dave Airlie wrote on 16.11.2014 06:20:
> no idea but I'm picking Emil as the culprit!

I've seen the same failure, but a more recent LLVM 3.6 fixed it for me. I can
report LLVM SVN r222082 as working.

Cheers,
Kai



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

Re: [Mesa-dev] tinderbox build regression

2014-11-16 Thread Kai Wasserbäch

Kai Wasserbäch wrote on 16.11.2014 11:49:
> Dear Dave,
> Dave Airlie wrote on 16.11.2014 06:20:
>> no idea but I'm picking Emil as the culprit!
> 
> I've seen the same failure, but a more recent LLVM 3.6 fixed it for me. I can
> report LLVM SVN r222082 as working.

Nah, sorry. I was wrong. You've seen bug 86330, I had a similar looking but
different build failure, that was due to the LLVM version (see Tom Stellard's
reversion of cd93d82ba9ec8cd8e4f54bbee16d7b47c542de71 in
0cae7ea2719a939cf91de03a1bfeeeca08ec98a4).

Sorry for the noise.

Cheers,
Kai



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

Re: [Mesa-dev] Statically linking libstdc++ and libgcc

2015-03-12 Thread Kai Wasserbäch

Michel Dänzer wrote on 12.03.2015 08:15:
> On 11.03.2015 05:07, Vivek Dasmohapatra wrote:
>> Hi - As you probably already know, there can only be one version of
>> libstdc++.so in your runtime link chain - This is usually not a problem,
>> but when things are linked against the Steam runtime (for example), they
>> can end up with two - one from the steam runtime, and one pulled in via
>> the mesa dri libs from the OS/distribution.
> 
> How can that happen? The problems I've seen related to this were usually
> because Steam overrides the system libstdc++ / libgcc with older
> versions, which breaks other system libraries.
> 
> Can somebody please tell Valve that doing that is not okay? And it's not
> necessary either. Each library can be compared to the system version
> individually and only overridden when necessary, e.g. by putting each
> library into its own directory and only adding the necessary directories
> to $LD_LIBRARY_PATH. E.g. VMware use this approach in their products.

This.

Though I'd actually like Valve to go even farther and at least start creating
dummy dependency packages for things they install. This way, they can ensure all
dependencies are met and they only have to ship closed-source stuff. Bonus
side-effect: only one copy of a library present, which gets updated by the
central package manager. If they use something like PackageKit they shouldn't
even have too much problems with the DEB/RPM split. Since you could generate
these dependencies automatically – SteamOS (aka Debian 7.x) is their base after
all, anything has to run there – that wouldn't constitute too much of a
maintenance burden either. (Obviously: true packages with a full build service
behind it, would be best, but I don't expect that to ever happen.) But I guess
everybody could be (mostly) happy with what Michel suggested.

And in addition to what has been said before: I wouldn't expect such a change to
take root in any (sane) distribution. So this change either turns into work for
the distributions (reverting the change) or the relevant configure option will
always be set to "disable".

Cheers,
Kai

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

Re: [Mesa-dev] [PATCH] gallium/swr: explicity use llvm legacy FunctionPassManager

2016-03-03 Thread Kai Wasserbäch

Tim Rowley wrote on 03.03.2016 18:20:
> swr uses the legacy FunctionPassManager for llvm-3.6 compatibility,
> but a change to llvm headers in 3.9 includes the new version as well.
> Explicity use the legacy version to prevent ambiguity.
> ---
>  src/gallium/drivers/swr/rasterizer/jitter/JitManager.h |  1 -
>  src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp|  8 +++-
>  src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp| 14 
> --
>  .../drivers/swr/rasterizer/jitter/streamout_jit.cpp|  8 +++-
>  4 files changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h 
> b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
> index c974a61..0f484b7 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
> @@ -64,7 +64,6 @@
>  #include "llvm/PassManager.h"
>  #else
>  #include "llvm/IR/LegacyPassManager.h"
> -using namespace llvm::legacy;
>  #endif
>  
>  #include "llvm/CodeGen/Passes.h"
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp 
> b/src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp
> index 954524a..16ccabf 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/blend_jit.cpp
> @@ -717,7 +717,13 @@ struct BlendJit : public Builder
>  
>  JitManager::DumpToFile(blendFunc, "");
>  
> -FunctionPassManager passes(JM()->mpCurrentModule);
> +#if LLVM_VERISON_MAJOR == 3 && LLVM_VERSION_MINOR == 6

Why not something like

#IF HAVE_LLVM == 0x0306

like radeonsi is using? (Same applies below.)

Cheers,
Kai


> +FunctionPassManager
> +#else
> +llvm::legacy::FunctionPassManager
> +#endif
> +   passes(JM()->mpCurrentModule);
> +
>  passes.add(createBreakCriticalEdgesPass());
>  passes.add(createCFGSimplificationPass());
>  passes.add(createEarlyCSEPass());
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp 
> b/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
> index c5a180e..4965f55 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
> @@ -174,7 +174,12 @@ Function* FetchJit::Create(const FETCH_COMPILE_STATE& 
> fetchState)
>  
>  verifyFunction(*fetch);
>  
> -FunctionPassManager setupPasses(JM()->mpCurrentModule);
> +#if LLVM_VERISON_MAJOR == 3 && LLVM_VERSION_MINOR == 6
> +FunctionPassManager
> +#else
> +llvm::legacy::FunctionPassManager
> +#endif
> +   setupPasses(JM()->mpCurrentModule);
>  
>  ///@todo We don't need the CFG passes for fetch. (e.g. 
> BreakCriticalEdges and CFGSimplification)
>  setupPasses.add(createBreakCriticalEdgesPass());
> @@ -186,7 +191,12 @@ Function* FetchJit::Create(const FETCH_COMPILE_STATE& 
> fetchState)
>  
>  JitManager::DumpToFile(fetch, "se");
>  
> -FunctionPassManager optPasses(JM()->mpCurrentModule);
> +#if LLVM_VERISON_MAJOR == 3 && LLVM_VERSION_MINOR == 6
> +FunctionPassManager
> +#else
> +llvm::legacy::FunctionPassManager
> +#endif
> +   optPasses(JM()->mpCurrentModule);
>  
>  ///@todo Haven't touched these either. Need to remove some of these and 
> add others.
>  optPasses.add(createCFGSimplificationPass());
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp 
> b/src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp
> index 6c5f22b..852d96d 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/streamout_jit.cpp
> @@ -293,7 +293,13 @@ struct StreamOutJit : public Builder
>  
>  JitManager::DumpToFile(soFunc, "SoFunc");
>  
> -FunctionPassManager passes(JM()->mpCurrentModule);
> +#if LLVM_VERISON_MAJOR == 3 && LLVM_VERSION_MINOR == 6
> +FunctionPassManager
> +#else
> +llvm::legacy::FunctionPassManager
> +#endif
> +   passes(JM()->mpCurrentModule);
> +
>  passes.add(createBreakCriticalEdgesPass());
>  passes.add(createCFGSimplificationPass());
>  passes.add(createEarlyCSEPass());



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 17/17] GL3.txt: Mark ARB_framebuffer_no_attachments as done

2016-03-19 Thread Kai Wasserbäch

Edward O'Callaghan wrote on 19.03.2016 07:41:
> Signed-off-by: Edward O'Callaghan 
> ---
>  docs/GL3.txt  | 2 +-
>  docs/relnotes/11.3.0.html | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index 3058996..b9fc86b 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -172,7 +172,7 @@ GL 4.3, GLSL 4.30:
>GL_KHR_debug  DONE (all drivers)
>GL_ARB_explicit_uniform_location  DONE (all drivers 
> that support GLSL)
>GL_ARB_fragment_layer_viewportDONE (i965, nv50, 
> nvc0, r600, radeonsi, llvmpipe)
> -  GL_ARB_framebuffer_no_attachments DONE (i965)
> +  GL_ARB_framebuffer_no_attachments DONE (i965, nvc0, 
> r600, radeonsi)
>GL_ARB_internalformat_query2  DONE (i965)
>GL_ARB_invalidate_subdata DONE (all drivers)
>GL_ARB_multi_draw_indirectDONE (i965, nvc0, 
> r600, radeonsi, llvmpipe, softpipe)

Should this also update the GL_ARB_framebuffer_no_attachments line in the OpenGL
ES 3.1 section? Or is more work needed for that? In the latter case a small
comment in the commit message might be nice.

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/4] automake: loader: rework the CPPFLAGS

2015-11-19 Thread Kai Wasserbäch

Hey Emil,
you can have my
  Tested-by: Kai Wasserbäch 
for the series.

I just did a build (amd64 and i386) and didn't see the additional symbols show
up again.

Thanks for taking care of this!

Cheers,
Kai


Emil Velikov wrote on 19.11.2015 17:33:
> From: Emil Velikov 
> 
> Rather than duplicating things, just use the generic AM_CPPFLAGS. This
> has the fortunate side-effect of adding VISIBILITY_CFLAGS for the dri3
> helper. The latter of which was erroneously exposing some internal
> symbols.
> 
> Cc: Kai Wasserbäch 
> Reported-by: Kai Wasserbäch 
> Signed-off-by: Emil Velikov 
> ---
>  src/loader/Makefile.am | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
> index c0f7947..67ed776 100644
> --- a/src/loader/Makefile.am
> +++ b/src/loader/Makefile.am
> @@ -25,18 +25,20 @@ EXTRA_DIST = SConscript
>  
>  noinst_LTLIBRARIES = libloader.la libloader_dri3_helper.la
>  
> -libloader_la_CPPFLAGS = \
> +AM_CPPFLAGS = \
>   $(DEFINES) \
>   -I$(top_srcdir)/include \
>   -I$(top_srcdir)/src \
>   $(VISIBILITY_CFLAGS) \
> + $(LIBDRM_CFLAGS) \
>   $(LIBUDEV_CFLAGS)
>  
>  libloader_la_SOURCES = $(LOADER_C_FILES)
>  libloader_la_LIBADD =
>  
>  if HAVE_DRICOMMON
> -libloader_la_CPPFLAGS += \
> +libloader_la_CPPFLAGS = \
> + $(AM_CPPFLAGS) \
>   -I$(top_srcdir)/src/mesa/drivers/dri/common/ \
>   -I$(top_builddir)/src/mesa/drivers/dri/common/ \
>   -I$(top_srcdir)/src/mesa/ \
> @@ -49,20 +51,11 @@ libloader_la_CPPFLAGS += \
>  endif
>  
>  if HAVE_LIBDRM
> -libloader_la_CPPFLAGS += \
> - $(LIBDRM_CFLAGS)
> -
>  libloader_la_LIBADD += \
>   $(LIBDRM_LIBS)
>  endif
>  
>  if HAVE_DRI3
> -libloader_dri3_helper_la_CPPFLAGS = \
> - $(DEFINES) \
> - -I$(top_srcdir)/include \
> -     -I$(top_srcdir)/src \
> - $(LIBDRM_CFLAGS)
> -
>  libloader_dri3_helper_la_SOURCES = \
>   loader_dri3_helper.c \
>   loader_dri3_helper.h
> 

-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/20] glapi: add ARB_gpu_shader_fp64 (v2)

2014-09-04 Thread Kai Wasserbäch

Hi Dave,
just a small comment, since I'm not really the right person to review this 
patch:

Dave Airlie schrieb am 04.09.2014 06:15:
> [...]
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 04fa86b..00f9b19 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -669,24 +669,24 @@ const struct function gl_core_functions_possible[] = {
> { "glVertexAttribP4uiv", 43, -1 },
> { "glDrawArraysIndirect", 43, -1 },
> { "glDrawElementsIndirect", 43, -1 },
> -// { "glUniform1d", 43, -1 },   // XXX: Add to xml
> -// { "glUniform2d", 43, -1 },   // XXX: Add to xml
> -// { "glUniform3d", 43, -1 },   // XXX: Add to xml
> -// { "glUniform4d", 43, -1 },   // XXX: Add to xml
> -// { "glUniform1dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniform2dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniform3dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniform4dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniformMatrix2dv", 43, -1 },// XXX: Add to xml
> -// { "glUniformMatrix3dv", 43, -1 },// XXX: Add to xml
> -// { "glUniformMatrix4dv", 43, -1 },// XXX: Add to xml
> -// { "glUniformMatrix2x3dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniformMatrix2x4dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniformMatrix3x2dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniformMatrix3x4dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniformMatrix4x2dv", 43, -1 },  // XXX: Add to xml
> -// { "glUniformMatrix4x3dv", 43, -1 },  // XXX: Add to xml
> -// { "glGetUniformdv", 43, -1 },// XXX: Add to xml
> +   { "glUniform1d", 40, -1 },
> +   { "glUniform2d", 40, -1 },
> +   { "glUniform3d", 40, -1 },
> +   { "glUniform4d", 40, -1 },
> +   { "glUniform1dv", 40, -1 },
> +   { "glUniform2dv", 40, -1 },
> +   { "glUniform3dv", 40, -1 },
> +   { "glUniform4dv", 40, -1 },
> +   { "glUniformMatrix2dv", 40, -1 },
> +   { "glUniformMatrix3dv", 40, -1 },
> +   { "glUniformMatrix4dv", 40, -1 },
> +   { "glUniformMatrix2x3dv", 40, -1 },
> +   { "glUniformMatrix2x4dv", 40, -1 },
> +   { "glUniformMatrix3x2dv", 40, -1 },
> +   { "glUniformMatrix3x4dv", 40, -1 },
> +   { "glUniformMatrix4x2dv", 40, -1 },
> +   { "glUniformMatrix4x3dv", 40, -1 },
> +   { "glGetUniformdv", 43, -1 },
  ^^
Shouldn't this be a 40 as well?

Cheers,
Kai



-- 

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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2017-05-18 Thread 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 v2 3/3] drirc: Add allow_glsl_builtin_variable_redeclaration for Dying Light and Dead Island Definitive Edition

2017-05-20 Thread 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

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

2017-10-17 Thread 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] egl/dri2: disambiguate driver name

2017-10-17 Thread 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

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

2017-10-17 Thread 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

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

2017-10-17 Thread 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

2017-10-18 Thread 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

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

2017-04-29 Thread 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

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

2017-05-10 Thread 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] Has anyone stressed radeonsi memory?

2017-11-15 Thread 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 mesa 2/2] egl: drop EGL driver `name`

2017-11-15 Thread 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] [PATCH] amd: build addrlib with C++11

2017-11-15 Thread 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

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

2017-11-16 Thread 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] docs: Point to apt.llvm.org for development snapshot packages

2017-11-16 Thread 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

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

2017-11-25 Thread 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

1 2 3 >

1 - 100 of 213 matches

Mail list logo