Re: Mesa >= 23.3.x and python 2.6 ...

[Stefan Dirsch]

On Sun, Jan 21, 2024 at 11:35:48PM -0800, Jordan Justen wrote:
> I dropped dri-devel from this reply.

Thanks! Initially I added dri-devel, since mesa-dev looked rather dead in
comparison to dri-devel. Also the issue was initially Intel driver specific.

> On 2024-01-20 05:56:23, Stefan Dirsch wrote:
> > Hi Jordan
> > 
> > On Sat, Jan 20, 2024 at 01:47:58AM -0800, Jordan Justen wrote:
> > > 
> > > It was "fun" finding a way to get python 3.6 :), but after that, I
> > > think I found a way to make Python 3.6 work. I guess you can try it
> > > out:
> > > 
> > > https://gitlab.freedesktop.org/jljusten/mesa/-/commits/intel-genxml-python3.6
> > > 
> > > In my light testing, Python 3.6 through 3.13 seemed to work. Python
> > > 3.5 did *not* work.
> > 
> > Wow! Thanks a lot! Indeed these two patches fix this build issue for me! :-)
> > 
> > In addition I needed to add the attached patch to fix some more errors I saw
> > with a python 3.6 build. With that I can build again Mesa 23.3.3.
> 
> It looks like you could turn your changes into ~2 patches.
> 
> I do find this change potentially concerning in that it seems like it
> actually would change behavior when newer Python versions are used.
> 
> -   subparsers = parser.add_subparsers(required=True)
> +   subparsers = parser.add_subparsers()

Thanks, I will split this up and apply this one only for systems with python
3.6.

> With my two patches, and your ~2 patches, you could open a merge
> request for Mesa. To be honest, I don't know how it would be received.
> (Maybe someone would push back on supporting an outdated Python, or
> perhaps not.)

Yeah. We'll see, what the feedback will be. Obviously Mesa is no longer
build-tested with python 3.6, so I may end up fighing against windmills
anyway, I will try to request a newer pyhton for next enterprise service pack
product, but I'm afraid it will be rejected. :-(

> One other question, do you only care about Mesa 23.3? If so, you could
> target the merge request for the 23.3 branch. It seems like there
> potentially could be less chance of getting push back for supporting
> this for just the 23.3 release.

Unfortunately it's likely I also need a python 3.6 supported Mesa also beyond
23.3.x. :-( See my previous comment.

For now I will give the patches a try for our Betas and a few weeks from now I
will try to make a pull request for my changes. Hope this makes sense.

Thanks,
Stefan


Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Frankenstraße 146
FAX: 0911-740 53 479  D-90461 Nürnberg
http://www.suse.deGermany 

Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: Mesa >= 23.3.x and python 2.6 ...

[Stefan Dirsch]

Hi Jordan

On Sat, Jan 20, 2024 at 01:47:58AM -0800, Jordan Justen wrote:
> On 2024-01-19 12:24:24, Stefan Dirsch wrote:
> > Hi Jordan
> > 
> > Thanks for digging into this!
> > 
> > On Fri, Jan 19, 2024 at 12:10:37PM -0800, Jordan Justen wrote:
> > > On 2024-01-18 04:37:52, Stefan Dirsch wrote:
> > > > Hi
> > > > 
> > > > I noticed that with version 23.3.x Mesa no longer can be built with 
> > > > python
> > > > 2.6. It still worked with Mesa 23.2.1.
> > > 
> > > As mentioned in other emails, this was typo where 3.6 was intended.
> > > 
> > > > 
> > > > It fails with
> > > > 
> > > > [   95s] Traceback (most recent call last):
> > > > [   95s]   File "../src/intel/genxml/gen_bits_header.py", line 23, in 
> > > > 
> > > > [   95s] import intel_genxml
> > > > [   95s]   File 
> > > > "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_
> > > > genxml.py", line 5
> > > > [   95s] from __future__ import annotations
> > > > [   95s] ^
> > > > [   95s] SyntaxError: future feature annotations is not defined
> > > > 
> > > 
> > > I guess this code first appeared in Dylan's:
> > > 
> > > 4fd2e15855d ("intel/genxml: add type annotations to gen_sort_tags.py")
> > > 
> > > and then became part of the standard tests a few commits later in:
> > > 
> > > 1f0a0a46d97 ("meson: run genxml sort tests")
> > > 
> > > back in Oct 2022. So, I guess at that point 'ninja test' would have
> > > failed with Python 3.6.
> > > 
> > > Then, I suppose I propagated this to being used on every build in:
> > > 
> > > 0495f952d48 ("intel/genxml: Add genxml_import.py script")
> > > 
> > > in Sept 2023.
> > 
> > Thanks. This explains why I've found this code already in older releases, 
> > but
> > it didn't fail for me yet. You said tests. Is this just a test, I could
> > disable (as dirty hack)? I was assuming it would generate code ...
> 
> In 0495f952d48, I moved in to a common file, and essentially, now it's
> used by our script that runs during the build in addition to the test.
> 
> It was "fun" finding a way to get python 3.6 :), but after that, I
> think I found a way to make Python 3.6 work. I guess you can try it
> out:
> 
> https://gitlab.freedesktop.org/jljusten/mesa/-/commits/intel-genxml-python3.6
> 
> In my light testing, Python 3.6 through 3.13 seemed to work. Python
> 3.5 did *not* work.

Wow! Thanks a lot! Indeed these two patches fix this build issue for me! :-)

In addition I needed to add the attached patch to fix some more errors I saw
with a python 3.6 build. With that I can build again Mesa 23.3.3.

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Frankenstraße 146
FAX: 0911-740 53 479  D-90461 Nürnberg
http://www.suse.deGermany 

Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

--- mesa-23.3.3/src/nouveau/nvidia-headers/class_parser.py.orig	2024-01-20 12:47:36.464476669 +0100
+++ mesa-23.3.3/src/nouveau/nvidia-headers/class_parser.py	2024-01-20 13:04:30.212851443 +0100
@@ -9,6 +9,16 @@
 
 from mako.template import Template
 
+def removeprefix(s, prefix):
+if s.startswith(prefix):
+return s[len(prefix):]
+return s
+
+def removesuffix(s, suffix):
+if s.endswith(suffix):
+return s[:-len(suffix)]
+return s
+
 METHOD_ARRAY_SIZES = {
 'BIND_GROUP_CONSTANT_BUFFER': 16,
 'CALL_MME_DATA' : 256,
@@ -273,7 +283,7 @@
 if ":" in list[2]:
 state = 1
 elif teststr in list[1]:
-curmthd.field_defs[curfield][list[1].removeprefix(teststr)] = list[2]
+curmthd.field_defs[curfield][removeprefix(list[1], teststr)] = list[2]
 else:
 state = 1
 
@@ -283,7 +293,7 @@
 if ("0x" in list[2]):
 state = 1
 else:
-field = list[1].removeprefix(teststr)
+field = removeprefix(list[1], teststr)
 bitfield = list[2].split(":")
 curmthd.field_name

Re: Mesa >= 23.3.x and python 2.6 ...

[Stefan Dirsch]

Hi Jordan

Thanks for digging into this!

On Fri, Jan 19, 2024 at 12:10:37PM -0800, Jordan Justen wrote:
> On 2024-01-18 04:37:52, Stefan Dirsch wrote:
> > Hi
> > 
> > I noticed that with version 23.3.x Mesa no longer can be built with python
> > 2.6. It still worked with Mesa 23.2.1.
> 
> As mentioned in other emails, this was typo where 3.6 was intended.
> 
> > 
> > It fails with
> > 
> > [   95s] Traceback (most recent call last):
> > [   95s]   File "../src/intel/genxml/gen_bits_header.py", line 23, in 
> > 
> > [   95s] import intel_genxml
> > [   95s]   File 
> > "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_
> > genxml.py", line 5
> > [   95s] from __future__ import annotations
> > [   95s] ^
> > [   95s] SyntaxError: future feature annotations is not defined
> > 
> 
> I guess this code first appeared in Dylan's:
> 
> 4fd2e15855d ("intel/genxml: add type annotations to gen_sort_tags.py")
> 
> and then became part of the standard tests a few commits later in:
> 
> 1f0a0a46d97 ("meson: run genxml sort tests")
> 
> back in Oct 2022. So, I guess at that point 'ninja test' would have
> failed with Python 3.6.
> 
> Then, I suppose I propagated this to being used on every build in:
> 
> 0495f952d48 ("intel/genxml: Add genxml_import.py script")
> 
> in Sept 2023.

Thanks. This explains why I've found this code already in older releases, but
it didn't fail for me yet. You said tests. Is this just a test, I could
disable (as dirty hack)? I was assuming it would generate code ...

> Maybe Dylan knows how we might make this compatible with Python 3.6,
> assuming we want to. :)
> 
> https://devguide.python.org/versions/

Yes, I know. It's EOL since a long time now ... sigh

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Frankenstraße 146
FAX: 0911-740 53 479  D-90461 Nürnberg
http://www.suse.deGermany 

Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: Mesa >= 23.3.x no longer supporting python 3.6 ...

[Stefan Dirsch]

On Thu, Jan 18, 2024 at 01:37:52PM +0100, Stefan Dirsch wrote:
> Hi
> 
> I noticed that with version 23.3.x Mesa no longer can be built with python
> 2.6. It still worked with Mesa 23.2.1.

Of course I've meant python 3.6. Sorry for the confusion!

> It fails with
> 
> [   95s] Traceback (most recent call last):
> [   95s]   File "../src/intel/genxml/gen_bits_header.py", line 23, in 
> [   95s] import intel_genxml
> [   95s]   File 
> "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_
> genxml.py", line 5
> [   95s] from __future__ import annotations
> [   95s] ^
> [   95s] SyntaxError: future feature annotations is not defined
> 
> When removing __future__ line like this
> 
> --- mesa-23.3.3/src/intel/genxml/intel_genxml.py.orig   2024-01-12 
> 10:26:26.314070540 +0100
> +++ mesa-23.3.3/src/intel/genxml/intel_genxml.py2024-01-12 
> 10:26:38.682317490 +0100
> @@ -2,7 +2,6 @@
>  # Copyright © 2019, 2022 Intel Corporation
>  # SPDX-License-Identifier: MIT
>  
> -from __future__ import annotations
>  from collections import OrderedDict
>  import copy
>  import io
> 
> this results in the following failure.
> 
> [  113s] Traceback (most recent call last):
> [  113s]   File "../src/intel/genxml/gen_bits_header.py", line 23, in 
> [  113s] import intel_genxml
> [  113s]   File 
> "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_
> genxml.py", line 51, in 
> [  113s] def add_struct_refs(items: typing.OrderedDict[str, bool], node: 
> et.
> Element) -> None:
> [  113s] AttributeError: module 'typing' has no attribute 'OrderedDict'
> 
> I'm wondering if Mesa developers are interested in still supporting python
> 3.6?
> 
> Unfortunately currently it's not an option for SUSE's enterprise product to
> update to a newer python (would be probably 3.12) (due to many customers still
> relying on python 3.6 and we lack the ressources of adding and maintaining a
> (full!) second python development stack). :-(
> 
> If the answer to the question above is a no. :-( How hard would it be to
> adjust the code to python 3.6? Any suggestions to how it could be done? Or is
> there any other workaround available?
> 
> I had a quick look between 23.2.1 and 23.3.3 and I've seen that
> 
>   from __future__ import annotations
> 
> and
> 
>   typing.OrderedDict
> 
> have already been used in 23.2.1 (although it was in gen_sort_tags.py and
> now has been moved to new intel_genxml.py). So not sure why this fails now
> or was working before ...
> 
> Any help here would be appreciated. SUSE is definitely interested in shipping
> the latest Mesa with our latest enterprise product.

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Frankenstraße 146
FAX: 0911-740 53 479  D-90461 Nürnberg
http://www.suse.deGermany 

Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: Mesa >= 23.3.x and python 2.6 ...

[Stefan Dirsch]

On Fri, Jan 19, 2024 at 12:35:58PM -0500, Matt Turner wrote:
> On Thu, Jan 18, 2024 at 10:22 AM Stefan Dirsch  wrote:
> > I noticed that with version 23.3.x Mesa no longer can be built with python
> > 2.6. It still worked with Mesa 23.2.1.
> 
> For anyone who got this far and was completely incredulous... this
> (and the subject) is typo'd -- the problem is about Python 3.6, not
> 2.6.

I'm pretty sure you were the first and only one. :-( I've corrected it in the
body by doing a reply to my own message, but how do I correct a typo in the
subject ... I'll try to send the message again with also the correct
subject. Then I'll be blamed for bringing up the same topic twice and spamming
the list. Sigh.

Thanks for having a look at the message nevertheless!

Thanks,
Stefan

Public Key available
------
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Frankenstraße 146
FAX: 0911-740 53 479  D-90461 Nürnberg
http://www.suse.deGermany 

Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

Re: Mesa >= 23.3.x and python 2.6 ...

[Stefan Dirsch]

On Thu, Jan 18, 2024 at 01:37:52PM +0100, Stefan Dirsch wrote:
> Hi
> 
> I noticed that with version 23.3.x Mesa no longer can be built with python
> 2.6. It still worked with Mesa 23.2.1.

I've meant python 3.6 of course!

CU,
Stefan

Public Key available
------
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Frankenstraße 146
FAX: 0911-740 53 479  D-90461 Nürnberg
http://www.suse.deGermany 

Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

Mesa >= 23.3.x and python 2.6 ...

[Stefan Dirsch]

Hi

I noticed that with version 23.3.x Mesa no longer can be built with python
2.6. It still worked with Mesa 23.2.1.

It fails with

[   95s] Traceback (most recent call last):
[   95s]   File "../src/intel/genxml/gen_bits_header.py", line 23, in 
[   95s] import intel_genxml
[   95s]   File "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_
genxml.py", line 5
[   95s] from __future__ import annotations
[   95s] ^
[   95s] SyntaxError: future feature annotations is not defined

When removing __future__ line like this

--- mesa-23.3.3/src/intel/genxml/intel_genxml.py.orig   2024-01-12 
10:26:26.314070540 +0100
+++ mesa-23.3.3/src/intel/genxml/intel_genxml.py2024-01-12 
10:26:38.682317490 +0100
@@ -2,7 +2,6 @@
 # Copyright © 2019, 2022 Intel Corporation
 # SPDX-License-Identifier: MIT
 
-from __future__ import annotations
 from collections import OrderedDict
 import copy
 import io

this results in the following failure.

[  113s] Traceback (most recent call last):
[  113s]   File "../src/intel/genxml/gen_bits_header.py", line 23, in 
[  113s] import intel_genxml
[  113s]   File "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_
genxml.py", line 51, in 
[  113s] def add_struct_refs(items: typing.OrderedDict[str, bool], node: et.
Element) -> None:
[  113s] AttributeError: module 'typing' has no attribute 'OrderedDict'

I'm wondering if Mesa developers are interested in still supporting python
3.6?

Unfortunately currently it's not an option for SUSE's enterprise product to
update to a newer python (would be probably 3.12) (due to many customers still
relying on python 3.6 and we lack the ressources of adding and maintaining a
(full!) second python development stack). :-(

If the answer to the question above is a no. :-( How hard would it be to
adjust the code to python 3.6? Any suggestions to how it could be done? Or is
there any other workaround available?

I had a quick look between 23.2.1 and 23.3.3 and I've seen that

  from __future__ import annotations

and

  typing.OrderedDict

have already been used in 23.2.1 (although it was in gen_sort_tags.py and
now has been moved to new intel_genxml.py). So not sure why this fails now
or was working before ...

Any help here would be appreciated. SUSE is definitely interested in shipping
the latest Mesa with our latest enterprise product.

Thanks,
Stefan

Public Key available
------
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Frankenstraße 146
FAX: 0911-740 53 479  D-90461 Nürnberg
http://www.suse.deGermany 

Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

[Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)

[Stefan Dirsch]

Hi

Unfortunately rendering of glxgears on S/390 architecture (64bit, BigEndian)
is broken on Mesa 19.3.3. I bisected the issue and the git commit id d17ff2f7,
which came in between 19.2 and 19.3, caused the issue. After reverting this
commit, glxgears rendering is working again. I openend issu#2472 for this.

  https://gitlab.freedesktop.org/mesa/mesa/issues/2472

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 

(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

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

Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

[Stefan Dirsch]

On Tue, Jan 28, 2020 at 11:45:39AM -0800, Dylan Baker wrote:
> Quoting Ian Romanick (2020-01-21 09:50:47)
> > On 1/20/20 6:41 AM, Stefan Dirsch wrote:
> > > Hi
> > > 
> > > Starting from the upcoming GCC release 10, the default of -fcommon option 
> > > will
> > > change to -fno-common. Due to this we're going to see a lot of build 
> > > failures
> > 
> > It seems like many of the places where this would occur in Mesa are
> > likely to be fine... but it would be easy enough to fix by sprinkling
> > 'extern' around (if my understanding of the GCC docs is correct).  It
> > also seems unlikely that GCC will be able to apply any hypothetical
> > optimizations to the uses in Mesa.  I think most places where a global
> > is intended to be isolated, we already decorate it with static.
> > 
> > See also
> > https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fcommon
> > 
> > We definitely should decide which behavior we want, and we should start
> > enforcing it sooner rather than later.
> > 
> > > in Mesa drivers like
> > > 
> > > multiple definition of `syncobj_handle'; 
> > > src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
> > >  (symbol from plugin):(.text+0x0): first defined here
> > > [  213s]
> > > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> > > src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol 
> > > from
> > > plugin): in function 
> > > `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
> > > 
> > > I'm wondering if there is already anybody working on fixing these issues 
> > > or is
> > > it recommended to workaround it by setting -fcommon manually somehow? How 
> > > can
> > > the latter be done when using meson/ninja as build tool?
> > 
> > I know you can do it with buildtype=plain, but that may be overkill for
> > anything other than testing.
> 
> meson -Dc_args=-fcommon -Dcpp_args=-fcommon 
> 
> will do what you want.

Thanks a lot for the hint!

> I agree that we should probably either add -fcommon or -fno-common to the
> meson/scons/android build files, so that we don't get cases of "but this works
> on my dev machine with $complier!"

I agree on that.

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 

(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

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

Re: [Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

[Stefan Dirsch]

On Tue, Jan 21, 2020 at 06:49:59PM +0100, Bas Nieuwenhuizen wrote:
> I think this ended up spawning a bunch of work in
> https://gitlab.freedesktop.org/mesa/mesa/issues/2385

Thanks a lot! These patches (already in master) fixed my build issues with
"-fno-common" compiler flag. :-)

Stefan

> On Mon, Jan 20, 2020 at 3:41 PM Stefan Dirsch  wrote:
> >
> > Hi
> >
> > Starting from the upcoming GCC release 10, the default of -fcommon option 
> > will
> > change to -fno-common. Due to this we're going to see a lot of build 
> > failures
> > in Mesa drivers like
> >
> > multiple definition of `syncobj_handle'; 
> > src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
> >  (symbol from plugin):(.text+0x0): first defined here
> > [  213s]
> > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
> > src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
> > plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':
> >
> > I'm wondering if there is already anybody working on fixing these issues or 
> > is
> > it recommended to workaround it by setting -fcommon manually somehow? How 
> > can
> > the latter be done when using meson/ninja as build tool?

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 

(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

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

[Mesa-dev] -fno-common build failures (default from upcoming gcc release 10)

[Stefan Dirsch]

Hi

Starting from the upcoming GCC release 10, the default of -fcommon option will
change to -fno-common. Due to this we're going to see a lot of build failures
in Mesa drivers like

multiple definition of `syncobj_handle'; 
src/amd/vulkan/9198681@@vulkan_radeon@sha/meson-generated_.._radv_entrypoints.c.o
 (symbol from plugin):(.text+0x0): first defined here
[  213s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_wsi_wayland.c.o (symbol from
plugin): in function `radv_GetPhysicalDeviceWaylandPresentationSupportKHR':

I'm wondering if there is already anybody working on fixing these issues or is
it recommended to workaround it by setting -fcommon manually somehow? How can
the latter be done when using meson/ninja as build tool?

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 

(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

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

[Mesa-dev] Weird behaviour (GLX extension missing) in X11 forwarding since xorg-server 1.20 ...

[Stefan Dirsch]

Hi

I'm wondering, whether this happens to everybody using xorg-server 1.20
(1.20.3 in my case).

When using X11 forwarding via ssh

  ssh -X 

(DISPLAY=localhost:10.0)

the list of available extensions when running xdpyinfo is limited to

[...]
number of extensions:2
BIG-REQUESTS
XC-MISC
default screen number:0

When running xdpyinfo local (DISPLAY=:0) it's complete:

[...]
number of extensions:29
BIG-REQUESTS
Composite
DAMAGE
DOUBLE-BUFFER
DPMS
DRI2
DRI3
GLX
Generic Event Extension
MIT-SCREEN-SAVER
MIT-SHM
Present
RANDR
RECORD
RENDER
SECURITY
SHAPE
SYNC
X-Resource
XC-MISC
XFIXES
XFree86-DGA
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
XVideo-MotionCompensation
default screen number:0
[...]

This happens even if you ssh to the same local machine. Can anybody reproduce
this? Is this a known issue. Since now GLX extension is missing I can't run
any GL application any longer via ssh ...

This still works with xorg-server 1.19 for me.

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 

SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

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

Re: [Mesa-dev] [PATCH] libGLw: Use newly introduced GLAPIVAR for variables

[Stefan Dirsch]

On Wed, Jul 18, 2018 at 11:07:01AM -0600, Brian Paul wrote:
> On 07/17/2018 06:47 PM, Stefan Dirsch wrote:
> > On Tue, Jul 17, 2018 at 04:57:26PM -0600, Brian Paul wrote:
> > > Reviewed-by: Brian Paul 
> > > 
> > > Do you need me to push this for you?
> > 
> > I'm afraid the answer is yes. Tried it but push hangs forever after this
> > 
> > # git push --verbose
> > Pushing to ssh://git.freedesktop.org/git/mesa/glw.git
> > Counting objects: 4, done.
> > Delta compression using up to 8 threads.
> > Compressing objects: 100% (4/4), done.
> > Writing objects: 100% (4/4), 700 bytes | 350.00 KiB/s, done.
> > Total 4 (delta 3), reused 0 (delta 0)
> 
> Worked for me.

Wonderful! Thanks a bunch.

Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] libGLw: Use newly introduced GLAPIVAR for variables

[Stefan Dirsch]

On Tue, Jul 17, 2018 at 04:57:26PM -0600, Brian Paul wrote:
> Reviewed-by: Brian Paul 
> 
> Do you need me to push this for you?

I'm afraid the answer is yes. Tried it but push hangs forever after this

# git push --verbose
Pushing to ssh://git.freedesktop.org/git/mesa/glw.git
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 700 bytes | 350.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0)

Thanks,
Stefan

Public Key available
------
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] libGLw: Use newly introduced GLAPIVAR for variables

[Stefan Dirsch]

On Tue, Jul 17, 2018 at 08:21:10AM -0600, Brian Paul wrote:
> On 07/17/2018 07:31 AM, Stefan Dirsch wrote:
> > GLAPI doesn't have an 'extern' in some circumstances. This way,
> > variable declarations become definitions (fdo #100916).
> > 
> > Signed-off-by: Stefan Dirsch 
> > ---
> >   GLwDrawA.h  | 12 ++--
> >   GLwDrawAP.h |  4 ++--
> >   2 files changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/GLwDrawA.h b/GLwDrawA.h
> > index b9711c2..21f70e7 100644
> > --- a/GLwDrawA.h
> > +++ b/GLwDrawA.h
> > @@ -131,12 +131,20 @@
> >   #define GLwNaccumAlphaSize"accumAlphaSize"
> >   #define GLwCAccumAlphaSize"AccumAlphaSize"
> > +#if (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) && 
> > (__SUNPRO_C >= 0x590))
> > +#  define GLAPIVAR extern __attribute__((visibility("default")))
> > +#endif
> > +
> > +#ifndef GLAPIVAR
> > +#define GLAPIVAR extern
> > +#endif
> 
> Couldn't you just use #else instead of #endif / #ifndef GLAPIVAR ?

Yes, of course. Just resent the patch to the list.

CU,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] libGLw: Use newly introduced GLAPIVAR for variables

[Stefan Dirsch]

GLAPI doesn't have an 'extern' in some circumstances. This way,
variable declarations become definitions (fdo #100916).

Signed-off-by: Stefan Dirsch 
---
 GLwDrawA.h  | 10 --
 GLwDrawAP.h |  4 ++--
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/GLwDrawA.h b/GLwDrawA.h
index b9711c2..316a70d 100644
--- a/GLwDrawA.h
+++ b/GLwDrawA.h
@@ -131,12 +131,18 @@
 #define GLwNaccumAlphaSize "accumAlphaSize"
 #define GLwCAccumAlphaSize "AccumAlphaSize"
 
+#if (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) && 
(__SUNPRO_C >= 0x590))
+#  define GLAPIVAR extern __attribute__((visibility("default")))
+#else
+#  define GLAPIVAR extern
+#endif
+
 #ifdef __GLX_MOTIF
 
 typedef struct _GLwMDrawingAreaClassRec*GLwMDrawingAreaWidgetClass;
 typedef struct _GLwMDrawingAreaRec *GLwMDrawingAreaWidget;
 
-GLAPI WidgetClass glwMDrawingAreaWidgetClass;
+GLAPIVAR WidgetClass glwMDrawingAreaWidgetClass;
 
 
 #else 
@@ -144,7 +150,7 @@ GLAPI WidgetClass glwMDrawingAreaWidgetClass;
 typedef struct _GLwDrawingAreaClassRec *GLwDrawingAreaWidgetClass;
 typedef struct _GLwDrawingAreaRec  *GLwDrawingAreaWidget;
 
-GLAPI WidgetClass glwDrawingAreaWidgetClass;
+GLAPIVAR WidgetClass glwDrawingAreaWidgetClass;
 
 
 #endif
diff --git a/GLwDrawAP.h b/GLwDrawAP.h
index 4ff21b4..6d29849 100644
--- a/GLwDrawAP.h
+++ b/GLwDrawAP.h
@@ -59,7 +59,7 @@ typedef struct _GLwMDrawingAreaClassRec {
   } GLwMDrawingAreaClassRec;
 
 
-GLAPI GLwMDrawingAreaClassRec glwMDrawingAreaClassRec;
+GLAPIVAR GLwMDrawingAreaClassRec glwMDrawingAreaClassRec;
 
 
 /* XT */
@@ -70,7 +70,7 @@ typedef struct _GLwDrawingAreaClassRec {
   GLwDrawingAreaClassPart glwDrawingArea_class;
   } GLwDrawingAreaClassRec;
 
-GLAPI GLwDrawingAreaClassRec glwDrawingAreaClassRec;
+GLAPIVAR GLwDrawingAreaClassRec glwDrawingAreaClassRec;
 
 
 #endif 
-- 
2.16.4

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

[Mesa-dev] [PATCH] libGLw: Use newly introduced GLAPIVAR for variables

[Stefan Dirsch]

GLAPI doesn't have an 'extern' in some circumstances. This way,
variable declarations become definitions (fdo #100916).

Signed-off-by: Stefan Dirsch 
---
 GLwDrawA.h  | 12 ++--
 GLwDrawAP.h |  4 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/GLwDrawA.h b/GLwDrawA.h
index b9711c2..21f70e7 100644
--- a/GLwDrawA.h
+++ b/GLwDrawA.h
@@ -131,12 +131,20 @@
 #define GLwNaccumAlphaSize "accumAlphaSize"
 #define GLwCAccumAlphaSize "AccumAlphaSize"
 
+#if (defined(__GNUC__) && __GNUC__ >= 4) || (defined(__SUNPRO_C) && 
(__SUNPRO_C >= 0x590))
+#  define GLAPIVAR extern __attribute__((visibility("default")))
+#endif
+
+#ifndef GLAPIVAR
+#define GLAPIVAR extern
+#endif
+
 #ifdef __GLX_MOTIF
 
 typedef struct _GLwMDrawingAreaClassRec*GLwMDrawingAreaWidgetClass;
 typedef struct _GLwMDrawingAreaRec *GLwMDrawingAreaWidget;
 
-GLAPI WidgetClass glwMDrawingAreaWidgetClass;
+GLAPIVAR WidgetClass glwMDrawingAreaWidgetClass;
 
 
 #else 
@@ -144,7 +152,7 @@ GLAPI WidgetClass glwMDrawingAreaWidgetClass;
 typedef struct _GLwDrawingAreaClassRec *GLwDrawingAreaWidgetClass;
 typedef struct _GLwDrawingAreaRec  *GLwDrawingAreaWidget;
 
-GLAPI WidgetClass glwDrawingAreaWidgetClass;
+GLAPIVAR WidgetClass glwDrawingAreaWidgetClass;
 
 
 #endif
diff --git a/GLwDrawAP.h b/GLwDrawAP.h
index 4ff21b4..6d29849 100644
--- a/GLwDrawAP.h
+++ b/GLwDrawAP.h
@@ -59,7 +59,7 @@ typedef struct _GLwMDrawingAreaClassRec {
   } GLwMDrawingAreaClassRec;
 
 
-GLAPI GLwMDrawingAreaClassRec glwMDrawingAreaClassRec;
+GLAPIVAR GLwMDrawingAreaClassRec glwMDrawingAreaClassRec;
 
 
 /* XT */
@@ -70,7 +70,7 @@ typedef struct _GLwDrawingAreaClassRec {
   GLwDrawingAreaClassPart glwDrawingArea_class;
   } GLwDrawingAreaClassRec;
 
-GLAPI GLwDrawingAreaClassRec glwDrawingAreaClassRec;
+GLAPIVAR GLwDrawingAreaClassRec glwDrawingAreaClassRec;
 
 
 #endif 
-- 
2.16.4

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

[Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
by "Michal Srb" <m...@suse.com> to not break python 2.

https://bugzilla.suse.com/show_bug.cgi?id=1082303

v2:
- no longer try to encode a unicode
- make use of 'from __future__ import print_function', so semantics
  of print statements in python2 are closer to print functions in python3

https://lists.freedesktop.org/archives/mesa-dev/2018-February/187056.html

v3:
- convert bytes object to unicode in order to fix output with python3

https://lists.freedesktop.org/archives/mesa-dev/2018-March/187492.html

Signed-off-by: Stefan Dirsch <sndir...@suse.de>
Reviewed-by: Tomas Chvatal <tchva...@suse.com>
Reviewed-by: Dylan Baker <dy...@pnwbakers.com>
Reviewed-by: Eric Engestrom <e...@engestrom.ch>
---
 src/gallium/drivers/r600/egd_tables.py | 53 +-
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/r600/egd_tables.py 
b/src/gallium/drivers/r600/egd_tables.py
index d7b78c7fb1..2d37a5bcc9 100644
--- a/src/gallium/drivers/r600/egd_tables.py
+++ b/src/gallium/drivers/r600/egd_tables.py
@@ -1,3 +1,4 @@
+from __future__ import print_function
 
 CopyRight = '''
 /*
@@ -60,7 +61,7 @@ class StringTable:
 """
 fragments = [
 '"%s\\0" /* %s */' % (
-te[0].encode('string_escape'),
+te[0].encode('unicode_escape').decode('utf-8'),
 ', '.join(str(idx) for idx in te[2])
 )
 for te in self.table
@@ -217,10 +218,10 @@ def write_tables(regs, packets):
 strings = StringTable()
 strings_offsets = IntTable("int")
 
-print '/* This file is autogenerated by egd_tables.py from evergreend.h. 
Do not edit directly. */'
-print
-print CopyRight.strip()
-print '''
+print('/* This file is autogenerated by egd_tables.py from evergreend.h. 
Do not edit directly. */')
+print('')
+print(CopyRight.strip())
+print('''
 #ifndef EG_TABLES_H
 #define EG_TABLES_H
 
@@ -242,20 +243,20 @@ struct eg_packet3 {
 unsigned name_offset;
 unsigned op;
 };
-'''
+''')
 
-print 'static const struct eg_packet3 packet3_table[] = {'
+print('static const struct eg_packet3 packet3_table[] = {')
 for pkt in packets:
-print '\t{%s, %s},' % (strings.add(pkt[5:]), pkt)
-print '};'
-print
+print('\t{%s, %s},' % (strings.add(pkt[5:]), pkt))
+print('};')
+print('')
 
-print 'static const struct eg_field egd_fields_table[] = {'
+print('static const struct eg_field egd_fields_table[] = {')
 
 fields_idx = 0
 for reg in regs:
 if len(reg.fields) and reg.own_fields:
-print '\t/* %s */' % (fields_idx)
+print('\t/* %s */' % (fields_idx))
 
 reg.fields_idx = fields_idx
 
@@ -266,34 +267,34 @@ struct eg_packet3 {
 while value[1] >= len(values_offsets):
 values_offsets.append(-1)
 values_offsets[value[1]] = 
strings.add(strip_prefix(value[0]))
-print '\t{%s, %s(~0u), %s, %s},' % (
+print('\t{%s, %s(~0u), %s, %s},' % (
 strings.add(field.name), field.s_name,
-len(values_offsets), 
strings_offsets.add(values_offsets))
+len(values_offsets), 
strings_offsets.add(values_offsets)))
 else:
-print '\t{%s, %s(~0u)},' % (strings.add(field.name), 
field.s_name)
+print('\t{%s, %s(~0u)},' % (strings.add(field.name), 
field.s_name))
 fields_idx += 1
 
-print '};'
-print
+print('};')
+print('')
 
-print 'static const struct eg_reg egd_reg_table[] = {'
+print('static const struct eg_reg egd_reg_table[] = {')
 for reg in regs:
 if len(reg.fields):
-print '\t{%s, %s, %s, %s},' % (strings.add(reg.name), reg.r_name,
-len(reg.fields), reg.fields_idx if reg.own_fields else 
reg.fields_owner.fields_idx)
+print('\t{%s, %s, %s, %s},' % (strings.add(reg.name), reg.r_name,
+len(reg.fields), reg.fields_idx if reg.own_fields else 
reg.fields_owner.fields_idx))
 else:
-print '\t{%s, %s},' % (strings.add(reg.name), reg.r_name)
-print '};'
-print
+print('\t{%s, %s},' % (strings.add(reg.name), reg.r_name))
+print('};')
+print('')
 
 strings.emit(sys.stdout, "egd_strings")
 
-print
+print('')
 
 strings_offsets.emit(sys.stdout, "egd_strings_offsets")
 
-print
-print '#endif'
+print('')
+print('#endif')
 
 
 def main():
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

On Fri, Mar 02, 2018 at 01:39:40PM +0100, Gustaw Smolarczyk wrote:
> 2018-03-02 12:59 GMT+01:00 Stefan Dirsch <sndir...@suse.de>:
> 
> On Fri, Mar 02, 2018 at 11:47:57AM +, Eric Engestrom wrote:
> > On Friday, 2018-03-02 12:25:11 +0100, Stefan Dirsch wrote:
> > > On Fri, Mar 02, 2018 at 11:03:53AM +, Eric Engestrom wrote:
> > > > On Friday, 2018-03-02 11:41:00 +0100, Stefan Dirsch wrote:
> > > > > Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
> > > > > by "Michal Srb" <m...@suse.com> to not break python 2.
> > > > >
> > > > > https://bugzilla.suse.com/show_bug.cgi?id=1082303
> > > > >
> > > > > v2:
> > > > > - no longer try to encode a unicode
> > > > > - make use of 'from __future__ import print_function', so 
> semantics
> > > > >   of print statements in python2 are closer to print functions in
> python3
> > > > >
> > > > > https://lists.freedesktop.org/archives/mesa-dev/2018-February/
> 187056.html
> > > > >
> > > > > Signed-off-by: Stefan Dirsch <sndir...@suse.de>
> > > > > Reviewed-by: Tomas Chvatal <tchva...@suse.com>
> > > > > ---
> > > > >  src/gallium/drivers/r600/egd_tables.py | 53
> +-
> > > > >  1 file changed, 27 insertions(+), 26 deletions(-)
> > > > >
> > > > > diff --git a/src/gallium/drivers/r600/egd_tables.py b/src/gallium/
> drivers/r600/egd_tables.py
> > > > > index d7b78c7fb1..4796456330 100644
> > > > > --- a/src/gallium/drivers/r600/egd_tables.py
> > > > > +++ b/src/gallium/drivers/r600/egd_tables.py
> > > > > @@ -1,3 +1,4 @@
> > > > > +from __future__ import print_function
> > > > >
> > > > >  CopyRight = '''
> > > > >  /*
> > > > > @@ -60,7 +61,7 @@ class StringTable:
> > > > >          """
> > > > >          fragments = [
> > > > >              '"%s\\0" /* %s */' % (
> > > > > -                te[0].encode('string_escape'),
> > > > > +                te[0],
> 
> 
> Hi,
> 
> I am not an expert in Python 3, but I have found the following answer
> experimentally.
> 
> I think the original version is semi-correct, but the encode() method returns 
> a
> bytes object which we need to convert to unicode. I think the following would
> be fine:
> 
> te[0].encode('unicode_escape').decode('utf-8')

Looks good. And still the same output with python2 and python3. :-) If Dylan
and Eric agree I'll send a revised patch.

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

On Fri, Mar 02, 2018 at 11:47:57AM +, Eric Engestrom wrote:
> On Friday, 2018-03-02 12:25:11 +0100, Stefan Dirsch wrote:
> > On Fri, Mar 02, 2018 at 11:03:53AM +, Eric Engestrom wrote:
> > > On Friday, 2018-03-02 11:41:00 +0100, Stefan Dirsch wrote:
> > > > Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
> > > > by "Michal Srb" <m...@suse.com> to not break python 2.
> > > > 
> > > > https://bugzilla.suse.com/show_bug.cgi?id=1082303
> > > > 
> > > > v2:
> > > > - no longer try to encode a unicode
> > > > - make use of 'from __future__ import print_function', so semantics
> > > >   of print statements in python2 are closer to print functions in 
> > > > python3
> > > > 
> > > > https://lists.freedesktop.org/archives/mesa-dev/2018-February/187056.html
> > > > 
> > > > Signed-off-by: Stefan Dirsch <sndir...@suse.de>
> > > > Reviewed-by: Tomas Chvatal <tchva...@suse.com>
> > > > ---
> > > >  src/gallium/drivers/r600/egd_tables.py | 53 
> > > > +-
> > > >  1 file changed, 27 insertions(+), 26 deletions(-)
> > > > 
> > > > diff --git a/src/gallium/drivers/r600/egd_tables.py 
> > > > b/src/gallium/drivers/r600/egd_tables.py
> > > > index d7b78c7fb1..4796456330 100644
> > > > --- a/src/gallium/drivers/r600/egd_tables.py
> > > > +++ b/src/gallium/drivers/r600/egd_tables.py
> > > > @@ -1,3 +1,4 @@
> > > > +from __future__ import print_function
> > > >  
> > > >  CopyRight = '''
> > > >  /*
> > > > @@ -60,7 +61,7 @@ class StringTable:
> > > >  """
> > > >  fragments = [
> > > >  '"%s\\0" /* %s */' % (
> > > > -te[0].encode('string_escape'),
> > > > +te[0],
> > > 
> > > I think you still need to escape the string here.
> > 
> > I don't know how to address this. :-( At least the output of
> > 
> >   python2 egd_tables.py evergreend.h
> >   python3 egd_tables.py evergreend.h
> > 
> > is now identical. Surely this may change with changes in content of
> > evergreend.h. :-( Ok. I've tried my best.
> 
> I think you should already land the print() changes, leaving this line
> as is for now. Won't be valid python3 yet, but this will be the last
> thing to fix, which someone else might pick up :)

Leaving the line as is won't run with python3.

> With the string escape hunk left out, this patch is
> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>

Thanks, but I'm not really interested in submitting a patch, which doesn't fix
the build for python3.

Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

On Fri, Mar 02, 2018 at 11:03:53AM +, Eric Engestrom wrote:
> On Friday, 2018-03-02 11:41:00 +0100, Stefan Dirsch wrote:
> > Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
> > by "Michal Srb" <m...@suse.com> to not break python 2.
> > 
> > https://bugzilla.suse.com/show_bug.cgi?id=1082303
> > 
> > v2:
> > - no longer try to encode a unicode
> > - make use of 'from __future__ import print_function', so semantics
> >   of print statements in python2 are closer to print functions in python3
> > 
> > https://lists.freedesktop.org/archives/mesa-dev/2018-February/187056.html
> > 
> > Signed-off-by: Stefan Dirsch <sndir...@suse.de>
> > Reviewed-by: Tomas Chvatal <tchva...@suse.com>
> > ---
> >  src/gallium/drivers/r600/egd_tables.py | 53 
> > +-
> >  1 file changed, 27 insertions(+), 26 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/r600/egd_tables.py 
> > b/src/gallium/drivers/r600/egd_tables.py
> > index d7b78c7fb1..4796456330 100644
> > --- a/src/gallium/drivers/r600/egd_tables.py
> > +++ b/src/gallium/drivers/r600/egd_tables.py
> > @@ -1,3 +1,4 @@
> > +from __future__ import print_function
> >  
> >  CopyRight = '''
> >  /*
> > @@ -60,7 +61,7 @@ class StringTable:
> >  """
> >  fragments = [
> >  '"%s\\0" /* %s */' % (
> > -te[0].encode('string_escape'),
> > +te[0],
> 
> I think you still need to escape the string here.

I don't know how to address this. :-( At least the output of

  python2 egd_tables.py evergreend.h
  python3 egd_tables.py evergreend.h

is now identical. Surely this may change with changes in content of
evergreend.h. :-( Ok. I've tried my best.

> The rest of the patch looks good to me :)

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

On Thu, Mar 01, 2018 at 09:00:38AM -0800, Dylan Baker wrote:
> Quoting sndir...@suse.de (2018-03-01 08:11:54)
> > From: Stefan Dirsch <sndir...@suse.de>
> > 
> > Patch by "Tomas Chvatal"  with modifications
> > by "Michal Srb"  to not break python 2.
> > 
> > https://bugzilla.suse.com/show_bug.cgi?id=1082303
> > 
> > v2:
> > - no longer try to encode a unicode
> > - make use of 'from __future__ import print_function', so semantics
> >   of print statements in python2 are closer to print functions in python3
> > 
> > https://lists.freedesktop.org/archives/mesa-dev/2018-February/187056.html
> > 
> > Signed-off-by: Stefan Dirsch <sndir...@suse.de>
> > Reviewed-by: Tomas Chvatal 
> > Reviewed-by: Dylan Baker 
> 
> Process comment for you. Reviewed-by in mesa is like the kernel, it carries a
> very specific formal meaning and you don't add Reviewed-by (or Acked-by,
> Tested-by, etc) unless someone explicitly says that they give a Reviewed-by.

This has been a mistake. I apologize.

> Also, please use the natural name@domain form for emails. Scripts that
> scrape emails out of emails and git commits are not fooled by "name at
> domain" anyway.

Yeah. I believe I copied the header from the mesa-devel mail archive. Then I
was running out of time when sending the email, etc. Sigh.

I've sent the patch once more to the mailing list.

> Reviewed-by: Dylan Baker <dy...@pnwbakers.com>

Thanks!

Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
by "Michal Srb" <m...@suse.com> to not break python 2.

https://bugzilla.suse.com/show_bug.cgi?id=1082303

v2:
- no longer try to encode a unicode
- make use of 'from __future__ import print_function', so semantics
  of print statements in python2 are closer to print functions in python3

https://lists.freedesktop.org/archives/mesa-dev/2018-February/187056.html

Signed-off-by: Stefan Dirsch <sndir...@suse.de>
Reviewed-by: Tomas Chvatal <tchva...@suse.com>
---
 src/gallium/drivers/r600/egd_tables.py | 53 +-
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/r600/egd_tables.py 
b/src/gallium/drivers/r600/egd_tables.py
index d7b78c7fb1..4796456330 100644
--- a/src/gallium/drivers/r600/egd_tables.py
+++ b/src/gallium/drivers/r600/egd_tables.py
@@ -1,3 +1,4 @@
+from __future__ import print_function
 
 CopyRight = '''
 /*
@@ -60,7 +61,7 @@ class StringTable:
 """
 fragments = [
 '"%s\\0" /* %s */' % (
-te[0].encode('string_escape'),
+te[0],
 ', '.join(str(idx) for idx in te[2])
 )
 for te in self.table
@@ -217,10 +218,10 @@ def write_tables(regs, packets):
 strings = StringTable()
 strings_offsets = IntTable("int")
 
-print '/* This file is autogenerated by egd_tables.py from evergreend.h. 
Do not edit directly. */'
-print
-print CopyRight.strip()
-print '''
+print('/* This file is autogenerated by egd_tables.py from evergreend.h. 
Do not edit directly. */')
+print('')
+print(CopyRight.strip())
+print('''
 #ifndef EG_TABLES_H
 #define EG_TABLES_H
 
@@ -242,20 +243,20 @@ struct eg_packet3 {
 unsigned name_offset;
 unsigned op;
 };
-'''
+''')
 
-print 'static const struct eg_packet3 packet3_table[] = {'
+print('static const struct eg_packet3 packet3_table[] = {')
 for pkt in packets:
-print '\t{%s, %s},' % (strings.add(pkt[5:]), pkt)
-print '};'
-print
+print('\t{%s, %s},' % (strings.add(pkt[5:]), pkt))
+print('};')
+print('')
 
-print 'static const struct eg_field egd_fields_table[] = {'
+print('static const struct eg_field egd_fields_table[] = {')
 
 fields_idx = 0
 for reg in regs:
 if len(reg.fields) and reg.own_fields:
-print '\t/* %s */' % (fields_idx)
+print('\t/* %s */' % (fields_idx))
 
 reg.fields_idx = fields_idx
 
@@ -266,34 +267,34 @@ struct eg_packet3 {
 while value[1] >= len(values_offsets):
 values_offsets.append(-1)
 values_offsets[value[1]] = 
strings.add(strip_prefix(value[0]))
-print '\t{%s, %s(~0u), %s, %s},' % (
+print('\t{%s, %s(~0u), %s, %s},' % (
 strings.add(field.name), field.s_name,
-len(values_offsets), 
strings_offsets.add(values_offsets))
+len(values_offsets), 
strings_offsets.add(values_offsets)))
 else:
-print '\t{%s, %s(~0u)},' % (strings.add(field.name), 
field.s_name)
+print('\t{%s, %s(~0u)},' % (strings.add(field.name), 
field.s_name))
 fields_idx += 1
 
-print '};'
-print
+print('};')
+print('')
 
-print 'static const struct eg_reg egd_reg_table[] = {'
+print('static const struct eg_reg egd_reg_table[] = {')
 for reg in regs:
 if len(reg.fields):
-print '\t{%s, %s, %s, %s},' % (strings.add(reg.name), reg.r_name,
-len(reg.fields), reg.fields_idx if reg.own_fields else 
reg.fields_owner.fields_idx)
+print('\t{%s, %s, %s, %s},' % (strings.add(reg.name), reg.r_name,
+len(reg.fields), reg.fields_idx if reg.own_fields else 
reg.fields_owner.fields_idx))
 else:
-print '\t{%s, %s},' % (strings.add(reg.name), reg.r_name)
-print '};'
-print
+print('\t{%s, %s},' % (strings.add(reg.name), reg.r_name))
+print('};')
+print('')
 
 strings.emit(sys.stdout, "egd_strings")
 
-print
+print('')
 
 strings_offsets.emit(sys.stdout, "egd_strings_offsets")
 
-print
-print '#endif'
+print('')
+print('#endif')
 
 
 def main():
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

On Wed, Feb 28, 2018 at 02:16:08PM +0100, Stefan Dirsch wrote:
> On Wed, Feb 28, 2018 at 12:12:25PM +0100, Stefan Dirsch wrote:
> > Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
> > by "Michal Srb" <m...@suse.com> to not break python 2.
> > 
> > https://bugzilla.suse.com/show_bug.cgi?id=1082303
> > 
> > v2:
> > - open parse file in binary mode (default changed from binary to unicode
> >   text mode with python3)
> > - make use of 'from __future__ import print_function', so semantics
> >   of print statements in python2 are closer to print functions in python3
> > 
> > https://lists.freedesktop.org/archives/mesa-dev/2018-February/187056.html
> 
> Ok, guys. This patch is complete crap. Tested with
> 
>   python2/python3 ./egd_tables.py
> 
> (meanwhile figured out, that the parse file itself needs to be added as second
> argument)
> 
> This happens if you try to upstream and revise a patch, that you didn't write
> yourself (in a language you're not familiar with). Sigh.
> 
> So please forget about this (not so nice) try.

Meanwhile I figured out that even the patch I initially sent was already
broken. It generated lines like this:

   "b'NOP'\0" /* 0 */
   "b'DEALLOC_STATE'\0" /* 4 */

instead of (python2)

   "NOP\0" /* 0 */
   "DEALLOC_STATE\0" /* 4 */

OMG.

Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

On Wed, Feb 28, 2018 at 12:12:25PM +0100, Stefan Dirsch wrote:
> Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
> by "Michal Srb" <m...@suse.com> to not break python 2.
> 
> https://bugzilla.suse.com/show_bug.cgi?id=1082303
> 
> v2:
> - open parse file in binary mode (default changed from binary to unicode
>   text mode with python3)
> - make use of 'from __future__ import print_function', so semantics
>   of print statements in python2 are closer to print functions in python3
> 
> https://lists.freedesktop.org/archives/mesa-dev/2018-February/187056.html

Ok, guys. This patch is complete crap. Tested with

  python2/python3 ./egd_tables.py

(meanwhile figured out, that the parse file itself needs to be added as second
argument)

This happens if you try to upstream and revise a patch, that you didn't write
yourself (in a language you're not familiar with). Sigh.

So please forget about this (not so nice) try.

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600/egd_tables.py: make the script python 2+3 compatible

[Stefan Dirsch]

Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
by "Michal Srb" <m...@suse.com> to not break python 2.

https://bugzilla.suse.com/show_bug.cgi?id=1082303

v2:
- open parse file in binary mode (default changed from binary to unicode
  text mode with python3)
- make use of 'from __future__ import print_function', so semantics
  of print statements in python2 are closer to print functions in python3

https://lists.freedesktop.org/archives/mesa-dev/2018-February/187056.html

Signed-off-by: Stefan Dirsch <sndir...@suse.de>
Reviewed-by: Dylan Baker <dy...@pnwbakers.com>
---
 src/gallium/drivers/r600/egd_tables.py | 55 +-
 1 file changed, 28 insertions(+), 27 deletions(-)

diff --git a/src/gallium/drivers/r600/egd_tables.py 
b/src/gallium/drivers/r600/egd_tables.py
index d7b78c7fb1..ee62157141 100644
--- a/src/gallium/drivers/r600/egd_tables.py
+++ b/src/gallium/drivers/r600/egd_tables.py
@@ -1,3 +1,4 @@
+from __future__ import print_function
 
 CopyRight = '''
 /*
@@ -60,7 +61,7 @@ class StringTable:
 """
 fragments = [
 '"%s\\0" /* %s */' % (
-te[0].encode('string_escape'),
+te[0].encode('unicode_escape'),
 ', '.join(str(idx) for idx in te[2])
 )
 for te in self.table
@@ -146,7 +147,7 @@ def strip_prefix(s):
 return s[s[2:].find('_')+3:]
 
 def parse(filename, regs, packets):
-stream = open(filename)
+stream = io.open('filename', 'b')
 
 for line in stream:
 if not line.startswith('#define '):
@@ -217,10 +218,10 @@ def write_tables(regs, packets):
 strings = StringTable()
 strings_offsets = IntTable("int")
 
-print '/* This file is autogenerated by egd_tables.py from evergreend.h. 
Do not edit directly. */'
-print
-print CopyRight.strip()
-print '''
+print('/* This file is autogenerated by egd_tables.py from evergreend.h. 
Do not edit directly. */')
+print('')
+print(CopyRight.strip())
+print('''
 #ifndef EG_TABLES_H
 #define EG_TABLES_H
 
@@ -242,20 +243,20 @@ struct eg_packet3 {
 unsigned name_offset;
 unsigned op;
 };
-'''
+''')
 
-print 'static const struct eg_packet3 packet3_table[] = {'
+print('static const struct eg_packet3 packet3_table[] = {')
 for pkt in packets:
-print '\t{%s, %s},' % (strings.add(pkt[5:]), pkt)
-print '};'
-print
+print('\t{%s, %s},' % (strings.add(pkt[5:]), pkt))
+print('};')
+print('')
 
-print 'static const struct eg_field egd_fields_table[] = {'
+print('static const struct eg_field egd_fields_table[] = {')
 
 fields_idx = 0
 for reg in regs:
 if len(reg.fields) and reg.own_fields:
-print '\t/* %s */' % (fields_idx)
+print('\t/* %s */' % (fields_idx))
 
 reg.fields_idx = fields_idx
 
@@ -266,34 +267,34 @@ struct eg_packet3 {
 while value[1] >= len(values_offsets):
 values_offsets.append(-1)
 values_offsets[value[1]] = 
strings.add(strip_prefix(value[0]))
-print '\t{%s, %s(~0u), %s, %s},' % (
+print('\t{%s, %s(~0u), %s, %s},' % (
 strings.add(field.name), field.s_name,
-len(values_offsets), 
strings_offsets.add(values_offsets))
+len(values_offsets), 
strings_offsets.add(values_offsets)))
 else:
-print '\t{%s, %s(~0u)},' % (strings.add(field.name), 
field.s_name)
+print('\t{%s, %s(~0u)},' % (strings.add(field.name), 
field.s_name))
 fields_idx += 1
 
-print '};'
-print
+print('};')
+print('')
 
-print 'static const struct eg_reg egd_reg_table[] = {'
+print('static const struct eg_reg egd_reg_table[] = {')
 for reg in regs:
 if len(reg.fields):
-print '\t{%s, %s, %s, %s},' % (strings.add(reg.name), reg.r_name,
-len(reg.fields), reg.fields_idx if reg.own_fields else 
reg.fields_owner.fields_idx)
+print('\t{%s, %s, %s, %s},' % (strings.add(reg.name), reg.r_name,
+len(reg.fields), reg.fields_idx if reg.own_fields else 
reg.fields_owner.fields_idx))
 else:
-print '\t{%s, %s},' % (strings.add(reg.name), reg.r_name)
-print '};'
-print
+print('\t{%s, %s},' % (strings.add(reg.name), reg.r_name))
+print('};')
+print('')
 
 strings.emit(sys.stdout, "egd_strings")
 
-print
+print('')
 
 strings_offsets.emit(sys.stdout, "egd_strings_offsets")
 
-print
-print '#endif'
+print('')
+print('#endif')
 
 
 def main():
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH] configure.ac: Link to libLLVMCodegen to fix cyclic linking problems

[Stefan Dirsch]

B41;308;0cOn Tue, Feb 27, 2018 at 04:24:04PM +0100, Stefan Dirsch wrote:
> On Tue, Feb 27, 2018 at 11:59:22AM +, Emil Velikov wrote:
> > On 23 February 2018 at 15:02, Stefan Dirsch <sndir...@suse.de> wrote:
> > > Patch by "Ismail Doenmez" <idon...@suse.com>
> > > https://bugzilla.suse.com/show_bug.cgi?id=1082307
> > 
> > Can anyone provide some information about the cyclic linking problem?
> > Stuff like - mesa configure options, LLVM version and/or actual error
> > will be appreciated.
> 
> Good question. I believe we no longer need this patch since we use
> LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS to build one single libLLVM
> library, which is the recommended way anyway.
> 
> Michal, is this correct? Could we drop this patch?

Michal meanwhile confirmed.

"Exactly. We do not need it anymore since that change in LLVM build. It would
be still useful for anyone who uses Mesa with LLVM build using
BUILD_SHARED_LIBS, but it is just workaround for issue in LLVM. Which LLVM
upstream does not want to address since the build mode is not meant for this
use case."

I'm removing the patch from (open)SUSE packages. ;-)

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure.ac: Link to libLLVMCodegen to fix cyclic linking problems

[Stefan Dirsch]

On Tue, Feb 27, 2018 at 11:59:22AM +, Emil Velikov wrote:
> On 23 February 2018 at 15:02, Stefan Dirsch <sndir...@suse.de> wrote:
> > Patch by "Ismail Doenmez" <idon...@suse.com>
> > https://bugzilla.suse.com/show_bug.cgi?id=1082307
> 
> Can anyone provide some information about the cyclic linking problem?
> Stuff like - mesa configure options, LLVM version and/or actual error
> will be appreciated.

Good question. I believe we no longer need this patch since we use
LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS to build one single libLLVM
library, which is the recommended way anyway.

Michal, is this correct? Could we drop this patch?

Thanks,
Stefan

Public Key available
----------
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600/egd_tables.py: added support for python 3

[Stefan Dirsch]

Patch by "Tomas Chvatal" <tchva...@suse.com> with modifications
by "Michal Srb" <m...@suse.com> to not break python 2.
https://bugzilla.suse.com/show_bug.cgi?id=1082303

Signed-off-by: Stefan Dirsch <sndir...@suse.de>
---
 src/gallium/drivers/r600/egd_tables.py | 52 +-
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/src/gallium/drivers/r600/egd_tables.py 
b/src/gallium/drivers/r600/egd_tables.py
index d7b78c7fb1..b3b8b50292 100644
--- a/src/gallium/drivers/r600/egd_tables.py
+++ b/src/gallium/drivers/r600/egd_tables.py
@@ -60,7 +60,7 @@ class StringTable:
 """
 fragments = [
 '"%s\\0" /* %s */' % (
-te[0].encode('string_escape'),
+te[0].encode('unicode_escape'),
 ', '.join(str(idx) for idx in te[2])
 )
 for te in self.table
@@ -217,10 +217,10 @@ def write_tables(regs, packets):
 strings = StringTable()
 strings_offsets = IntTable("int")
 
-print '/* This file is autogenerated by egd_tables.py from evergreend.h. 
Do not edit directly. */'
-print
-print CopyRight.strip()
-print '''
+print('/* This file is autogenerated by egd_tables.py from evergreend.h. 
Do not edit directly. */')
+print('')
+print(CopyRight.strip())
+print('''
 #ifndef EG_TABLES_H
 #define EG_TABLES_H
 
@@ -242,20 +242,20 @@ struct eg_packet3 {
 unsigned name_offset;
 unsigned op;
 };
-'''
+''')
 
-print 'static const struct eg_packet3 packet3_table[] = {'
+print('static const struct eg_packet3 packet3_table[] = {')
 for pkt in packets:
-print '\t{%s, %s},' % (strings.add(pkt[5:]), pkt)
-print '};'
-print
+print('\t{%s, %s},' % (strings.add(pkt[5:]), pkt))
+print('};')
+print('')
 
-print 'static const struct eg_field egd_fields_table[] = {'
+print('static const struct eg_field egd_fields_table[] = {')
 
 fields_idx = 0
 for reg in regs:
 if len(reg.fields) and reg.own_fields:
-print '\t/* %s */' % (fields_idx)
+print('\t/* %s */' % (fields_idx))
 
 reg.fields_idx = fields_idx
 
@@ -266,34 +266,34 @@ struct eg_packet3 {
 while value[1] >= len(values_offsets):
 values_offsets.append(-1)
 values_offsets[value[1]] = 
strings.add(strip_prefix(value[0]))
-print '\t{%s, %s(~0u), %s, %s},' % (
+print('\t{%s, %s(~0u), %s, %s},' % (
 strings.add(field.name), field.s_name,
-len(values_offsets), 
strings_offsets.add(values_offsets))
+len(values_offsets), 
strings_offsets.add(values_offsets)))
 else:
-print '\t{%s, %s(~0u)},' % (strings.add(field.name), 
field.s_name)
+print('\t{%s, %s(~0u)},' % (strings.add(field.name), 
field.s_name))
 fields_idx += 1
 
-print '};'
-print
+print('};')
+print('')
 
-print 'static const struct eg_reg egd_reg_table[] = {'
+print('static const struct eg_reg egd_reg_table[] = {')
 for reg in regs:
 if len(reg.fields):
-print '\t{%s, %s, %s, %s},' % (strings.add(reg.name), reg.r_name,
-len(reg.fields), reg.fields_idx if reg.own_fields else 
reg.fields_owner.fields_idx)
+print('\t{%s, %s, %s, %s},' % (strings.add(reg.name), reg.r_name,
+len(reg.fields), reg.fields_idx if reg.own_fields else 
reg.fields_owner.fields_idx))
 else:
-print '\t{%s, %s},' % (strings.add(reg.name), reg.r_name)
-print '};'
-print
+print('\t{%s, %s},' % (strings.add(reg.name), reg.r_name))
+print('};')
+print('')
 
 strings.emit(sys.stdout, "egd_strings")
 
-print
+print('')
 
 strings_offsets.emit(sys.stdout, "egd_strings_offsets")
 
-print
-print '#endif'
+print('')
+print('#endif')
 
 
 def main():
-- 
2.13.6

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

[Mesa-dev] [PATCH] configure.ac: Link to libLLVMCodegen to fix cyclic linking problems

[Stefan Dirsch]

Patch by "Ismail Doenmez" 
https://bugzilla.suse.com/show_bug.cgi?id=1082307
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index 8a9172690a..a23eb844d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1032,6 +1032,7 @@ llvm_add_default_components() {
 
 # Required default components
 llvm_add_component "bitwriter" $driver_name
+llvm_add_component "codegen" $driver_name
 llvm_add_component "engine" $driver_name
 llvm_add_component "mcdisassembler" $driver_name
 llvm_add_component "mcjit" $driver_name
-- 
2.13.6

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

Re: [Mesa-dev] [Mesa-maintainers] Building Mesa GIT with LLVM prior to 3.9

[Stefan Dirsch]

On Mon, Sep 18, 2017 at 05:00:07PM +0100, Emil Velikov wrote:
> As you may know, different components in Mesa use LLVM for various purposes.
> 
> In particular:
>  - 3.3.0 for the aux gallium module, gallivm
>  - 3.6.0 for the opencl state-tracker, clover
>  - 3.9.0 for multiple drivers r600, radeonsi, radv and swr
> [...]
> So leaving the former out for now, I'm wondering if we cannot bump the
> Clover requirement to 3.9.0.
> [...]
>  - openSUSE - 3.9 since Leap 42.2 (unofficial), official since Tumbleweed

No objections from my side as Mesa maintainer for openSUSE, since we need llvm
3.9 for various drivers mentioned above anyway. ;-)

Thanks,
Stefan

Public Key available
----------
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH glx/glxglvnd] Avoid overflow in 'last' variable of FindGLXFunction(...)

[Stefan Dirsch]

On Thu, Jul 14, 2016 at 05:20:55PM +0100, Emil Velikov wrote:
> On 14 July 2016 at 15:23, Eric Engestrom <eric.engest...@imgtec.com> wrote:
> > On Thu, Jul 14, 2016 at 03:21:20PM +0200, Stefan Dirsch wrote:
> >> This 'last' variable used in FindGLXFunction(...) may become negative,
> >> but has been defined as unsigned int resulting in an overflow,
> >> finally resulting in a segfault when accessing 
> >> _glXDispatchTableStrings[...].
> >> Fixed this by definining it as signed int. 'first' variable also needs to 
> >> be
> >> defined as signed int. Otherwise condition for while loop fails due to C
> >> implicitly converting signed to unsigned values before comparison.
> >
> > Indeed, `last` can become negative is when the name searched for is
> > alphabetically less than the first entry in the dispatch table.
> > On the penultimate round, we would have `first = 0` and `last = 1`.
> > Next iteration of the while loop, middle becomes 0, `strcmp() > 0`
> > and last = middle - 1, ie. -1.
> >
> > The same issue exists on the other side (name searched is after last
> > entry), but until DI_FUNCTION_COUNT reaches UINT_MAX this wouldn't
> > wrap around.
> >
> > It's unlikely we'll ever have more than INT_MAX entries in the dispatch
> > table, so I think this patch is OK. I tried to find a better fix, but
> > adding checks before updating first and last feels too heavy.
> >
> Indeed, reaching {U,}INT_MAX is extremely unlikely, thus we can avoid
> adding extra checks.
> 
> > Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
> >
> I'll add the stable tag and push this in a few minutes (as the fresh
> doze of coffee kicks in).

Thanks a lot!

> Stefan, I'll double-check about the issue mentioned in the cover
> letter and let you know (and/or send patches).

Didn't hear back from you. Are you still planning to look into this? Or does
it just work for you and I messed something up on my side?

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] libglvnd support in Mesa 12

[Stefan Dirsch]

I've played around with libglvnd support in Mesa12. I'm using libglvnd
from git master (commit id 1b30d15) and Mesa 12.0.1.

It tries to open the last fallback libGLX_indirect. I workarounded this via
setting __GLX_VENDOR_LIBRARY_NAME environment variable to "mesa". This
resulted in a crash when trying to find "glXUseXFont", for which I attach a fix.

[PATCH glx/glxglvnd] Avoid overflow in 'last' variable of

Unfortunately GL applications like glxinfo/glxgears still fail with

  "Error: couldn't get an RGB, double-buffered visual"

Anybody who has this already successfully running? Any hints?

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

[Mesa-dev] [PATCH glx/glxglvnd] Avoid overflow in 'last' variable of FindGLXFunction(...)

[Stefan Dirsch]

This 'last' variable used in FindGLXFunction(...) may become negative,
but has been defined as unsigned int resulting in an overflow,
finally resulting in a segfault when accessing _glXDispatchTableStrings[...].
Fixed this by definining it as signed int. 'first' variable also needs to be
defined as signed int. Otherwise condition for while loop fails due to C
implicitly converting signed to unsigned values before comparison.

Signed-off-by: Stefan Dirsch <sndir...@suse.de>
---
 src/glx/glxglvnd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glx/glxglvnd.c b/src/glx/glxglvnd.c
index b7252a7..962eda8 100644
--- a/src/glx/glxglvnd.c
+++ b/src/glx/glxglvnd.c
@@ -19,11 +19,11 @@ static void *__glXGLVNDGetProcAddress(const GLubyte 
*procName)
 
 static unsigned FindGLXFunction(const GLubyte *name)
 {
-unsigned first = 0;
-unsigned last = DI_FUNCTION_COUNT - 1;
+int first = 0;
+int last = DI_FUNCTION_COUNT - 1;
 
 while (first <= last) {
-unsigned middle = (first + last) / 2;
+int middle = (first + last) / 2;
 int comp = strcmp((const char *) name,
   __glXDispatchTableStrings[middle]);
 
-- 
2.6.6

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

Re: [Mesa-dev] [PATCH] dri3: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

On Wed, Apr 27, 2016 at 01:12:57PM +0100, Emil Velikov wrote:
> On 25 April 2016 at 14:06, Stefan Dirsch <sndir...@suse.de> wrote:
> > According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
> > always returns a valid pointer. If no context is made current, it will
> > contain dummyContext. Thus a test for NULL will always fail.
> >
> > https://lists.freedesktop.org/archives/mesa-dev/2016-April/113962.html
> >
> > Signed-off-by: Stefan Dirsch <sndir...@suse.de>
> > Reviewed-by: Egbert Eich <e...@freedesktop.org>
> 
> Thanks for the patches Stefan.
> 
> Both this and the dri2 one are in master... 

Cool!

> just to realise that I
> should have tagged them for stable (/me does that on the side).

These have also been emailed with Cc set to
<mesa-sta...@lists.freedesktop.org> meanwhile. So these should have been
tracked properly. No need to hurry. ;-)

> Barring the libva patch, can you skim through the list and let us know
> which ones are outstanding ?
> 
> https://patchwork.freedesktop.org/project/mesa/patches/?submitter=12700

These are all obsolete apart from the latest one:

  https://patchwork.freedesktop.org/patch/82662/

> P.S. Don't bother resending, only to add someone's r-b/ack/... tag.
> Patchwork does this for us ;-)

Sorry, I wasn't aware of that. :-(

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] dri3: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
always returns a valid pointer. If no context is made current, it will
contain dummyContext. Thus a test for NULL will always fail.

https://lists.freedesktop.org/archives/mesa-dev/2016-April/113962.html

Signed-off-by: Stefan Dirsch <sndir...@suse.de>
Reviewed-by: Egbert Eich <e...@freedesktop.org>
---
 src/glx/dri3_glx.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 6054ffc..e7c2ec1 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -127,13 +127,9 @@ static __DRIcontext *
 glx_dri3_get_dri_context(struct loader_dri3_drawable *draw)
 {
struct glx_context *gc = __glXGetCurrentContext();
+   struct dri3_context *dri3Ctx = (struct dri3_context *) gc;
 
-   if (gc) {
-  struct dri3_context *dri3Ctx = (struct dri3_context *) gc;
-  return dri3Ctx->driContext;
-   }
-
-   return NULL;
+   return (gc != ) ? dri3Ctx->driContext : NULL;
 }
 
 static void
-- 
2.6.2

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

[Mesa-dev] [PATCH] st/va: hardlink driver instances to gallium_drv_video.so

[Stefan Dirsch]

From: Jimmy Berry 

Removes the need to set LIBVA_DRIVER_NAME=gallium for supported targets and is
consistent with vdpau and general gallium drivers.
---
 src/gallium/targets/va/Makefile.am | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/gallium/targets/va/Makefile.am 
b/src/gallium/targets/va/Makefile.am
index 1edd5c2..df825b7 100644
--- a/src/gallium/targets/va/Makefile.am
+++ b/src/gallium/targets/va/Makefile.am
@@ -66,3 +66,17 @@ if HAVE_MESA_LLVM
 gallium_drv_video_la_LIBADD += $(LLVM_LIBS)
 gallium_drv_video_la_LDFLAGS += $(LLVM_LDFLAGS)
 endif
+
+# hardlink each megadriver instance, but don't actually have
+# gallium_drv_video.so in the set of final installed files.
+install-data-hook:
+   for i in $(TARGET_DRIVERS); do  \
+   ln -f $(DESTDIR)$(vadir)/gallium_drv_video.so\
+ $(DESTDIR)$(vadir)/$${i}_drv_video.so; \
+   done;   \
+   $(RM) $(DESTDIR)$(vadir)/gallium_drv_video.*
+
+uninstall-hook:
+   for i in $(TARGET_DRIVERS); do  \
+   $(RM) $(DESTDIR)$(vadir)/$${i}_drv_video.so; \
+   done;
-- 
2.6.2

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

[Mesa-dev] [PATCH] dri2: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

From: Egbert Eich 

According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
always returns a valid pointer. If no context is made current, it will
contain dummyContext. Thus a test for NULL will always fail.

https://bugzilla.opensuse.org/show_bug.cgi?id=962609

Tested-by: Olaf Hering 
Reviewed-by: Michel Dänzer 
---
 src/glx/dri2_glx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 7710349..7288266 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -520,7 +520,7 @@ dri2GetCurrentContext()
struct glx_context *gc = __glXGetCurrentContext();
struct dri2_context *dri2Ctx = (struct dri2_context *)gc;
 
-   return dri2Ctx ? dri2Ctx->driContext : NULL;
+   return (gc != ) ? dri2Ctx->driContext : NULL;
 }
 
 /**
-- 
2.6.2

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

Re: [Mesa-dev] [PATCH] dri2: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

On Thu, Apr 21, 2016 at 04:22:26PM +0900, Michel Dänzer wrote:
> On 20.04.2016 19:38, Stefan Dirsch wrote:
> > According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
> > always returns a valid pointer. If no context is made current, it will
> > contain dummyContext. Thus a test for NULL will always fail.
> > 
> > Patch author: Egbert Eich <e...@suse.com>

done.

> Please set the Git author field itself to Egbert Eich <e...@suse.com> then.
>
> With that fixed,
> 
> Reviewed-by: Michel Dänzer <michel.daen...@amd.com>

Wow! I've added this to the commit message as well and resent the patch.

https://lists.freedesktop.org/archives/mesa-dev/2016-April/113975.html

> Do you need somebody to push this patch for you?

If you could help with that, this would be very useful and appreciated.

> P.S. Looks like at least glx_dri3_get_dri_context may need the same
> treatment?

Took care of this as well and sent the patch to the list.

https://lists.freedesktop.org/archives/mesa-dev/2016-April/113976.html

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] dri3: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
always returns a valid pointer. If no context is made current, it will
contain dummyContext. Thus a test for NULL will always fail.

https://lists.freedesktop.org/archives/mesa-dev/2016-April/113962.html

Signed-off-by: Stefan Dirsch <sndir...@suse.de>
---
 src/glx/dri3_glx.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 6054ffc..e7c2ec1 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -127,13 +127,9 @@ static __DRIcontext *
 glx_dri3_get_dri_context(struct loader_dri3_drawable *draw)
 {
struct glx_context *gc = __glXGetCurrentContext();
+   struct dri3_context *dri3Ctx = (struct dri3_context *) gc;
 
-   if (gc) {
-  struct dri3_context *dri3Ctx = (struct dri3_context *) gc;
-  return dri3Ctx->driContext;
-   }
-
-   return NULL;
+   return (gc != ) ? dri3Ctx->driContext : NULL;
 }
 
 static void
-- 
2.6.2

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

[Mesa-dev] [PATCH] dri2: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

From: Egbert Eich 

According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
always returns a valid pointer. If no context is made current, it will
contain dummyContext. Thus a test for NULL will always fail.

https://bugzilla.opensuse.org/show_bug.cgi?id=962609

Signed-off-by: Egbert Eich 
Tested-by: Olaf Hering 
Reviewed-by: Michel Dänzer 
---
 src/glx/dri2_glx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 7710349..7288266 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -520,7 +520,7 @@ dri2GetCurrentContext()
struct glx_context *gc = __glXGetCurrentContext();
struct dri2_context *dri2Ctx = (struct dri2_context *)gc;
 
-   return dri2Ctx ? dri2Ctx->driContext : NULL;
+   return (gc != ) ? dri2Ctx->driContext : NULL;
 }
 
 /**
-- 
2.6.2

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

[Mesa-dev] [PATCH 1/3] dri2: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

From: Egbert Eich 

According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
always returns a valid pointer. If no context is made current, it will
contain dummyContext. Thus a test for NULL will always fail.

https://bugzilla.opensuse.org/show_bug.cgi?id=962609

Signed-off-by: Egbert Eich 
Tested-by: Olaf Hering 
Reviewed-by: Michel Dänzer 
---
 src/glx/dri2_glx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 7710349..7288266 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -520,7 +520,7 @@ dri2GetCurrentContext()
struct glx_context *gc = __glXGetCurrentContext();
struct dri2_context *dri2Ctx = (struct dri2_context *)gc;
 
-   return dri2Ctx ? dri2Ctx->driContext : NULL;
+   return (gc != ) ? dri2Ctx->driContext : NULL;
 }
 
 /**
-- 
2.6.2

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

[Mesa-dev] [PATCH] st/va: hardlink driver instances to gallium_drv_video.so

[Stefan Dirsch]

Removes the need to set LIBVA_DRIVER_NAME=gallium for supported targets and is
consistent with vdpau and general gallium drivers.

Author: Jimmy Berry 

Signed-off-by: Jimmy Berry 
---
 src/gallium/targets/va/Makefile.am | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/gallium/targets/va/Makefile.am 
b/src/gallium/targets/va/Makefile.am
index 1edd5c2..df825b7 100644
--- a/src/gallium/targets/va/Makefile.am
+++ b/src/gallium/targets/va/Makefile.am
@@ -66,3 +66,17 @@ if HAVE_MESA_LLVM
 gallium_drv_video_la_LIBADD += $(LLVM_LIBS)
 gallium_drv_video_la_LDFLAGS += $(LLVM_LDFLAGS)
 endif
+
+# hardlink each megadriver instance, but don't actually have
+# gallium_drv_video.so in the set of final installed files.
+install-data-hook:
+   for i in $(TARGET_DRIVERS); do  \
+   ln -f $(DESTDIR)$(vadir)/gallium_drv_video.so\
+ $(DESTDIR)$(vadir)/$${i}_drv_video.so; \
+   done;   \
+   $(RM) $(DESTDIR)$(vadir)/gallium_drv_video.*
+
+uninstall-hook:
+   for i in $(TARGET_DRIVERS); do  \
+   $(RM) $(DESTDIR)$(vadir)/$${i}_drv_video.so; \
+   done;
-- 
2.6.2

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

[Mesa-dev] [PATCH] dri2: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
always returns a valid pointer. If no context is made current, it will
contain dummyContext. Thus a test for NULL will always fail.

Patch author: Egbert Eich 

https://bugzilla.opensuse.org/show_bug.cgi?id=962609

Signed-off-by: Egbert Eich 
Tested-by: Olaf Hering 
---
 src/glx/dri2_glx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 7710349..7288266 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -520,7 +520,7 @@ dri2GetCurrentContext()
struct glx_context *gc = __glXGetCurrentContext();
struct dri2_context *dri2Ctx = (struct dri2_context *)gc;
 
-   return dri2Ctx ? dri2Ctx->driContext : NULL;
+   return (gc != ) ? dri2Ctx->driContext : NULL;
 }
 
 /**
-- 
2.6.2

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

[Mesa-dev] [PATCH] st/va: hardlink driver instances to gallium_drv_video.so

[Stefan Dirsch]

Dear gentlemen,

unfortunately the patch by Jimmy Berry didn't get too much attention, when he
posted it first. Maybe this time it's different. Find it attached.

Thanks,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
>From 8974248c4147e57552dc21c6d16e4d1817d34fad Mon Sep 17 00:00:00 2001
From: Jimmy Berry <ji...@boombatower.com>
Date: Sat, 19 Dec 2015 22:49:10 -0600
Subject: [Mesa-dev] [PATCH] st/va: hardlink driver instances to gallium_drv_video.so

Removes the need to set LIBVA_DRIVER_NAME=gallium for supported targets and is
consistent with vdpau and general gallium drivers.

Signed-off-by: Jimmy Berry <ji...@boombatower.com>
---
 src/gallium/targets/va/Makefile.am | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/gallium/targets/va/Makefile.am b/src/gallium/targets/va/Makefile.am
index 733e7ac..2cab898 100644
--- a/src/gallium/targets/va/Makefile.am
+++ b/src/gallium/targets/va/Makefile.am
@@ -64,3 +64,17 @@ if HAVE_MESA_LLVM
 gallium_drv_video_la_LIBADD += $(LLVM_LIBS)
 gallium_drv_video_la_LDFLAGS += $(LLVM_LDFLAGS)
 endif
+
+# hardlink each megadriver instance, but don't actually have
+# gallium_drv_video.so in the set of final installed files.
+install-data-hook:
+	for i in $(TARGET_DRIVERS); do  \
+		ln -f $(DESTDIR)$(vadir)/gallium_drv_video.so\
+		  $(DESTDIR)$(vadir)/$${i}_drv_video.so; \
+	done;   \
+	$(RM) $(DESTDIR)$(vadir)/gallium_drv_video.*
+
+uninstall-hook:
+	for i in $(TARGET_DRIVERS); do  \
+		$(RM) $(DESTDIR)$(vadir)/$${i}_drv_video.so; \
+	done;
-- 
2.6.3

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

[Mesa-dev] [PATCH] dri2: Check for dummyContext to see if the glx_context is valid

[Stefan Dirsch]

Dear gentlemen,

please forgive me. It's some time ago I tried to upstream patches. I'm afraid
it's not the right prcoess I'm using here. :-(

Attached you find a patch. It has been a fix for

  https://bugzilla.opensuse.org/show_bug.cgi?id=962609

CU,
Stefan

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
From: Egbert Eich <e...@suse.de>
Date: Wed Jan 20 13:51:11 2016 +0100
Subject: [PATCH]dri2: Check for dummyContext to see if the glx_context is valid
Patch-mainline: to be upstreamed

References: boo#962609
Signed-off-by: Egbert Eich <e...@suse.com>

According to the comments in src/glx/glxcurrent.c __glXGetCurrentContext()
always returns a valid pointer. If no context is made current, it will
contain dummyContext. Thus a test for NULL will always fail.

Signed-off-by: Egbert Eich <e...@suse.de>
---
 src/glx/dri2_glx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 27ea952..6a5f964 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -520,7 +520,7 @@ dri2GetCurrentContext()
struct glx_context *gc = __glXGetCurrentContext();
struct dri2_context *dri2Ctx = (struct dri2_context *)gc;
 
-   return dri2Ctx ? dri2Ctx->driContext : NULL;
+   return (gc != ) ? dri2Ctx->driContext : NULL;
 }
 
 /**
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa-demos: xeglthreads needs to add "-lX11 -lpthread" itself

[Stefan Dirsch]

Hi Andreas

Thanks for asking!

Seems you're preparing a new release? That would be really cool! Indeed my
patch is no longer needed. Even with 8.2.0 it wasn't. I just didn't notice
when updating it.

Also with current git I no longer need to disable egl. ;-)

So I can revert this change again:

Wed Jun 24 14:38:19 UTC 2015 - sndir...@suse.com
- disabled egl build due to Mesa's removal of skeleton 
  implementation of EGL_MESA_screen_surface with release 10.6.0

I guess that's the reason for it:

commit 74443c6ee79f3251f643ea05e94df58183e37d0d
Author: Matt Turner <matts...@gmail.com>
Date:   Fri Aug 28 15:57:38 2015 -0700

egl: Remove demos using EGL_MESA_screen_surface.

The remnants of the extension were removed from Mesa in commit 7a58262e.

Thanks,
Stefan

On Sun, Dec 06, 2015 at 02:29:20PM +0100, Andreas Boll wrote:
> Is this still an issue?
> Could you give us the build log of a verbose build?
> 
> Thanks,
> Andreas
> 
> 2015-08-21 10:37 GMT+02:00 Stefan Dirsch <sndir...@suse.de>:
> > Hi
> >
> > This is just a simple buildfix for current mesa-demos git master branch.
> >
> > Thanks,
> > Stefan
> >
> > Author: Stefan Dirsch <sndir...@suse.de>
> > Subject: xeglthreads needs to add "-lX11 -lpthread" itself
> > Signed-off-by: Stefan Dirsch <sndir...@suse.de>
> >
> > xeglthreads no longer can rely on the toolchain to add the required libs,
> > it uses directly.
> >
> > --- src/egl/opengl/Makefile.am.orig 2011-08-29 14:34:02.0 +
> > +++ src/egl/opengl/Makefile.am  2011-08-29 14:34:31.0 +
> > @@ -32,7 +32,7 @@ AM_CFLAGS = \
> > -I$(top_srcdir)/src/util
> >  AM_LDFLAGS = \
> > $(DEMO_LIBS) \
> > -   $(EGL_LIBS)
> > +   $(EGL_LIBS) -lX11 -lpthread
> >
> >  if HAVE_X11
> >  EGL_X11_DEMOS = \
> >
> > Public Key available
> > --
> > Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
> > Tel: 0911-740 53 0Maxfeldstraße 5
> > FAX: 0911-740 53 479  D-90409 Nürnberg
> > http://www.suse.deGermany
> > ---
> > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
> > Norton, HRB 21284 (AG Nürnberg)
> > ---
> > _______
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

-- 
Regards,
Stefan Dirsch

Public Key available
--
Stefan Dirsch (Res. & Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa-demos: xeglthreads needs to add -lX11 -lpthread itself

[Stefan Dirsch]

Hi

This is just a simple buildfix for current mesa-demos git master branch.

Thanks,
Stefan

Author: Stefan Dirsch sndir...@suse.de
Subject: xeglthreads needs to add -lX11 -lpthread itself
Signed-off-by: Stefan Dirsch sndir...@suse.de

xeglthreads no longer can rely on the toolchain to add the required libs,
it uses directly.

--- src/egl/opengl/Makefile.am.orig 2011-08-29 14:34:02.0 +
+++ src/egl/opengl/Makefile.am  2011-08-29 14:34:31.0 +
@@ -32,7 +32,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/util
 AM_LDFLAGS = \
$(DEMO_LIBS) \
-   $(EGL_LIBS)
+   $(EGL_LIBS) -lX11 -lpthread
 
 if HAVE_X11
 EGL_X11_DEMOS = \

Public Key available
--
Stefan Dirsch (Res.  Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa-demos: xeglthreads needs to add -lX11 -lpthread itself

[Stefan Dirsch]

Hi

This is just a simple buildfix for current mesa-demos git master branch.

Thanks,
Stefan

Author: Stefan Dirsch sndir...@suse.de
Subject: xeglthreads needs to add -lX11 -lpthread itself
Signed-off-by: Stefan Dirsch sndir...@suse.de

xeglthreads no longer can rely on the toolchain to add the required libs,
it uses directly.

--- src/egl/opengl/Makefile.am.orig 2011-08-29 14:34:02.0 +
+++ src/egl/opengl/Makefile.am  2011-08-29 14:34:31.0 +
@@ -32,7 +32,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/util
 AM_LDFLAGS = \
$(DEMO_LIBS) \
-   $(EGL_LIBS)
+   $(EGL_LIBS) -lX11 -lpthread
 
 if HAVE_X11
 EGL_X11_DEMOS = \

Public Key available
--
Stefan Dirsch (Res.  Dev.)   SUSE LINUX GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
---
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] Suppress any libGL:... warnings when LIBGL_DEBUG == quiet

[Stefan Dirsch]

On Tue, Sep 09, 2014 at 10:00:47PM +0100, Emil Velikov wrote:
  I didn't try to upstream this yet, since I wasn't convinced about the full
  correctness of the patch. It doesn't make use of a threshold and a verbose
  level which is done in src/glx/dri_common.c:dri_message(). Looking at
  __driUtilMessage() more closely a verbose level isn't given anyway. So
  probably the patch isn't that bad.
  
  If you believe the patch is ok, please feel free to push it. You do have my
  Signed-off-by: Stefan Dirsch sndir...@suse.de.
  
 I've added the SoB to the commit, slightly pimped the commit message and
 pushed to master. Does not seem like it's required in 10.3 but feel free to
 convince me otherwise :)

Thanks a lot! It's definitely a cosmetic issue. No need to push it to 10.3.

Best regards,
Stefan

Public Key available
--
Stefan Dirsch (Res.  Dev.)   SUSE LINUX Products GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
--
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] Suppress any libGL:... warnings when LIBGL_DEBUG == quiet

[Stefan Dirsch]

On Mon, Sep 08, 2014 at 04:51:37PM +0100, Emil Velikov wrote:
 Gents,
 
 Can anyone review this trivial patch ?
 
 Stefan, Johannes
 Why do I need to register in order to view the bugreport ? Afaict it is not a
 security issue, so I believe the bug should be publicly accessible.

Sorry, the bug has been reported against our sle12 business product (closed
beta program). I'm wondering that you could access it at all. I've meanwhile
cloned the bug to the openSUSE bug area, which should be accessible by
everybody - after registering to Novell's bugzilla. :-( Sorry for that
inconvenience.

  https://bugzilla.novell.com/show_bug.cgi?id=895730

I didn't try to upstream this yet, since I wasn't convinced about the full
correctness of the patch. It doesn't make use of a threshold and a verbose
level which is done in src/glx/dri_common.c:dri_message(). Looking at
__driUtilMessage() more closely a verbose level isn't given anyway. So
probably the patch isn't that bad.

If you believe the patch is ok, please feel free to push it. You do have my
Signed-off-by: Stefan Dirsch sndir...@suse.de.

Hope this helps.

Thanks,
Stefan

 On 26/08/14 21:47, Johannes Obermayr wrote:
  From: Stefan Dirsch sndir...@suse.de
  
  Let's handle LIBGL_DEBUG env. variable in Mesa in a consistent way.
  
  Fixes: https://bugzilla.novell.com/show_bug.cgi?id=892896
  ---
  To: mesa-dev@lists.freedesktop.org
  Cc: 10.3 mesa-sta...@lists.freedesktop.org
  openSUSE maintainers: Why can't you forward your applied u_* patches to 
  upstream
to get them included in final/next release?
  ---
   src/mesa/drivers/dri/common/xmlconfig.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
  
  diff --git a/src/mesa/drivers/dri/common/xmlconfig.c 
  b/src/mesa/drivers/dri/common/xmlconfig.c
  index ce37647..8e48522 100644
  --- a/src/mesa/drivers/dri/common/xmlconfig.c
  +++ b/src/mesa/drivers/dri/common/xmlconfig.c
  @@ -429,8 +429,10 @@ static void
   __driUtilMessage(const char *f, ...)
   {
   va_list args;
  +const char *libgl_debug;
   
  -if (getenv(LIBGL_DEBUG)) {
  +libgl_debug=getenv(LIBGL_DEBUG);
  +if (libgl_debug  !strstr(libgl_debug, quiet)) {
   fprintf(stderr, libGL: );
   va_start(args, f);
   vfprintf(stderr, f, args);

Public Key available
--
Stefan Dirsch (Res.  Dev.)   SUSE LINUX Products GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479  D-90409 Nürnberg
http://www.suse.deGermany 
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
--
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev