[PATCH i-g-t v3 0/4] Use C11 atomics

[PATCH i-g-t v3 0/4] Use C11 atomics

[Guillaume Tucker]

This series replaces calls to the __sync_* functions with the more
recent atomic_* ones defined in stdatomic.h in gem_create and
sw_sync.  It also adds dependency on libatomic when required, that is
to say when the CPU architecture doesn't provide native support for
some atomic operations.  This makes the tests more portable, in
particular for 32-bit MIPS which doesn't support 64-bit atomics.

v2:
 - add linker test to only add dependency on libatomic when needed
 - only add libatomic dependency to gem_create and sw_sync
 - use stdatomic.h and _Atomic type modifier
 - explicitly require libatomic in all Docker images

v3:
 - use sub-arch libatomic1 in Debian docker images
 - use null_dep in meson.build

Guillaume Tucker (4):
  meson: add libatomic dependency
  gitlab-ci: add libatomic to docker images
  i915/gem_create: use atomic_* instead of __sync_*
  tests/sw_sync: use atomic_* instead of __sync_*

 Dockerfile.debian       |  1 +
 Dockerfile.debian-arm64 |  1 +
 Dockerfile.debian-armhf |  1 +
 Dockerfile.fedora       |  2 +-
 meson.build             | 14 ++++++++++++++
 tests/Makefile.am       |  3 ++-
 tests/i915/gem_create.c | 16 ++++++++++++----
 tests/meson.build       | 17 +++++++++++++++--
 tests/sw_sync.c         | 12 ++++++------
 9 files changed, 53 insertions(+), 14 deletions(-)

--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[igt-dev] [PATCH i-g-t v3 0/4] Use C11 atomics

[Guillaume Tucker]

This series replaces calls to the __sync_* functions with the more
recent atomic_* ones defined in stdatomic.h in gem_create and
sw_sync.  It also adds dependency on libatomic when required, that is
to say when the CPU architecture doesn't provide native support for
some atomic operations.  This makes the tests more portable, in
particular for 32-bit MIPS which doesn't support 64-bit atomics.

v2:
 - add linker test to only add dependency on libatomic when needed
 - only add libatomic dependency to gem_create and sw_sync
 - use stdatomic.h and _Atomic type modifier
 - explicitly require libatomic in all Docker images

v3:
 - use sub-arch libatomic1 in Debian docker images
 - use null_dep in meson.build

Guillaume Tucker (4):
  meson: add libatomic dependency
  gitlab-ci: add libatomic to docker images
  i915/gem_create: use atomic_* instead of __sync_*
  tests/sw_sync: use atomic_* instead of __sync_*

 Dockerfile.debian       |  1 +
 Dockerfile.debian-arm64 |  1 +
 Dockerfile.debian-armhf |  1 +
 Dockerfile.fedora       |  2 +-
 meson.build             | 14 ++++++++++++++
 tests/Makefile.am       |  3 ++-
 tests/i915/gem_create.c | 16 ++++++++++++----
 tests/meson.build       | 17 +++++++++++++++--
 tests/sw_sync.c         | 12 ++++++------
 9 files changed, 53 insertions(+), 14 deletions(-)

--
2.20.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Guillaume Tucker]

Add conditional dependency on libatomic in order to be able to use the
__atomic_* functions instead of the older __sync_* ones.  The
libatomic library is only needed when there aren't any native support
on the current architecture, so a linker test is used for this
purpose.  This enables atomic operations to be on a wider number of
architectures including MIPS.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---

Notes:
    v2: add linker test for libatomic
    v3: use null_dep

 meson.build | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/meson.build b/meson.build
index 6268c58d3634..118ad667ffb5 100644
--- a/meson.build
+++ b/meson.build
@@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
 dlsym = cc.find_library('dl')
 zlib = cc.find_library('z')
 
+if cc.links('''
+#include <stdint.h>
+int main(void) {
+  uint32_t x32 = 0;
+  uint64_t x64 = 0;
+  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
+  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
+  return 0;
+}''', name : 'built-in atomics')
+	libatomic = null_dep
+else
+	libatomic = cc.find_library('atomic')
+endif
+
 if cc.has_header('linux/kd.h')
 	config.set('HAVE_LINUX_KD_H', 1)
 endif
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Guillaume Tucker]

Add conditional dependency on libatomic in order to be able to use the
__atomic_* functions instead of the older __sync_* ones.  The
libatomic library is only needed when there aren't any native support
on the current architecture, so a linker test is used for this
purpose.  This enables atomic operations to be on a wider number of
architectures including MIPS.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---

Notes:
    v2: add linker test for libatomic
    v3: use null_dep

 meson.build | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/meson.build b/meson.build
index 6268c58d3634..118ad667ffb5 100644
--- a/meson.build
+++ b/meson.build
@@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
 dlsym = cc.find_library('dl')
 zlib = cc.find_library('z')
 
+if cc.links('''
+#include <stdint.h>
+int main(void) {
+  uint32_t x32 = 0;
+  uint64_t x64 = 0;
+  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
+  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
+  return 0;
+}''', name : 'built-in atomics')
+	libatomic = null_dep
+else
+	libatomic = cc.find_library('atomic')
+endif
+
 if cc.has_header('linux/kd.h')
 	config.set('HAVE_LINUX_KD_H', 1)
 endif
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Ser, Simon]

On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> Add conditional dependency on libatomic in order to be able to use the
> __atomic_* functions instead of the older __sync_* ones.  The
> libatomic library is only needed when there aren't any native support
> on the current architecture, so a linker test is used for this
> purpose.  This enables atomic operations to be on a wider number of
> architectures including MIPS.
> 
> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> ---
> 
> Notes:
>     v2: add linker test for libatomic
>     v3: use null_dep
> 
>  meson.build | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/meson.build b/meson.build
> index 6268c58d3634..118ad667ffb5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
>  dlsym = cc.find_library('dl')
>  zlib = cc.find_library('z')
>  
> +if cc.links('''
> +#include <stdint.h>
> +int main(void) {
> +  uint32_t x32 = 0;
> +  uint64_t x64 = 0;
> +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
> +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);

See my reply for v2. I've looked into this a little bit more and it
looks like __atomic_* functions are a GCC implementation detail. OIn
other words, the C11 standard [1] defines only atomic_* functions, and
GCC implements them with __atomic_* builtins when the platform supports
it, but other compilers might not expose those builtins and still
support atomic_* functions without them. This also seems to be what [2]
explains:

> The first set of library functions are named __atomic_*. This set has
> been “standardized” by GCC, and is described below. (See also GCC’s
> documentation)

(Notice the quotes around “standardized”, meaning they are a GCC
extension)

[1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
[2]: https://llvm.org/docs/Atomics.html

> +  return 0;
> +}''', name : 'built-in atomics')
> +	libatomic = null_dep
> +else
> +	libatomic = cc.find_library('atomic')
> +endif
> +
>  if cc.has_header('linux/kd.h')
>  	config.set('HAVE_LINUX_KD_H', 1)
>  endif
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Ser, Simon]

On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> Add conditional dependency on libatomic in order to be able to use the
> __atomic_* functions instead of the older __sync_* ones.  The
> libatomic library is only needed when there aren't any native support
> on the current architecture, so a linker test is used for this
> purpose.  This enables atomic operations to be on a wider number of
> architectures including MIPS.
> 
> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> ---
> 
> Notes:
>     v2: add linker test for libatomic
>     v3: use null_dep
> 
>  meson.build | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/meson.build b/meson.build
> index 6268c58d3634..118ad667ffb5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
>  dlsym = cc.find_library('dl')
>  zlib = cc.find_library('z')
>  
> +if cc.links('''
> +#include <stdint.h>
> +int main(void) {
> +  uint32_t x32 = 0;
> +  uint64_t x64 = 0;
> +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
> +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);

See my reply for v2. I've looked into this a little bit more and it
looks like __atomic_* functions are a GCC implementation detail. OIn
other words, the C11 standard [1] defines only atomic_* functions, and
GCC implements them with __atomic_* builtins when the platform supports
it, but other compilers might not expose those builtins and still
support atomic_* functions without them. This also seems to be what [2]
explains:

> The first set of library functions are named __atomic_*. This set has
> been “standardized” by GCC, and is described below. (See also GCC’s
> documentation)

(Notice the quotes around “standardized”, meaning they are a GCC
extension)

[1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
[2]: https://llvm.org/docs/Atomics.html

> +  return 0;
> +}''', name : 'built-in atomics')
> +	libatomic = null_dep
> +else
> +	libatomic = cc.find_library('atomic')
> +endif
> +
>  if cc.has_header('linux/kd.h')
>  	config.set('HAVE_LINUX_KD_H', 1)
>  endif
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Guillaume Tucker]

On 18/06/2019 14:20, Ser, Simon wrote:
> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
>> Add conditional dependency on libatomic in order to be able to use the
>> __atomic_* functions instead of the older __sync_* ones.  The
>> libatomic library is only needed when there aren't any native support
>> on the current architecture, so a linker test is used for this
>> purpose.  This enables atomic operations to be on a wider number of
>> architectures including MIPS.
>>
>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>> ---
>>
>> Notes:
>>     v2: add linker test for libatomic
>>     v3: use null_dep
>>
>>  meson.build | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/meson.build b/meson.build
>> index 6268c58d3634..118ad667ffb5 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
>>  dlsym = cc.find_library('dl')
>>  zlib = cc.find_library('z')
>>  
>> +if cc.links('''
>> +#include <stdint.h>
>> +int main(void) {
>> +  uint32_t x32 = 0;
>> +  uint64_t x64 = 0;
>> +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
>> +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
> 
> See my reply for v2. I've looked into this a little bit more and it
> looks like __atomic_* functions are a GCC implementation detail. OIn
> other words, the C11 standard [1] defines only atomic_* functions, and
> GCC implements them with __atomic_* builtins when the platform supports
> it, but other compilers might not expose those builtins and still
> support atomic_* functions without them. This also seems to be what [2]
> explains:
> 
>> The first set of library functions are named __atomic_*. This set has
>> been “standardized” by GCC, and is described below. (See also GCC’s
>> documentation)
> 
> (Notice the quotes around “standardized”, meaning they are a GCC
> extension)

Quite, and while the stdatomic.h API is part of the C11 standard,
libatomic is part of GCC.  So this test is to determine whether
linking against GCC's libatomic.so is needed for its __atomic_*
fallback implementation.

It raises the question of what to do with other compilers, but
igt has other build errors with clang on mips at the moment.
With a quick search, it looks like its __atomic_* functions are
part of libclang.so for clang.

Maybe this test should only be used when the compiler name is
gcc?  In practice it does work with both gcc and clang though, as
they both use the same naming convention for atomic built-ins.

Guillaume

> [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> [2]: https://llvm.org/docs/Atomics.html
> 
>> +  return 0;
>> +}''', name : 'built-in atomics')
>> +	libatomic = null_dep
>> +else
>> +	libatomic = cc.find_library('atomic')
>> +endif
>> +
>>  if cc.has_header('linux/kd.h')
>>  	config.set('HAVE_LINUX_KD_H', 1)
>>  endif

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Guillaume Tucker]

On 18/06/2019 14:20, Ser, Simon wrote:
> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
>> Add conditional dependency on libatomic in order to be able to use the
>> __atomic_* functions instead of the older __sync_* ones.  The
>> libatomic library is only needed when there aren't any native support
>> on the current architecture, so a linker test is used for this
>> purpose.  This enables atomic operations to be on a wider number of
>> architectures including MIPS.
>>
>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>> ---
>>
>> Notes:
>>     v2: add linker test for libatomic
>>     v3: use null_dep
>>
>>  meson.build | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/meson.build b/meson.build
>> index 6268c58d3634..118ad667ffb5 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
>>  dlsym = cc.find_library('dl')
>>  zlib = cc.find_library('z')
>>  
>> +if cc.links('''
>> +#include <stdint.h>
>> +int main(void) {
>> +  uint32_t x32 = 0;
>> +  uint64_t x64 = 0;
>> +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
>> +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
> 
> See my reply for v2. I've looked into this a little bit more and it
> looks like __atomic_* functions are a GCC implementation detail. OIn
> other words, the C11 standard [1] defines only atomic_* functions, and
> GCC implements them with __atomic_* builtins when the platform supports
> it, but other compilers might not expose those builtins and still
> support atomic_* functions without them. This also seems to be what [2]
> explains:
> 
>> The first set of library functions are named __atomic_*. This set has
>> been “standardized” by GCC, and is described below. (See also GCC’s
>> documentation)
> 
> (Notice the quotes around “standardized”, meaning they are a GCC
> extension)

Quite, and while the stdatomic.h API is part of the C11 standard,
libatomic is part of GCC.  So this test is to determine whether
linking against GCC's libatomic.so is needed for its __atomic_*
fallback implementation.

It raises the question of what to do with other compilers, but
igt has other build errors with clang on mips at the moment.
With a quick search, it looks like its __atomic_* functions are
part of libclang.so for clang.

Maybe this test should only be used when the compiler name is
gcc?  In practice it does work with both gcc and clang though, as
they both use the same naming convention for atomic built-ins.

Guillaume

> [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> [2]: https://llvm.org/docs/Atomics.html
> 
>> +  return 0;
>> +}''', name : 'built-in atomics')
>> +	libatomic = null_dep
>> +else
>> +	libatomic = cc.find_library('atomic')
>> +endif
>> +
>>  if cc.has_header('linux/kd.h')
>>  	config.set('HAVE_LINUX_KD_H', 1)
>>  endif

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Ser, Simon]

On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
> On 18/06/2019 14:20, Ser, Simon wrote:
> > On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> > > Add conditional dependency on libatomic in order to be able to use the
> > > __atomic_* functions instead of the older __sync_* ones.  The
> > > libatomic library is only needed when there aren't any native support
> > > on the current architecture, so a linker test is used for this
> > > purpose.  This enables atomic operations to be on a wider number of
> > > architectures including MIPS.
> > > 
> > > Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> > > ---
> > > 
> > > Notes:
> > >     v2: add linker test for libatomic
> > >     v3: use null_dep
> > > 
> > >  meson.build | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/meson.build b/meson.build
> > > index 6268c58d3634..118ad667ffb5 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
> > >  dlsym = cc.find_library('dl')
> > >  zlib = cc.find_library('z')
> > >  
> > > +if cc.links('''
> > > +#include <stdint.h>
> > > +int main(void) {
> > > +  uint32_t x32 = 0;
> > > +  uint64_t x64 = 0;
> > > +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
> > > +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
> > 
> > See my reply for v2. I've looked into this a little bit more and it
> > looks like __atomic_* functions are a GCC implementation detail. OIn
> > other words, the C11 standard [1] defines only atomic_* functions, and
> > GCC implements them with __atomic_* builtins when the platform supports
> > it, but other compilers might not expose those builtins and still
> > support atomic_* functions without them. This also seems to be what [2]
> > explains:
> > 
> > > The first set of library functions are named __atomic_*. This set has
> > > been “standardized” by GCC, and is described below. (See also GCC’s
> > > documentation)
> > 
> > (Notice the quotes around “standardized”, meaning they are a GCC
> > extension)
> 
> Quite, and while the stdatomic.h API is part of the C11 standard,
> libatomic is part of GCC.  So this test is to determine whether
> linking against GCC's libatomic.so is needed for its __atomic_*
> fallback implementation.
> 
> It raises the question of what to do with other compilers, but
> igt has other build errors with clang on mips at the moment.
> With a quick search, it looks like its __atomic_* functions are
> part of libclang.so for clang.

I don't see anything in `readelf -s /usr/lib/libclang.so.8`.

> Maybe this test should only be used when the compiler name is
> gcc?  In practice it does work with both gcc and clang though, as
> they both use the same naming convention for atomic built-ins.

Hmm. I'm still not quite sure I understand why checking with __atomic_*
is preferred.

- If the compiler has __atomic_* builtins: this won't link with
  libatomic
- If the compiler doesn't have __atomic_* builtins: this will link with
  libatomic even if stdatomic.h works without it

What we're really interested in is stdatomic.h support, not __atomic_*.
So I still think checking for atomic_* is better than __atomic_*. Am I
missing something?

> Guillaume
> 
> > [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> > [2]: https://llvm.org/docs/Atomics.html
> > 
> > > +  return 0;
> > > +}''', name : 'built-in atomics')
> > > +	libatomic = null_dep
> > > +else
> > > +	libatomic = cc.find_library('atomic')
> > > +endif
> > > +
> > >  if cc.has_header('linux/kd.h')
> > >  	config.set('HAVE_LINUX_KD_H', 1)
> > >  endif
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Ser, Simon]

On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
> On 18/06/2019 14:20, Ser, Simon wrote:
> > On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> > > Add conditional dependency on libatomic in order to be able to use the
> > > __atomic_* functions instead of the older __sync_* ones.  The
> > > libatomic library is only needed when there aren't any native support
> > > on the current architecture, so a linker test is used for this
> > > purpose.  This enables atomic operations to be on a wider number of
> > > architectures including MIPS.
> > > 
> > > Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> > > ---
> > > 
> > > Notes:
> > >     v2: add linker test for libatomic
> > >     v3: use null_dep
> > > 
> > >  meson.build | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/meson.build b/meson.build
> > > index 6268c58d3634..118ad667ffb5 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
> > >  dlsym = cc.find_library('dl')
> > >  zlib = cc.find_library('z')
> > >  
> > > +if cc.links('''
> > > +#include <stdint.h>
> > > +int main(void) {
> > > +  uint32_t x32 = 0;
> > > +  uint64_t x64 = 0;
> > > +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
> > > +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
> > 
> > See my reply for v2. I've looked into this a little bit more and it
> > looks like __atomic_* functions are a GCC implementation detail. OIn
> > other words, the C11 standard [1] defines only atomic_* functions, and
> > GCC implements them with __atomic_* builtins when the platform supports
> > it, but other compilers might not expose those builtins and still
> > support atomic_* functions without them. This also seems to be what [2]
> > explains:
> > 
> > > The first set of library functions are named __atomic_*. This set has
> > > been “standardized” by GCC, and is described below. (See also GCC’s
> > > documentation)
> > 
> > (Notice the quotes around “standardized”, meaning they are a GCC
> > extension)
> 
> Quite, and while the stdatomic.h API is part of the C11 standard,
> libatomic is part of GCC.  So this test is to determine whether
> linking against GCC's libatomic.so is needed for its __atomic_*
> fallback implementation.
> 
> It raises the question of what to do with other compilers, but
> igt has other build errors with clang on mips at the moment.
> With a quick search, it looks like its __atomic_* functions are
> part of libclang.so for clang.

I don't see anything in `readelf -s /usr/lib/libclang.so.8`.

> Maybe this test should only be used when the compiler name is
> gcc?  In practice it does work with both gcc and clang though, as
> they both use the same naming convention for atomic built-ins.

Hmm. I'm still not quite sure I understand why checking with __atomic_*
is preferred.

- If the compiler has __atomic_* builtins: this won't link with
  libatomic
- If the compiler doesn't have __atomic_* builtins: this will link with
  libatomic even if stdatomic.h works without it

What we're really interested in is stdatomic.h support, not __atomic_*.
So I still think checking for atomic_* is better than __atomic_*. Am I
missing something?

> Guillaume
> 
> > [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> > [2]: https://llvm.org/docs/Atomics.html
> > 
> > > +  return 0;
> > > +}''', name : 'built-in atomics')
> > > +	libatomic = null_dep
> > > +else
> > > +	libatomic = cc.find_library('atomic')
> > > +endif
> > > +
> > >  if cc.has_header('linux/kd.h')
> > >  	config.set('HAVE_LINUX_KD_H', 1)
> > >  endif
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Guillaume Tucker]

On 18/06/2019 15:37, Ser, Simon wrote:
> On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
>> On 18/06/2019 14:20, Ser, Simon wrote:
>>> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
>>>> Add conditional dependency on libatomic in order to be able to use the
>>>> __atomic_* functions instead of the older __sync_* ones.  The
>>>> libatomic library is only needed when there aren't any native support
>>>> on the current architecture, so a linker test is used for this
>>>> purpose.  This enables atomic operations to be on a wider number of
>>>> architectures including MIPS.
>>>>
>>>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>>>> ---
>>>>
>>>> Notes:
>>>>     v2: add linker test for libatomic
>>>>     v3: use null_dep
>>>>
>>>>  meson.build | 14 ++++++++++++++
>>>>  1 file changed, 14 insertions(+)
>>>>
>>>> diff --git a/meson.build b/meson.build
>>>> index 6268c58d3634..118ad667ffb5 100644
>>>> --- a/meson.build
>>>> +++ b/meson.build
>>>> @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
>>>>  dlsym = cc.find_library('dl')
>>>>  zlib = cc.find_library('z')
>>>>  
>>>> +if cc.links('''
>>>> +#include <stdint.h>
>>>> +int main(void) {
>>>> +  uint32_t x32 = 0;
>>>> +  uint64_t x64 = 0;
>>>> +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
>>>> +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
>>>
>>> See my reply for v2. I've looked into this a little bit more and it
>>> looks like __atomic_* functions are a GCC implementation detail. OIn
>>> other words, the C11 standard [1] defines only atomic_* functions, and
>>> GCC implements them with __atomic_* builtins when the platform supports
>>> it, but other compilers might not expose those builtins and still
>>> support atomic_* functions without them. This also seems to be what [2]
>>> explains:
>>>
>>>> The first set of library functions are named __atomic_*. This set has
>>>> been “standardized” by GCC, and is described below. (See also GCC’s
>>>> documentation)
>>>
>>> (Notice the quotes around “standardized”, meaning they are a GCC
>>> extension)
>>
>> Quite, and while the stdatomic.h API is part of the C11 standard,
>> libatomic is part of GCC.  So this test is to determine whether
>> linking against GCC's libatomic.so is needed for its __atomic_*
>> fallback implementation.
>>
>> It raises the question of what to do with other compilers, but
>> igt has other build errors with clang on mips at the moment.
>> With a quick search, it looks like its __atomic_* functions are
>> part of libclang.so for clang.
> 
> I don't see anything in `readelf -s /usr/lib/libclang.so.8`.

Yes, well I did this:

$ for f in $(find . -name "*.so"); do strings $f | grep __atomic_load && echo $f; done
__atomic_load
__atomic_load_1
__atomic_load_2
__atomic_load_4
__atomic_load_8
./gcc/mips-linux-gnu/8/libatomic.so
__atomic_load
__atomic_load_1
__atomic_load_2
__atomic_load_4
__atomic_load_8
__atomic_load_16
./mips-linux-gnu/libLLVM-7.so

although it's true that they don't appear as proper symbols with
readelf.  It would take a bit more investigation in the LLVM
source code to get to the bottom of that, but I don't think it's
necessary to solve the problem at hand.

>> Maybe this test should only be used when the compiler name is
>> gcc?  In practice it does work with both gcc and clang though, as
>> they both use the same naming convention for atomic built-ins.
> 
> Hmm. I'm still not quite sure I understand why checking with __atomic_*
> is preferred.
> 
> - If the compiler has __atomic_* builtins: this won't link with
>   libatomic
> - If the compiler doesn't have __atomic_* builtins: this will link with
>   libatomic even if stdatomic.h works without it
> 
> What we're really interested in is stdatomic.h support, not __atomic_*.
> So I still think checking for atomic_* is better than __atomic_*. Am I
> missing something?

I think the issue is that there is no absolute relationship
between stdatomic.h and the __atomic_* functions.  So the test is
currently designed from libatomic's point of view, and it might
add libatomic dependency even if stdatomic.h doesn't use the
__atomic_* functions.  Then conversely, using the C11 atomic_*
instead in the test means that we would add dependency on
libatomic if it fails to link without being completely sure that
it is the missing library.

If you take the current test on its own, it doesn't claim to
cover stdatomic.h support but just libatomic dependency.  So
that's why I prefer it.

But in practice, both variants (__atomic_* and C11 atomic_*) can
be used in the test with existing versions of GCC and I'm not
trying to cover Clang MIPS builds in this series.  I think
there's no perfect solution here, and if you still think it makes
more sense to use the C11 atomic_* functions then fine, I can
change the test to do that instead.

Guillaume

>>> [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
>>> [2]: https://llvm.org/docs/Atomics.html
>>>
>>>> +  return 0;
>>>> +}''', name : 'built-in atomics')
>>>> +	libatomic = null_dep
>>>> +else
>>>> +	libatomic = cc.find_library('atomic')
>>>> +endif
>>>> +
>>>>  if cc.has_header('linux/kd.h')
>>>>  	config.set('HAVE_LINUX_KD_H', 1)
>>>>  endif

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Guillaume Tucker]

On 18/06/2019 15:37, Ser, Simon wrote:
> On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
>> On 18/06/2019 14:20, Ser, Simon wrote:
>>> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
>>>> Add conditional dependency on libatomic in order to be able to use the
>>>> __atomic_* functions instead of the older __sync_* ones.  The
>>>> libatomic library is only needed when there aren't any native support
>>>> on the current architecture, so a linker test is used for this
>>>> purpose.  This enables atomic operations to be on a wider number of
>>>> architectures including MIPS.
>>>>
>>>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>>>> ---
>>>>
>>>> Notes:
>>>>     v2: add linker test for libatomic
>>>>     v3: use null_dep
>>>>
>>>>  meson.build | 14 ++++++++++++++
>>>>  1 file changed, 14 insertions(+)
>>>>
>>>> diff --git a/meson.build b/meson.build
>>>> index 6268c58d3634..118ad667ffb5 100644
>>>> --- a/meson.build
>>>> +++ b/meson.build
>>>> @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
>>>>  dlsym = cc.find_library('dl')
>>>>  zlib = cc.find_library('z')
>>>>  
>>>> +if cc.links('''
>>>> +#include <stdint.h>
>>>> +int main(void) {
>>>> +  uint32_t x32 = 0;
>>>> +  uint64_t x64 = 0;
>>>> +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
>>>> +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
>>>
>>> See my reply for v2. I've looked into this a little bit more and it
>>> looks like __atomic_* functions are a GCC implementation detail. OIn
>>> other words, the C11 standard [1] defines only atomic_* functions, and
>>> GCC implements them with __atomic_* builtins when the platform supports
>>> it, but other compilers might not expose those builtins and still
>>> support atomic_* functions without them. This also seems to be what [2]
>>> explains:
>>>
>>>> The first set of library functions are named __atomic_*. This set has
>>>> been “standardized” by GCC, and is described below. (See also GCC’s
>>>> documentation)
>>>
>>> (Notice the quotes around “standardized”, meaning they are a GCC
>>> extension)
>>
>> Quite, and while the stdatomic.h API is part of the C11 standard,
>> libatomic is part of GCC.  So this test is to determine whether
>> linking against GCC's libatomic.so is needed for its __atomic_*
>> fallback implementation.
>>
>> It raises the question of what to do with other compilers, but
>> igt has other build errors with clang on mips at the moment.
>> With a quick search, it looks like its __atomic_* functions are
>> part of libclang.so for clang.
> 
> I don't see anything in `readelf -s /usr/lib/libclang.so.8`.

Yes, well I did this:

$ for f in $(find . -name "*.so"); do strings $f | grep __atomic_load && echo $f; done
__atomic_load
__atomic_load_1
__atomic_load_2
__atomic_load_4
__atomic_load_8
./gcc/mips-linux-gnu/8/libatomic.so
__atomic_load
__atomic_load_1
__atomic_load_2
__atomic_load_4
__atomic_load_8
__atomic_load_16
./mips-linux-gnu/libLLVM-7.so

although it's true that they don't appear as proper symbols with
readelf.  It would take a bit more investigation in the LLVM
source code to get to the bottom of that, but I don't think it's
necessary to solve the problem at hand.

>> Maybe this test should only be used when the compiler name is
>> gcc?  In practice it does work with both gcc and clang though, as
>> they both use the same naming convention for atomic built-ins.
> 
> Hmm. I'm still not quite sure I understand why checking with __atomic_*
> is preferred.
> 
> - If the compiler has __atomic_* builtins: this won't link with
>   libatomic
> - If the compiler doesn't have __atomic_* builtins: this will link with
>   libatomic even if stdatomic.h works without it
> 
> What we're really interested in is stdatomic.h support, not __atomic_*.
> So I still think checking for atomic_* is better than __atomic_*. Am I
> missing something?

I think the issue is that there is no absolute relationship
between stdatomic.h and the __atomic_* functions.  So the test is
currently designed from libatomic's point of view, and it might
add libatomic dependency even if stdatomic.h doesn't use the
__atomic_* functions.  Then conversely, using the C11 atomic_*
instead in the test means that we would add dependency on
libatomic if it fails to link without being completely sure that
it is the missing library.

If you take the current test on its own, it doesn't claim to
cover stdatomic.h support but just libatomic dependency.  So
that's why I prefer it.

But in practice, both variants (__atomic_* and C11 atomic_*) can
be used in the test with existing versions of GCC and I'm not
trying to cover Clang MIPS builds in this series.  I think
there's no perfect solution here, and if you still think it makes
more sense to use the C11 atomic_* functions then fine, I can
change the test to do that instead.

Guillaume

>>> [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
>>> [2]: https://llvm.org/docs/Atomics.html
>>>
>>>> +  return 0;
>>>> +}''', name : 'built-in atomics')
>>>> +	libatomic = null_dep
>>>> +else
>>>> +	libatomic = cc.find_library('atomic')
>>>> +endif
>>>> +
>>>>  if cc.has_header('linux/kd.h')
>>>>  	config.set('HAVE_LINUX_KD_H', 1)
>>>>  endif

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Ser, Simon]

On Tue, 2019-06-18 at 17:03 +0100, Guillaume Tucker wrote:
> On 18/06/2019 15:37, Ser, Simon wrote:
> > On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
> > > On 18/06/2019 14:20, Ser, Simon wrote:
> > > > On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> > > > > Add conditional dependency on libatomic in order to be able to use the
> > > > > __atomic_* functions instead of the older __sync_* ones.  The
> > > > > libatomic library is only needed when there aren't any native support
> > > > > on the current architecture, so a linker test is used for this
> > > > > purpose.  This enables atomic operations to be on a wider number of
> > > > > architectures including MIPS.
> > > > > 
> > > > > Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> > > > > ---
> > > > > 
> > > > > Notes:
> > > > >     v2: add linker test for libatomic
> > > > >     v3: use null_dep
> > > > > 
> > > > >  meson.build | 14 ++++++++++++++
> > > > >  1 file changed, 14 insertions(+)
> > > > > 
> > > > > diff --git a/meson.build b/meson.build
> > > > > index 6268c58d3634..118ad667ffb5 100644
> > > > > --- a/meson.build
> > > > > +++ b/meson.build
> > > > > @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
> > > > >  dlsym = cc.find_library('dl')
> > > > >  zlib = cc.find_library('z')
> > > > >  
> > > > > +if cc.links('''
> > > > > +#include <stdint.h>
> > > > > +int main(void) {
> > > > > +  uint32_t x32 = 0;
> > > > > +  uint64_t x64 = 0;
> > > > > +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
> > > > > +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
> > > > 
> > > > See my reply for v2. I've looked into this a little bit more and it
> > > > looks like __atomic_* functions are a GCC implementation detail. OIn
> > > > other words, the C11 standard [1] defines only atomic_* functions, and
> > > > GCC implements them with __atomic_* builtins when the platform supports
> > > > it, but other compilers might not expose those builtins and still
> > > > support atomic_* functions without them. This also seems to be what [2]
> > > > explains:
> > > > 
> > > > > The first set of library functions are named __atomic_*. This set has
> > > > > been “standardized” by GCC, and is described below. (See also GCC’s
> > > > > documentation)
> > > > 
> > > > (Notice the quotes around “standardized”, meaning they are a GCC
> > > > extension)
> > > 
> > > Quite, and while the stdatomic.h API is part of the C11 standard,
> > > libatomic is part of GCC.  So this test is to determine whether
> > > linking against GCC's libatomic.so is needed for its __atomic_*
> > > fallback implementation.
> > > 
> > > It raises the question of what to do with other compilers, but
> > > igt has other build errors with clang on mips at the moment.
> > > With a quick search, it looks like its __atomic_* functions are
> > > part of libclang.so for clang.
> > 
> > I don't see anything in `readelf -s /usr/lib/libclang.so.8`.
> 
> Yes, well I did this:
> 
> $ for f in $(find . -name "*.so"); do strings $f | grep __atomic_load && echo $f; done
> __atomic_load
> __atomic_load_1
> __atomic_load_2
> __atomic_load_4
> __atomic_load_8
> ./gcc/mips-linux-gnu/8/libatomic.so
> __atomic_load
> __atomic_load_1
> __atomic_load_2
> __atomic_load_4
> __atomic_load_8
> __atomic_load_16
> ./mips-linux-gnu/libLLVM-7.so
> 
> although it's true that they don't appear as proper symbols with
> readelf.  It would take a bit more investigation in the LLVM
> source code to get to the bottom of that, but I don't think it's
> necessary to solve the problem at hand.

Are you sure these are not undefined symbols? (That is, symbols used in
the library because it's linked to libatomic)

> > > Maybe this test should only be used when the compiler name is
> > > gcc?  In practice it does work with both gcc and clang though, as
> > > they both use the same naming convention for atomic built-ins.
> > 
> > Hmm. I'm still not quite sure I understand why checking with __atomic_*
> > is preferred.
> > 
> > - If the compiler has __atomic_* builtins: this won't link with
> >   libatomic
> > - If the compiler doesn't have __atomic_* builtins: this will link with
> >   libatomic even if stdatomic.h works without it
> > 
> > What we're really interested in is stdatomic.h support, not __atomic_*.
> > So I still think checking for atomic_* is better than __atomic_*. Am I
> > missing something?
> 
> I think the issue is that there is no absolute relationship
> between stdatomic.h and the __atomic_* functions.  So the test is
> currently designed from libatomic's point of view, and it might
> add libatomic dependency even if stdatomic.h doesn't use the
> __atomic_* functions.  Then conversely, using the C11 atomic_*
> instead in the test means that we would add dependency on
> libatomic if it fails to link without being completely sure that
> it is the missing library.
> 
> If you take the current test on its own, it doesn't claim to
> cover stdatomic.h support but just libatomic dependency.  So
> that's why I prefer it.
> 
> But in practice, both variants (__atomic_* and C11 atomic_*) can
> be used in the test with existing versions of GCC and I'm not
> trying to cover Clang MIPS builds in this series.  I think
> there's no perfect solution here, and if you still think it makes
> more sense to use the C11 atomic_* functions then fine, I can
> change the test to do that instead.

Fair enough. We can adjust the check when needed.

Reviewed-by: Simon Ser <simon.ser@intel.com>

> Guillaume
> 
> > > > [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> > > > [2]: https://llvm.org/docs/Atomics.html
> > > > 
> > > > > +  return 0;
> > > > > +}''', name : 'built-in atomics')
> > > > > +	libatomic = null_dep
> > > > > +else
> > > > > +	libatomic = cc.find_library('atomic')
> > > > > +endif
> > > > > +
> > > > >  if cc.has_header('linux/kd.h')
> > > > >  	config.set('HAVE_LINUX_KD_H', 1)
> > > > >  endif
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Ser, Simon]

On Tue, 2019-06-18 at 17:03 +0100, Guillaume Tucker wrote:
> On 18/06/2019 15:37, Ser, Simon wrote:
> > On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
> > > On 18/06/2019 14:20, Ser, Simon wrote:
> > > > On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> > > > > Add conditional dependency on libatomic in order to be able to use the
> > > > > __atomic_* functions instead of the older __sync_* ones.  The
> > > > > libatomic library is only needed when there aren't any native support
> > > > > on the current architecture, so a linker test is used for this
> > > > > purpose.  This enables atomic operations to be on a wider number of
> > > > > architectures including MIPS.
> > > > > 
> > > > > Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> > > > > ---
> > > > > 
> > > > > Notes:
> > > > >     v2: add linker test for libatomic
> > > > >     v3: use null_dep
> > > > > 
> > > > >  meson.build | 14 ++++++++++++++
> > > > >  1 file changed, 14 insertions(+)
> > > > > 
> > > > > diff --git a/meson.build b/meson.build
> > > > > index 6268c58d3634..118ad667ffb5 100644
> > > > > --- a/meson.build
> > > > > +++ b/meson.build
> > > > > @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
> > > > >  dlsym = cc.find_library('dl')
> > > > >  zlib = cc.find_library('z')
> > > > >  
> > > > > +if cc.links('''
> > > > > +#include <stdint.h>
> > > > > +int main(void) {
> > > > > +  uint32_t x32 = 0;
> > > > > +  uint64_t x64 = 0;
> > > > > +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
> > > > > +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
> > > > 
> > > > See my reply for v2. I've looked into this a little bit more and it
> > > > looks like __atomic_* functions are a GCC implementation detail. OIn
> > > > other words, the C11 standard [1] defines only atomic_* functions, and
> > > > GCC implements them with __atomic_* builtins when the platform supports
> > > > it, but other compilers might not expose those builtins and still
> > > > support atomic_* functions without them. This also seems to be what [2]
> > > > explains:
> > > > 
> > > > > The first set of library functions are named __atomic_*. This set has
> > > > > been “standardized” by GCC, and is described below. (See also GCC’s
> > > > > documentation)
> > > > 
> > > > (Notice the quotes around “standardized”, meaning they are a GCC
> > > > extension)
> > > 
> > > Quite, and while the stdatomic.h API is part of the C11 standard,
> > > libatomic is part of GCC.  So this test is to determine whether
> > > linking against GCC's libatomic.so is needed for its __atomic_*
> > > fallback implementation.
> > > 
> > > It raises the question of what to do with other compilers, but
> > > igt has other build errors with clang on mips at the moment.
> > > With a quick search, it looks like its __atomic_* functions are
> > > part of libclang.so for clang.
> > 
> > I don't see anything in `readelf -s /usr/lib/libclang.so.8`.
> 
> Yes, well I did this:
> 
> $ for f in $(find . -name "*.so"); do strings $f | grep __atomic_load && echo $f; done
> __atomic_load
> __atomic_load_1
> __atomic_load_2
> __atomic_load_4
> __atomic_load_8
> ./gcc/mips-linux-gnu/8/libatomic.so
> __atomic_load
> __atomic_load_1
> __atomic_load_2
> __atomic_load_4
> __atomic_load_8
> __atomic_load_16
> ./mips-linux-gnu/libLLVM-7.so
> 
> although it's true that they don't appear as proper symbols with
> readelf.  It would take a bit more investigation in the LLVM
> source code to get to the bottom of that, but I don't think it's
> necessary to solve the problem at hand.

Are you sure these are not undefined symbols? (That is, symbols used in
the library because it's linked to libatomic)

> > > Maybe this test should only be used when the compiler name is
> > > gcc?  In practice it does work with both gcc and clang though, as
> > > they both use the same naming convention for atomic built-ins.
> > 
> > Hmm. I'm still not quite sure I understand why checking with __atomic_*
> > is preferred.
> > 
> > - If the compiler has __atomic_* builtins: this won't link with
> >   libatomic
> > - If the compiler doesn't have __atomic_* builtins: this will link with
> >   libatomic even if stdatomic.h works without it
> > 
> > What we're really interested in is stdatomic.h support, not __atomic_*.
> > So I still think checking for atomic_* is better than __atomic_*. Am I
> > missing something?
> 
> I think the issue is that there is no absolute relationship
> between stdatomic.h and the __atomic_* functions.  So the test is
> currently designed from libatomic's point of view, and it might
> add libatomic dependency even if stdatomic.h doesn't use the
> __atomic_* functions.  Then conversely, using the C11 atomic_*
> instead in the test means that we would add dependency on
> libatomic if it fails to link without being completely sure that
> it is the missing library.
> 
> If you take the current test on its own, it doesn't claim to
> cover stdatomic.h support but just libatomic dependency.  So
> that's why I prefer it.
> 
> But in practice, both variants (__atomic_* and C11 atomic_*) can
> be used in the test with existing versions of GCC and I'm not
> trying to cover Clang MIPS builds in this series.  I think
> there's no perfect solution here, and if you still think it makes
> more sense to use the C11 atomic_* functions then fine, I can
> change the test to do that instead.

Fair enough. We can adjust the check when needed.

Reviewed-by: Simon Ser <simon.ser@intel.com>

> Guillaume
> 
> > > > [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> > > > [2]: https://llvm.org/docs/Atomics.html
> > > > 
> > > > > +  return 0;
> > > > > +}''', name : 'built-in atomics')
> > > > > +	libatomic = null_dep
> > > > > +else
> > > > > +	libatomic = cc.find_library('atomic')
> > > > > +endif
> > > > > +
> > > > >  if cc.has_header('linux/kd.h')
> > > > >  	config.set('HAVE_LINUX_KD_H', 1)
> > > > >  endif
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Guillaume Tucker]

On 19/06/2019 07:42, Ser, Simon wrote:
> On Tue, 2019-06-18 at 17:03 +0100, Guillaume Tucker wrote:
>> On 18/06/2019 15:37, Ser, Simon wrote:
>>> On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
>>>> On 18/06/2019 14:20, Ser, Simon wrote:
>>>>> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
>>>>>> Add conditional dependency on libatomic in order to be able to use the
>>>>>> __atomic_* functions instead of the older __sync_* ones.  The
>>>>>> libatomic library is only needed when there aren't any native support
>>>>>> on the current architecture, so a linker test is used for this
>>>>>> purpose.  This enables atomic operations to be on a wider number of
>>>>>> architectures including MIPS.
>>>>>>
>>>>>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>>>>>> ---
>>>>>>
>>>>>> Notes:
>>>>>>     v2: add linker test for libatomic
>>>>>>     v3: use null_dep
>>>>>>
>>>>>>  meson.build | 14 ++++++++++++++
>>>>>>  1 file changed, 14 insertions(+)
>>>>>>
>>>>>> diff --git a/meson.build b/meson.build
>>>>>> index 6268c58d3634..118ad667ffb5 100644
>>>>>> --- a/meson.build
>>>>>> +++ b/meson.build
>>>>>> @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
>>>>>>  dlsym = cc.find_library('dl')
>>>>>>  zlib = cc.find_library('z')
>>>>>>  
>>>>>> +if cc.links('''
>>>>>> +#include <stdint.h>
>>>>>> +int main(void) {
>>>>>> +  uint32_t x32 = 0;
>>>>>> +  uint64_t x64 = 0;
>>>>>> +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
>>>>>> +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
>>>>>
>>>>> See my reply for v2. I've looked into this a little bit more and it
>>>>> looks like __atomic_* functions are a GCC implementation detail. OIn
>>>>> other words, the C11 standard [1] defines only atomic_* functions, and
>>>>> GCC implements them with __atomic_* builtins when the platform supports
>>>>> it, but other compilers might not expose those builtins and still
>>>>> support atomic_* functions without them. This also seems to be what [2]
>>>>> explains:
>>>>>
>>>>>> The first set of library functions are named __atomic_*. This set has
>>>>>> been “standardized” by GCC, and is described below. (See also GCC’s
>>>>>> documentation)
>>>>>
>>>>> (Notice the quotes around “standardized”, meaning they are a GCC
>>>>> extension)
>>>>
>>>> Quite, and while the stdatomic.h API is part of the C11 standard,
>>>> libatomic is part of GCC.  So this test is to determine whether
>>>> linking against GCC's libatomic.so is needed for its __atomic_*
>>>> fallback implementation.
>>>>
>>>> It raises the question of what to do with other compilers, but
>>>> igt has other build errors with clang on mips at the moment.
>>>> With a quick search, it looks like its __atomic_* functions are
>>>> part of libclang.so for clang.
>>>
>>> I don't see anything in `readelf -s /usr/lib/libclang.so.8`.
>>
>> Yes, well I did this:
>>
>> $ for f in $(find . -name "*.so"); do strings $f | grep __atomic_load && echo $f; done
>> __atomic_load
>> __atomic_load_1
>> __atomic_load_2
>> __atomic_load_4
>> __atomic_load_8
>> ./gcc/mips-linux-gnu/8/libatomic.so
>> __atomic_load
>> __atomic_load_1
>> __atomic_load_2
>> __atomic_load_4
>> __atomic_load_8
>> __atomic_load_16
>> ./mips-linux-gnu/libLLVM-7.so
>>
>> although it's true that they don't appear as proper symbols with
>> readelf.  It would take a bit more investigation in the LLVM
>> source code to get to the bottom of that, but I don't think it's
>> necessary to solve the problem at hand.
> 
> Are you sure these are not undefined symbols? (That is, symbols used in
> the library because it's linked to libatomic)

I'm not sure but I would be surprised if LLVM was linked against
GCC's libatomic library.

>>>> Maybe this test should only be used when the compiler name is
>>>> gcc?  In practice it does work with both gcc and clang though, as
>>>> they both use the same naming convention for atomic built-ins.
>>>
>>> Hmm. I'm still not quite sure I understand why checking with __atomic_*
>>> is preferred.
>>>
>>> - If the compiler has __atomic_* builtins: this won't link with
>>>   libatomic
>>> - If the compiler doesn't have __atomic_* builtins: this will link with
>>>   libatomic even if stdatomic.h works without it
>>>
>>> What we're really interested in is stdatomic.h support, not __atomic_*.
>>> So I still think checking for atomic_* is better than __atomic_*. Am I
>>> missing something?
>>
>> I think the issue is that there is no absolute relationship
>> between stdatomic.h and the __atomic_* functions.  So the test is
>> currently designed from libatomic's point of view, and it might
>> add libatomic dependency even if stdatomic.h doesn't use the
>> __atomic_* functions.  Then conversely, using the C11 atomic_*
>> instead in the test means that we would add dependency on
>> libatomic if it fails to link without being completely sure that
>> it is the missing library.
>>
>> If you take the current test on its own, it doesn't claim to
>> cover stdatomic.h support but just libatomic dependency.  So
>> that's why I prefer it.
>>
>> But in practice, both variants (__atomic_* and C11 atomic_*) can
>> be used in the test with existing versions of GCC and I'm not
>> trying to cover Clang MIPS builds in this series.  I think
>> there's no perfect solution here, and if you still think it makes
>> more sense to use the C11 atomic_* functions then fine, I can
>> change the test to do that instead.
> 
> Fair enough. We can adjust the check when needed.
> 
> Reviewed-by: Simon Ser <simon.ser@intel.com>

Thanks,
Guillaume

>>>>> [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
>>>>> [2]: https://llvm.org/docs/Atomics.html
>>>>>
>>>>>> +  return 0;
>>>>>> +}''', name : 'built-in atomics')
>>>>>> +	libatomic = null_dep
>>>>>> +else
>>>>>> +	libatomic = cc.find_library('atomic')
>>>>>> +endif
>>>>>> +
>>>>>>  if cc.has_header('linux/kd.h')
>>>>>>  	config.set('HAVE_LINUX_KD_H', 1)
>>>>>>  endif

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t v3 1/4] meson: add libatomic dependency

[Guillaume Tucker]

On 19/06/2019 07:42, Ser, Simon wrote:
> On Tue, 2019-06-18 at 17:03 +0100, Guillaume Tucker wrote:
>> On 18/06/2019 15:37, Ser, Simon wrote:
>>> On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
>>>> On 18/06/2019 14:20, Ser, Simon wrote:
>>>>> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
>>>>>> Add conditional dependency on libatomic in order to be able to use the
>>>>>> __atomic_* functions instead of the older __sync_* ones.  The
>>>>>> libatomic library is only needed when there aren't any native support
>>>>>> on the current architecture, so a linker test is used for this
>>>>>> purpose.  This enables atomic operations to be on a wider number of
>>>>>> architectures including MIPS.
>>>>>>
>>>>>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>>>>>> ---
>>>>>>
>>>>>> Notes:
>>>>>>     v2: add linker test for libatomic
>>>>>>     v3: use null_dep
>>>>>>
>>>>>>  meson.build | 14 ++++++++++++++
>>>>>>  1 file changed, 14 insertions(+)
>>>>>>
>>>>>> diff --git a/meson.build b/meson.build
>>>>>> index 6268c58d3634..118ad667ffb5 100644
>>>>>> --- a/meson.build
>>>>>> +++ b/meson.build
>>>>>> @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
>>>>>>  dlsym = cc.find_library('dl')
>>>>>>  zlib = cc.find_library('z')
>>>>>>  
>>>>>> +if cc.links('''
>>>>>> +#include <stdint.h>
>>>>>> +int main(void) {
>>>>>> +  uint32_t x32 = 0;
>>>>>> +  uint64_t x64 = 0;
>>>>>> +  __atomic_load_n(&x32, __ATOMIC_SEQ_CST);
>>>>>> +  __atomic_load_n(&x64, __ATOMIC_SEQ_CST);
>>>>>
>>>>> See my reply for v2. I've looked into this a little bit more and it
>>>>> looks like __atomic_* functions are a GCC implementation detail. OIn
>>>>> other words, the C11 standard [1] defines only atomic_* functions, and
>>>>> GCC implements them with __atomic_* builtins when the platform supports
>>>>> it, but other compilers might not expose those builtins and still
>>>>> support atomic_* functions without them. This also seems to be what [2]
>>>>> explains:
>>>>>
>>>>>> The first set of library functions are named __atomic_*. This set has
>>>>>> been “standardized” by GCC, and is described below. (See also GCC’s
>>>>>> documentation)
>>>>>
>>>>> (Notice the quotes around “standardized”, meaning they are a GCC
>>>>> extension)
>>>>
>>>> Quite, and while the stdatomic.h API is part of the C11 standard,
>>>> libatomic is part of GCC.  So this test is to determine whether
>>>> linking against GCC's libatomic.so is needed for its __atomic_*
>>>> fallback implementation.
>>>>
>>>> It raises the question of what to do with other compilers, but
>>>> igt has other build errors with clang on mips at the moment.
>>>> With a quick search, it looks like its __atomic_* functions are
>>>> part of libclang.so for clang.
>>>
>>> I don't see anything in `readelf -s /usr/lib/libclang.so.8`.
>>
>> Yes, well I did this:
>>
>> $ for f in $(find . -name "*.so"); do strings $f | grep __atomic_load && echo $f; done
>> __atomic_load
>> __atomic_load_1
>> __atomic_load_2
>> __atomic_load_4
>> __atomic_load_8
>> ./gcc/mips-linux-gnu/8/libatomic.so
>> __atomic_load
>> __atomic_load_1
>> __atomic_load_2
>> __atomic_load_4
>> __atomic_load_8
>> __atomic_load_16
>> ./mips-linux-gnu/libLLVM-7.so
>>
>> although it's true that they don't appear as proper symbols with
>> readelf.  It would take a bit more investigation in the LLVM
>> source code to get to the bottom of that, but I don't think it's
>> necessary to solve the problem at hand.
> 
> Are you sure these are not undefined symbols? (That is, symbols used in
> the library because it's linked to libatomic)

I'm not sure but I would be surprised if LLVM was linked against
GCC's libatomic library.

>>>> Maybe this test should only be used when the compiler name is
>>>> gcc?  In practice it does work with both gcc and clang though, as
>>>> they both use the same naming convention for atomic built-ins.
>>>
>>> Hmm. I'm still not quite sure I understand why checking with __atomic_*
>>> is preferred.
>>>
>>> - If the compiler has __atomic_* builtins: this won't link with
>>>   libatomic
>>> - If the compiler doesn't have __atomic_* builtins: this will link with
>>>   libatomic even if stdatomic.h works without it
>>>
>>> What we're really interested in is stdatomic.h support, not __atomic_*.
>>> So I still think checking for atomic_* is better than __atomic_*. Am I
>>> missing something?
>>
>> I think the issue is that there is no absolute relationship
>> between stdatomic.h and the __atomic_* functions.  So the test is
>> currently designed from libatomic's point of view, and it might
>> add libatomic dependency even if stdatomic.h doesn't use the
>> __atomic_* functions.  Then conversely, using the C11 atomic_*
>> instead in the test means that we would add dependency on
>> libatomic if it fails to link without being completely sure that
>> it is the missing library.
>>
>> If you take the current test on its own, it doesn't claim to
>> cover stdatomic.h support but just libatomic dependency.  So
>> that's why I prefer it.
>>
>> But in practice, both variants (__atomic_* and C11 atomic_*) can
>> be used in the test with existing versions of GCC and I'm not
>> trying to cover Clang MIPS builds in this series.  I think
>> there's no perfect solution here, and if you still think it makes
>> more sense to use the C11 atomic_* functions then fine, I can
>> change the test to do that instead.
> 
> Fair enough. We can adjust the check when needed.
> 
> Reviewed-by: Simon Ser <simon.ser@intel.com>

Thanks,
Guillaume

>>>>> [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
>>>>> [2]: https://llvm.org/docs/Atomics.html
>>>>>
>>>>>> +  return 0;
>>>>>> +}''', name : 'built-in atomics')
>>>>>> +	libatomic = null_dep
>>>>>> +else
>>>>>> +	libatomic = cc.find_library('atomic')
>>>>>> +endif
>>>>>> +
>>>>>>  if cc.has_header('linux/kd.h')
>>>>>>  	config.set('HAVE_LINUX_KD_H', 1)
>>>>>>  endif

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[PATCH i-g-t v3 2/4] gitlab-ci: add libatomic to docker images

[Guillaume Tucker]

Add libatomic to the Fedora docker image so it can link binaries that
use __atomic_* functions.  Also explicitly add libatomic1 to Debian
docker images as it is needed in particular on non-x86 architectures
for run-time linkage.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---

Notes:
    v2: add libatomic1 in Debian docker images
    v3: add libatomic1 for non-x86 arches in Debian docker images

 Dockerfile.debian       | 1 +
 Dockerfile.debian-arm64 | 1 +
 Dockerfile.debian-armhf | 1 +
 Dockerfile.fedora       | 2 +-
 4 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Dockerfile.debian b/Dockerfile.debian
index b9c3be3945e0..d23591850c4e 100644
--- a/Dockerfile.debian
+++ b/Dockerfile.debian
@@ -6,6 +6,7 @@ RUN apt-get install -y \
 			flex \
 			bison \
 			pkg-config \
+			libatomic1 \
 			libpciaccess-dev \
 			libkmod-dev \
 			libprocps-dev \
diff --git a/Dockerfile.debian-arm64 b/Dockerfile.debian-arm64
index 7b3a3c7ca803..c9fb28c804b8 100644
--- a/Dockerfile.debian-arm64
+++ b/Dockerfile.debian-arm64
@@ -14,6 +14,7 @@ RUN dpkg --add-architecture arm64
 RUN apt-get update
 RUN apt-get install -y \
 			gcc-aarch64-linux-gnu \
+			libatomic1:arm64 \
 			libpciaccess-dev:arm64 \
 			libkmod-dev:arm64 \
 			libprocps-dev:arm64 \
diff --git a/Dockerfile.debian-armhf b/Dockerfile.debian-armhf
index c67a1e2acf6a..3a133d849d68 100644
--- a/Dockerfile.debian-armhf
+++ b/Dockerfile.debian-armhf
@@ -14,6 +14,7 @@ RUN dpkg --add-architecture armhf
 RUN apt-get update
 RUN apt-get install -y \
 			gcc-arm-linux-gnueabihf \
+			libatomic1:armhf \
 			libpciaccess-dev:armhf \
 			libkmod-dev:armhf \
 			libprocps-dev:armhf \
diff --git a/Dockerfile.fedora b/Dockerfile.fedora
index 6686e587613d..c84b412b0723 100644
--- a/Dockerfile.fedora
+++ b/Dockerfile.fedora
@@ -1,7 +1,7 @@
 FROM fedora:30
 
 RUN dnf install -y \
-	gcc flex bison meson ninja-build xdotool \
+	gcc flex bison libatomic meson ninja-build xdotool \
 	'pkgconfig(libdrm)' \
 	'pkgconfig(pciaccess)' \
 	'pkgconfig(libkmod)' \
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[igt-dev] [PATCH i-g-t v3 2/4] gitlab-ci: add libatomic to docker images

[Guillaume Tucker]

Add libatomic to the Fedora docker image so it can link binaries that
use __atomic_* functions.  Also explicitly add libatomic1 to Debian
docker images as it is needed in particular on non-x86 architectures
for run-time linkage.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---

Notes:
    v2: add libatomic1 in Debian docker images
    v3: add libatomic1 for non-x86 arches in Debian docker images

 Dockerfile.debian       | 1 +
 Dockerfile.debian-arm64 | 1 +
 Dockerfile.debian-armhf | 1 +
 Dockerfile.fedora       | 2 +-
 4 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Dockerfile.debian b/Dockerfile.debian
index b9c3be3945e0..d23591850c4e 100644
--- a/Dockerfile.debian
+++ b/Dockerfile.debian
@@ -6,6 +6,7 @@ RUN apt-get install -y \
 			flex \
 			bison \
 			pkg-config \
+			libatomic1 \
 			libpciaccess-dev \
 			libkmod-dev \
 			libprocps-dev \
diff --git a/Dockerfile.debian-arm64 b/Dockerfile.debian-arm64
index 7b3a3c7ca803..c9fb28c804b8 100644
--- a/Dockerfile.debian-arm64
+++ b/Dockerfile.debian-arm64
@@ -14,6 +14,7 @@ RUN dpkg --add-architecture arm64
 RUN apt-get update
 RUN apt-get install -y \
 			gcc-aarch64-linux-gnu \
+			libatomic1:arm64 \
 			libpciaccess-dev:arm64 \
 			libkmod-dev:arm64 \
 			libprocps-dev:arm64 \
diff --git a/Dockerfile.debian-armhf b/Dockerfile.debian-armhf
index c67a1e2acf6a..3a133d849d68 100644
--- a/Dockerfile.debian-armhf
+++ b/Dockerfile.debian-armhf
@@ -14,6 +14,7 @@ RUN dpkg --add-architecture armhf
 RUN apt-get update
 RUN apt-get install -y \
 			gcc-arm-linux-gnueabihf \
+			libatomic1:armhf \
 			libpciaccess-dev:armhf \
 			libkmod-dev:armhf \
 			libprocps-dev:armhf \
diff --git a/Dockerfile.fedora b/Dockerfile.fedora
index 6686e587613d..c84b412b0723 100644
--- a/Dockerfile.fedora
+++ b/Dockerfile.fedora
@@ -1,7 +1,7 @@
 FROM fedora:30
 
 RUN dnf install -y \
-	gcc flex bison meson ninja-build xdotool \
+	gcc flex bison libatomic meson ninja-build xdotool \
 	'pkgconfig(libdrm)' \
 	'pkgconfig(pciaccess)' \
 	'pkgconfig(libkmod)' \
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v3 2/4] gitlab-ci: add libatomic to docker images

[Ser, Simon]

On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> Add libatomic to the Fedora docker image so it can link binaries that
> use __atomic_* functions.  Also explicitly add libatomic1 to Debian
> docker images as it is needed in particular on non-x86 architectures
> for run-time linkage.

Per "[PATCH i-g-t v3 1/4] meson: add libatomic dependency", do we need
libatomic for all of these images?

> 
> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> ---
> 
> Notes:
>     v2: add libatomic1 in Debian docker images
>     v3: add libatomic1 for non-x86 arches in Debian docker images
> 
>  Dockerfile.debian       | 1 +
>  Dockerfile.debian-arm64 | 1 +
>  Dockerfile.debian-armhf | 1 +
>  Dockerfile.fedora       | 2 +-
>  4 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Dockerfile.debian b/Dockerfile.debian
> index b9c3be3945e0..d23591850c4e 100644
> --- a/Dockerfile.debian
> +++ b/Dockerfile.debian
> @@ -6,6 +6,7 @@ RUN apt-get install -y \
>  			flex \
>  			bison \
>  			pkg-config \
> +			libatomic1 \
>  			libpciaccess-dev \
>  			libkmod-dev \
>  			libprocps-dev \
> diff --git a/Dockerfile.debian-arm64 b/Dockerfile.debian-arm64
> index 7b3a3c7ca803..c9fb28c804b8 100644
> --- a/Dockerfile.debian-arm64
> +++ b/Dockerfile.debian-arm64
> @@ -14,6 +14,7 @@ RUN dpkg --add-architecture arm64
>  RUN apt-get update
>  RUN apt-get install -y \
>  			gcc-aarch64-linux-gnu \
> +			libatomic1:arm64 \
>  			libpciaccess-dev:arm64 \
>  			libkmod-dev:arm64 \
>  			libprocps-dev:arm64 \
> diff --git a/Dockerfile.debian-armhf b/Dockerfile.debian-armhf
> index c67a1e2acf6a..3a133d849d68 100644
> --- a/Dockerfile.debian-armhf
> +++ b/Dockerfile.debian-armhf
> @@ -14,6 +14,7 @@ RUN dpkg --add-architecture armhf
>  RUN apt-get update
>  RUN apt-get install -y \
>  			gcc-arm-linux-gnueabihf \
> +			libatomic1:armhf \
>  			libpciaccess-dev:armhf \
>  			libkmod-dev:armhf \
>  			libprocps-dev:armhf \
> diff --git a/Dockerfile.fedora b/Dockerfile.fedora
> index 6686e587613d..c84b412b0723 100644
> --- a/Dockerfile.fedora
> +++ b/Dockerfile.fedora
> @@ -1,7 +1,7 @@
>  FROM fedora:30
>  
>  RUN dnf install -y \
> -	gcc flex bison meson ninja-build xdotool \
> +	gcc flex bison libatomic meson ninja-build xdotool \
>  	'pkgconfig(libdrm)' \
>  	'pkgconfig(pciaccess)' \
>  	'pkgconfig(libkmod)' \
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t v3 2/4] gitlab-ci: add libatomic to docker images

[Ser, Simon]

On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> Add libatomic to the Fedora docker image so it can link binaries that
> use __atomic_* functions.  Also explicitly add libatomic1 to Debian
> docker images as it is needed in particular on non-x86 architectures
> for run-time linkage.

Per "[PATCH i-g-t v3 1/4] meson: add libatomic dependency", do we need
libatomic for all of these images?

> 
> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> ---
> 
> Notes:
>     v2: add libatomic1 in Debian docker images
>     v3: add libatomic1 for non-x86 arches in Debian docker images
> 
>  Dockerfile.debian       | 1 +
>  Dockerfile.debian-arm64 | 1 +
>  Dockerfile.debian-armhf | 1 +
>  Dockerfile.fedora       | 2 +-
>  4 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Dockerfile.debian b/Dockerfile.debian
> index b9c3be3945e0..d23591850c4e 100644
> --- a/Dockerfile.debian
> +++ b/Dockerfile.debian
> @@ -6,6 +6,7 @@ RUN apt-get install -y \
>  			flex \
>  			bison \
>  			pkg-config \
> +			libatomic1 \
>  			libpciaccess-dev \
>  			libkmod-dev \
>  			libprocps-dev \
> diff --git a/Dockerfile.debian-arm64 b/Dockerfile.debian-arm64
> index 7b3a3c7ca803..c9fb28c804b8 100644
> --- a/Dockerfile.debian-arm64
> +++ b/Dockerfile.debian-arm64
> @@ -14,6 +14,7 @@ RUN dpkg --add-architecture arm64
>  RUN apt-get update
>  RUN apt-get install -y \
>  			gcc-aarch64-linux-gnu \
> +			libatomic1:arm64 \
>  			libpciaccess-dev:arm64 \
>  			libkmod-dev:arm64 \
>  			libprocps-dev:arm64 \
> diff --git a/Dockerfile.debian-armhf b/Dockerfile.debian-armhf
> index c67a1e2acf6a..3a133d849d68 100644
> --- a/Dockerfile.debian-armhf
> +++ b/Dockerfile.debian-armhf
> @@ -14,6 +14,7 @@ RUN dpkg --add-architecture armhf
>  RUN apt-get update
>  RUN apt-get install -y \
>  			gcc-arm-linux-gnueabihf \
> +			libatomic1:armhf \
>  			libpciaccess-dev:armhf \
>  			libkmod-dev:armhf \
>  			libprocps-dev:armhf \
> diff --git a/Dockerfile.fedora b/Dockerfile.fedora
> index 6686e587613d..c84b412b0723 100644
> --- a/Dockerfile.fedora
> +++ b/Dockerfile.fedora
> @@ -1,7 +1,7 @@
>  FROM fedora:30
>  
>  RUN dnf install -y \
> -	gcc flex bison meson ninja-build xdotool \
> +	gcc flex bison libatomic meson ninja-build xdotool \
>  	'pkgconfig(libdrm)' \
>  	'pkgconfig(pciaccess)' \
>  	'pkgconfig(libkmod)' \
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v3 2/4] gitlab-ci: add libatomic to docker images

[Guillaume Tucker]

On 19/06/2019 07:50, Ser, Simon wrote:
> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
>> Add libatomic to the Fedora docker image so it can link binaries that
>> use __atomic_* functions.  Also explicitly add libatomic1 to Debian
>> docker images as it is needed in particular on non-x86 architectures
>> for run-time linkage.
> 
> Per "[PATCH i-g-t v3 1/4] meson: add libatomic dependency", do we need
> libatomic for all of these images?

I suppose it's safer to include it, so if the linker test in
meson.build does happen to add the dependency it will actually
work.  Also as per an earlier comment:

  [PATCH i-g-t 2/4] gitlab-ci: add libatomic to Fedora docker image

  On 06/06/2019 08:26, Ser, Simon wrote:
  >> I wonder how does the libatomic gets installed implicitly in Debian.
  > It's a dependency of GCC. Probably a good idea to add it anyway?

It's true that we may optimise this a bit by checking for every
arch whether the test is expected to always pass or not and drop
the libatomic1 sub-arch package for those that link fine without
it.  I suspect only the mips version really needs it, the CI jobs
can help us confirm that.  Does that seem worth doing?

Guillaume

>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>> ---
>>
>> Notes:
>>     v2: add libatomic1 in Debian docker images
>>     v3: add libatomic1 for non-x86 arches in Debian docker images
>>
>>  Dockerfile.debian       | 1 +
>>  Dockerfile.debian-arm64 | 1 +
>>  Dockerfile.debian-armhf | 1 +
>>  Dockerfile.fedora       | 2 +-
>>  4 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Dockerfile.debian b/Dockerfile.debian
>> index b9c3be3945e0..d23591850c4e 100644
>> --- a/Dockerfile.debian
>> +++ b/Dockerfile.debian
>> @@ -6,6 +6,7 @@ RUN apt-get install -y \
>>  			flex \
>>  			bison \
>>  			pkg-config \
>> +			libatomic1 \
>>  			libpciaccess-dev \
>>  			libkmod-dev \
>>  			libprocps-dev \
>> diff --git a/Dockerfile.debian-arm64 b/Dockerfile.debian-arm64
>> index 7b3a3c7ca803..c9fb28c804b8 100644
>> --- a/Dockerfile.debian-arm64
>> +++ b/Dockerfile.debian-arm64
>> @@ -14,6 +14,7 @@ RUN dpkg --add-architecture arm64
>>  RUN apt-get update
>>  RUN apt-get install -y \
>>  			gcc-aarch64-linux-gnu \
>> +			libatomic1:arm64 \
>>  			libpciaccess-dev:arm64 \
>>  			libkmod-dev:arm64 \
>>  			libprocps-dev:arm64 \
>> diff --git a/Dockerfile.debian-armhf b/Dockerfile.debian-armhf
>> index c67a1e2acf6a..3a133d849d68 100644
>> --- a/Dockerfile.debian-armhf
>> +++ b/Dockerfile.debian-armhf
>> @@ -14,6 +14,7 @@ RUN dpkg --add-architecture armhf
>>  RUN apt-get update
>>  RUN apt-get install -y \
>>  			gcc-arm-linux-gnueabihf \
>> +			libatomic1:armhf \
>>  			libpciaccess-dev:armhf \
>>  			libkmod-dev:armhf \
>>  			libprocps-dev:armhf \
>> diff --git a/Dockerfile.fedora b/Dockerfile.fedora
>> index 6686e587613d..c84b412b0723 100644
>> --- a/Dockerfile.fedora
>> +++ b/Dockerfile.fedora
>> @@ -1,7 +1,7 @@
>>  FROM fedora:30
>>  
>>  RUN dnf install -y \
>> -	gcc flex bison meson ninja-build xdotool \
>> +	gcc flex bison libatomic meson ninja-build xdotool \
>>  	'pkgconfig(libdrm)' \
>>  	'pkgconfig(pciaccess)' \
>>  	'pkgconfig(libkmod)' \

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t v3 2/4] gitlab-ci: add libatomic to docker images

[Guillaume Tucker]

On 19/06/2019 07:50, Ser, Simon wrote:
> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
>> Add libatomic to the Fedora docker image so it can link binaries that
>> use __atomic_* functions.  Also explicitly add libatomic1 to Debian
>> docker images as it is needed in particular on non-x86 architectures
>> for run-time linkage.
> 
> Per "[PATCH i-g-t v3 1/4] meson: add libatomic dependency", do we need
> libatomic for all of these images?

I suppose it's safer to include it, so if the linker test in
meson.build does happen to add the dependency it will actually
work.  Also as per an earlier comment:

  [PATCH i-g-t 2/4] gitlab-ci: add libatomic to Fedora docker image

  On 06/06/2019 08:26, Ser, Simon wrote:
  >> I wonder how does the libatomic gets installed implicitly in Debian.
  > It's a dependency of GCC. Probably a good idea to add it anyway?

It's true that we may optimise this a bit by checking for every
arch whether the test is expected to always pass or not and drop
the libatomic1 sub-arch package for those that link fine without
it.  I suspect only the mips version really needs it, the CI jobs
can help us confirm that.  Does that seem worth doing?

Guillaume

>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>> ---
>>
>> Notes:
>>     v2: add libatomic1 in Debian docker images
>>     v3: add libatomic1 for non-x86 arches in Debian docker images
>>
>>  Dockerfile.debian       | 1 +
>>  Dockerfile.debian-arm64 | 1 +
>>  Dockerfile.debian-armhf | 1 +
>>  Dockerfile.fedora       | 2 +-
>>  4 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Dockerfile.debian b/Dockerfile.debian
>> index b9c3be3945e0..d23591850c4e 100644
>> --- a/Dockerfile.debian
>> +++ b/Dockerfile.debian
>> @@ -6,6 +6,7 @@ RUN apt-get install -y \
>>  			flex \
>>  			bison \
>>  			pkg-config \
>> +			libatomic1 \
>>  			libpciaccess-dev \
>>  			libkmod-dev \
>>  			libprocps-dev \
>> diff --git a/Dockerfile.debian-arm64 b/Dockerfile.debian-arm64
>> index 7b3a3c7ca803..c9fb28c804b8 100644
>> --- a/Dockerfile.debian-arm64
>> +++ b/Dockerfile.debian-arm64
>> @@ -14,6 +14,7 @@ RUN dpkg --add-architecture arm64
>>  RUN apt-get update
>>  RUN apt-get install -y \
>>  			gcc-aarch64-linux-gnu \
>> +			libatomic1:arm64 \
>>  			libpciaccess-dev:arm64 \
>>  			libkmod-dev:arm64 \
>>  			libprocps-dev:arm64 \
>> diff --git a/Dockerfile.debian-armhf b/Dockerfile.debian-armhf
>> index c67a1e2acf6a..3a133d849d68 100644
>> --- a/Dockerfile.debian-armhf
>> +++ b/Dockerfile.debian-armhf
>> @@ -14,6 +14,7 @@ RUN dpkg --add-architecture armhf
>>  RUN apt-get update
>>  RUN apt-get install -y \
>>  			gcc-arm-linux-gnueabihf \
>> +			libatomic1:armhf \
>>  			libpciaccess-dev:armhf \
>>  			libkmod-dev:armhf \
>>  			libprocps-dev:armhf \
>> diff --git a/Dockerfile.fedora b/Dockerfile.fedora
>> index 6686e587613d..c84b412b0723 100644
>> --- a/Dockerfile.fedora
>> +++ b/Dockerfile.fedora
>> @@ -1,7 +1,7 @@
>>  FROM fedora:30
>>  
>>  RUN dnf install -y \
>> -	gcc flex bison meson ninja-build xdotool \
>> +	gcc flex bison libatomic meson ninja-build xdotool \
>>  	'pkgconfig(libdrm)' \
>>  	'pkgconfig(pciaccess)' \
>>  	'pkgconfig(libkmod)' \

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[PATCH i-g-t v3 3/4] i915/gem_create: use atomic_* instead of __sync_*

[Guillaume Tucker]

This fixes builds on some architectures, in particular MIPS which
doesn't have __sync_add_and_fetch_8 and __sync_val_compare_and_swap_8
for 64-bit variable handling.

* replace calls to the older __sync_* functions with the new atomic_*
  standard ones
* use the _Atomic type modifier as required with stdatomic.h functions
* add dependency for gem_create on libatomic

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
---

Notes:
    v2: use atomic_* and only link libatomic with gem_create

 tests/Makefile.am       |  2 +-
 tests/i915/gem_create.c | 16 ++++++++++++----
 tests/meson.build       |  9 ++++++++-
 3 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5a428b8ac213..bbd386c9c2db 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -90,7 +90,7 @@ AM_LDFLAGS = -Wl,--as-needed
 drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_create_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
-gem_create_LDADD = $(LDADD) -lpthread
+gem_create_LDADD = $(LDADD) -lpthread -latomic
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
index 43cbf45f289b..9008cd8a21e3 100644
--- a/tests/i915/gem_create.c
+++ b/tests/i915/gem_create.c
@@ -45,6 +45,7 @@
 #include <sys/time.h>
 #include <getopt.h>
 #include <pthread.h>
+#include <stdatomic.h>
 
 #include <drm.h>
 
@@ -156,7 +157,14 @@ static void invalid_nonaligned_size(int fd)
 	gem_close(fd, create.handle);
 }
 
-static uint64_t get_npages(uint64_t *global, uint64_t npages)
+static uint64_t atomic_compare_swap_u64(_Atomic(uint64_t) *ptr,
+					uint64_t oldval, uint64_t newval)
+{
+	atomic_compare_exchange_strong(ptr, &oldval, newval);
+	return oldval;
+}
+
+static uint64_t get_npages(_Atomic(uint64_t) *global, uint64_t npages)
 {
 	uint64_t try, old, max;
 
@@ -165,13 +173,13 @@ static uint64_t get_npages(uint64_t *global, uint64_t npages)
 		old = max;
 		try = 1 + npages % (max / 2);
 		max -= try;
-	} while ((max = __sync_val_compare_and_swap(global, old, max)) != old);
+	} while ((max = atomic_compare_swap_u64(global, old, max)) != old);
 
 	return try;
 }
 
 struct thread_clear {
-	uint64_t max;
+	_Atomic(uint64_t) max;
 	int timeout;
 	int i915;
 };
@@ -202,7 +210,7 @@ static void *thread_clear(void *data)
 		}
 		gem_close(i915, create.handle);
 
-		__sync_add_and_fetch(&arg->max, npages);
+		atomic_fetch_add(&arg->max, npages);
 	}
 
 	return NULL;
diff --git a/tests/meson.build b/tests/meson.build
index f168fbbae2a8..ffd432d38193 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -110,7 +110,6 @@ i915_progs = [
 	'gem_close_race',
 	'gem_concurrent_blit',
 	'gem_cpu_reloc',
-	'gem_create',
 	'gem_cs_prefetch',
 	'gem_cs_tlb',
 	'gem_ctx_bad_destroy',
@@ -277,6 +276,14 @@ foreach prog : i915_progs
 	test_list += prog
 endforeach
 
+test_executables += executable('gem_create',
+	   join_paths('i915', 'gem_create.c'),
+	   dependencies : test_deps + [ libatomic ],
+	   install_dir : libexecdir,
+	   install_rpath : libexecdir_rpathdir,
+	   install : true)
+test_list += 'gem_create'
+
 test_executables += executable('gem_ctx_sseu',
 	   join_paths('i915', 'gem_ctx_sseu.c'),
 	   dependencies : test_deps + [ lib_igt_perf ],
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[igt-dev] [PATCH i-g-t v3 3/4] i915/gem_create: use atomic_* instead of __sync_*

[Guillaume Tucker]

This fixes builds on some architectures, in particular MIPS which
doesn't have __sync_add_and_fetch_8 and __sync_val_compare_and_swap_8
for 64-bit variable handling.

* replace calls to the older __sync_* functions with the new atomic_*
  standard ones
* use the _Atomic type modifier as required with stdatomic.h functions
* add dependency for gem_create on libatomic

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
---

Notes:
    v2: use atomic_* and only link libatomic with gem_create

 tests/Makefile.am       |  2 +-
 tests/i915/gem_create.c | 16 ++++++++++++----
 tests/meson.build       |  9 ++++++++-
 3 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5a428b8ac213..bbd386c9c2db 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -90,7 +90,7 @@ AM_LDFLAGS = -Wl,--as-needed
 drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_create_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
-gem_create_LDADD = $(LDADD) -lpthread
+gem_create_LDADD = $(LDADD) -lpthread -latomic
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
index 43cbf45f289b..9008cd8a21e3 100644
--- a/tests/i915/gem_create.c
+++ b/tests/i915/gem_create.c
@@ -45,6 +45,7 @@
 #include <sys/time.h>
 #include <getopt.h>
 #include <pthread.h>
+#include <stdatomic.h>
 
 #include <drm.h>
 
@@ -156,7 +157,14 @@ static void invalid_nonaligned_size(int fd)
 	gem_close(fd, create.handle);
 }
 
-static uint64_t get_npages(uint64_t *global, uint64_t npages)
+static uint64_t atomic_compare_swap_u64(_Atomic(uint64_t) *ptr,
+					uint64_t oldval, uint64_t newval)
+{
+	atomic_compare_exchange_strong(ptr, &oldval, newval);
+	return oldval;
+}
+
+static uint64_t get_npages(_Atomic(uint64_t) *global, uint64_t npages)
 {
 	uint64_t try, old, max;
 
@@ -165,13 +173,13 @@ static uint64_t get_npages(uint64_t *global, uint64_t npages)
 		old = max;
 		try = 1 + npages % (max / 2);
 		max -= try;
-	} while ((max = __sync_val_compare_and_swap(global, old, max)) != old);
+	} while ((max = atomic_compare_swap_u64(global, old, max)) != old);
 
 	return try;
 }
 
 struct thread_clear {
-	uint64_t max;
+	_Atomic(uint64_t) max;
 	int timeout;
 	int i915;
 };
@@ -202,7 +210,7 @@ static void *thread_clear(void *data)
 		}
 		gem_close(i915, create.handle);
 
-		__sync_add_and_fetch(&arg->max, npages);
+		atomic_fetch_add(&arg->max, npages);
 	}
 
 	return NULL;
diff --git a/tests/meson.build b/tests/meson.build
index f168fbbae2a8..ffd432d38193 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -110,7 +110,6 @@ i915_progs = [
 	'gem_close_race',
 	'gem_concurrent_blit',
 	'gem_cpu_reloc',
-	'gem_create',
 	'gem_cs_prefetch',
 	'gem_cs_tlb',
 	'gem_ctx_bad_destroy',
@@ -277,6 +276,14 @@ foreach prog : i915_progs
 	test_list += prog
 endforeach
 
+test_executables += executable('gem_create',
+	   join_paths('i915', 'gem_create.c'),
+	   dependencies : test_deps + [ libatomic ],
+	   install_dir : libexecdir,
+	   install_rpath : libexecdir_rpathdir,
+	   install : true)
+test_list += 'gem_create'
+
 test_executables += executable('gem_ctx_sseu',
 	   join_paths('i915', 'gem_ctx_sseu.c'),
 	   dependencies : test_deps + [ lib_igt_perf ],
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[PATCH i-g-t v3 4/4] tests/sw_sync: use atomic_* instead of __sync_*

[Guillaume Tucker]

Replace calls to the older __sync_* functions with the new atomic_*
standard ones to be consistent with other tests and improve
portability across CPU architectures.  Add dependency of sw_sync on
libatomic.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
---

Notes:
    v2: use atomic_* and only link libatomic with sw_sync

 tests/Makefile.am |  1 +
 tests/meson.build |  8 +++++++-
 tests/sw_sync.c   | 12 ++++++------
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index bbd386c9c2db..7d71df8c7a2e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -122,6 +122,7 @@ prime_self_import_LDADD = $(LDADD) -lpthread
 gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_userptr_blits_LDADD = $(LDADD) -lpthread
 perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
+sw_sync_LDADD = $(LDADD) -latomic
 
 kms_flip_LDADD = $(LDADD) -lpthread
 
diff --git a/tests/meson.build b/tests/meson.build
index ffd432d38193..34a74025a537 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -76,7 +76,6 @@ test_progs = [
 	'prime_self_import',
 	'prime_udl',
 	'prime_vgem',
-	'sw_sync',
 	'syncobj_basic',
 	'syncobj_wait',
 	'template',
@@ -329,6 +328,13 @@ executable('testdisplay', ['testdisplay.c', 'testdisplay_hotplug.c'],
 	   install : true)
 test_list += 'testdisplay'
 
+test_executables += executable('sw_sync', 'sw_sync.c',
+	   dependencies : test_deps + [ libatomic ],
+	   install_dir : libexecdir,
+	   install_rpath : libexecdir_rpathdir,
+	   install : true)
+test_list += 'sw_sync'
+
 subdir('amdgpu')
 
 gen_testlist = find_program('generate_testlist.sh')
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 950b8b614759..62d1d17cab45 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -26,6 +26,7 @@
 
 #include <pthread.h>
 #include <semaphore.h>
+#include <stdatomic.h>
 #include <stdint.h>
 #include <sys/socket.h>
 #include <sys/types.h>
@@ -43,7 +44,7 @@ IGT_TEST_DESCRIPTION("Test SW Sync Framework");
 typedef struct {
 	int timeline;
 	uint32_t thread_id;
-	uint32_t *counter;
+	_Atomic(uint32_t) *counter;
 	sem_t *sem;
 } data_t;
 
@@ -489,7 +490,7 @@ static void test_sync_multi_consumer(void)
 	pthread_t thread_arr[MULTI_CONSUMER_THREADS];
 	sem_t sem;
 	int timeline;
-	uint32_t counter = 0;
+	_Atomic(uint32_t) counter = 0;
 	uintptr_t thread_ret = 0;
 	data_t data;
 	int i, ret;
@@ -517,7 +518,7 @@ static void test_sync_multi_consumer(void)
 	{
 		sem_wait(&sem);
 
-		__sync_fetch_and_add(&counter, 1);
+		atomic_fetch_add(&counter, 1);
 		sw_sync_timeline_inc(timeline, 1);
 	}
 
@@ -554,7 +555,7 @@ static void * test_sync_multi_consumer_producer_thread(void *arg)
 		if (sync_fence_wait(fence, 1000) < 0)
 			return (void *) 1;
 
-		if (__sync_fetch_and_add(data->counter, 1) != next_point)
+		if (atomic_fetch_add(data->counter, 1) != next_point)
 			return (void *) 1;
 
 		/* Kick off the next thread. */
@@ -570,7 +571,7 @@ static void test_sync_multi_consumer_producer(void)
 	data_t data_arr[MULTI_CONSUMER_PRODUCER_THREADS];
 	pthread_t thread_arr[MULTI_CONSUMER_PRODUCER_THREADS];
 	int timeline;
-	uint32_t counter = 0;
+	_Atomic(uint32_t) counter = 0;
 	uintptr_t thread_ret = 0;
 	data_t data;
 	int i, ret;
@@ -900,4 +901,3 @@ igt_main
 	igt_subtest("sync_random_merge")
 		test_sync_random_merge();
 }
-
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v3 4/4] tests/sw_sync: use atomic_* instead of __sync_*

[Guillaume Tucker]

Replace calls to the older __sync_* functions with the new atomic_*
standard ones to be consistent with other tests and improve
portability across CPU architectures.  Add dependency of sw_sync on
libatomic.

Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
---

Notes:
    v2: use atomic_* and only link libatomic with sw_sync

 tests/Makefile.am |  1 +
 tests/meson.build |  8 +++++++-
 tests/sw_sync.c   | 12 ++++++------
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index bbd386c9c2db..7d71df8c7a2e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -122,6 +122,7 @@ prime_self_import_LDADD = $(LDADD) -lpthread
 gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_userptr_blits_LDADD = $(LDADD) -lpthread
 perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
+sw_sync_LDADD = $(LDADD) -latomic
 
 kms_flip_LDADD = $(LDADD) -lpthread
 
diff --git a/tests/meson.build b/tests/meson.build
index ffd432d38193..34a74025a537 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -76,7 +76,6 @@ test_progs = [
 	'prime_self_import',
 	'prime_udl',
 	'prime_vgem',
-	'sw_sync',
 	'syncobj_basic',
 	'syncobj_wait',
 	'template',
@@ -329,6 +328,13 @@ executable('testdisplay', ['testdisplay.c', 'testdisplay_hotplug.c'],
 	   install : true)
 test_list += 'testdisplay'
 
+test_executables += executable('sw_sync', 'sw_sync.c',
+	   dependencies : test_deps + [ libatomic ],
+	   install_dir : libexecdir,
+	   install_rpath : libexecdir_rpathdir,
+	   install : true)
+test_list += 'sw_sync'
+
 subdir('amdgpu')
 
 gen_testlist = find_program('generate_testlist.sh')
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 950b8b614759..62d1d17cab45 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -26,6 +26,7 @@
 
 #include <pthread.h>
 #include <semaphore.h>
+#include <stdatomic.h>
 #include <stdint.h>
 #include <sys/socket.h>
 #include <sys/types.h>
@@ -43,7 +44,7 @@ IGT_TEST_DESCRIPTION("Test SW Sync Framework");
 typedef struct {
 	int timeline;
 	uint32_t thread_id;
-	uint32_t *counter;
+	_Atomic(uint32_t) *counter;
 	sem_t *sem;
 } data_t;
 
@@ -489,7 +490,7 @@ static void test_sync_multi_consumer(void)
 	pthread_t thread_arr[MULTI_CONSUMER_THREADS];
 	sem_t sem;
 	int timeline;
-	uint32_t counter = 0;
+	_Atomic(uint32_t) counter = 0;
 	uintptr_t thread_ret = 0;
 	data_t data;
 	int i, ret;
@@ -517,7 +518,7 @@ static void test_sync_multi_consumer(void)
 	{
 		sem_wait(&sem);
 
-		__sync_fetch_and_add(&counter, 1);
+		atomic_fetch_add(&counter, 1);
 		sw_sync_timeline_inc(timeline, 1);
 	}
 
@@ -554,7 +555,7 @@ static void * test_sync_multi_consumer_producer_thread(void *arg)
 		if (sync_fence_wait(fence, 1000) < 0)
 			return (void *) 1;
 
-		if (__sync_fetch_and_add(data->counter, 1) != next_point)
+		if (atomic_fetch_add(data->counter, 1) != next_point)
 			return (void *) 1;
 
 		/* Kick off the next thread. */
@@ -570,7 +571,7 @@ static void test_sync_multi_consumer_producer(void)
 	data_t data_arr[MULTI_CONSUMER_PRODUCER_THREADS];
 	pthread_t thread_arr[MULTI_CONSUMER_PRODUCER_THREADS];
 	int timeline;
-	uint32_t counter = 0;
+	_Atomic(uint32_t) counter = 0;
 	uintptr_t thread_ret = 0;
 	data_t data;
 	int i, ret;
@@ -900,4 +901,3 @@ igt_main
 	igt_subtest("sync_random_merge")
 		test_sync_random_merge();
 }
-
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2)

[Patchwork]

== Series Details ==

Series: Use C11 atomics (rev2)
URL   : https://patchwork.freedesktop.org/series/62048/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6291 -> IGTPW_3170
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_3170 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_3170, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/62048/revisions/2/mbox/

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_3170:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live_gem:
    - fi-cfl-guc:         [PASS][1] -> [DMESG-WARN][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-cfl-guc/igt@i915_selftest@live_gem.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@i915_selftest@live_gem.html

  * igt@runner@aborted:
    - fi-cfl-guc:         NOTRUN -> [FAIL][3]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@runner@aborted.html

  
Known issues
------------

  Here are the changes found in IGTPW_3170 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@core_auth@basic-auth:
    - fi-icl-u3:          [PASS][4] -> [DMESG-WARN][5] ([fdo#107724]) +1 similar issue
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-u3/igt@core_auth@basic-auth.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@core_auth@basic-auth.html

  * igt@gem_exec_suspend@basic-s3:
    - fi-blb-e6850:       [PASS][6] -> [INCOMPLETE][7] ([fdo#107718])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [PASS][8] -> [FAIL][9] ([fdo#109485])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
    - fi-icl-dsi:         [PASS][10] -> [DMESG-WARN][11] ([fdo#106107])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-hsw-peppy:       [PASS][12] -> [DMESG-WARN][13] ([fdo#102614])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html

  
#### Possible fixes ####

  * igt@gem_mmap_gtt@basic-short:
    - fi-icl-u3:          [DMESG-WARN][14] ([fdo#107724]) -> [PASS][15] +2 similar issues
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-u3/igt@gem_mmap_gtt@basic-short.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@gem_mmap_gtt@basic-short.html

  * igt@prime_vgem@basic-wait-default:
    - fi-icl-dsi:         [DMESG-WARN][16] ([fdo#106107]) -> [PASS][17]
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-dsi/igt@prime_vgem@basic-wait-default.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@prime_vgem@basic-wait-default.html

  
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485


Participating hosts (48 -> 36)
------------------------------

  Missing    (12): fi-kbl-soraka fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus fi-cml-u 


Build changes
-------------

  * IGT: IGT_5059 -> IGTPW_3170

  CI_DRM_6291: 30a8dd688b1e9b56df650976b5058da5022dcfb8 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_3170: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
  IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2)

[Ser, Simon]

On Tue, 2019-06-18 at 13:31 +0000, Patchwork wrote:
> == Series Details ==
> 
> Series: Use C11 atomics (rev2)
> URL   : https://patchwork.freedesktop.org/series/62048/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_6291 -> IGTPW_3170
> ====================================================
> 
> Summary
> -------
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with IGTPW_3170 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in IGTPW_3170, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   External URL: https://patchwork.freedesktop.org/api/1.0/series/62048/revisions/2/mbox/
> 
> Possible new issues
> -------------------
> 
>   Here are the unknown changes that may have been introduced in IGTPW_3170:
> 
> ### IGT changes ###
> 
> #### Possible regressions ####
> 
>   * igt@i915_selftest@live_gem:
>     - fi-cfl-guc:         [PASS][1] -> [DMESG-WARN][2]
>    [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-cfl-guc/igt@i915_selftest@live_gem.html
>    [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@i915_selftest@live_gem.html
> 
>   * igt@runner@aborted:
>     - fi-cfl-guc:         NOTRUN -> [FAIL][3]
>    [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@runner@aborted.html

Seems unrelated. Feel free to click the "Test again" button on 
https://patchwork.freedesktop.org/series/62048/

>   
> Known issues
> ------------
> 
>   Here are the changes found in IGTPW_3170 that come from known issues:
> 
> ### IGT changes ###
> 
> #### Issues hit ####
> 
>   * igt@core_auth@basic-auth:
>     - fi-icl-u3:          [PASS][4] -> [DMESG-WARN][5] ([fdo#107724]) +1 similar issue
>    [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-u3/igt@core_auth@basic-auth.html
>    [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@core_auth@basic-auth.html
> 
>   * igt@gem_exec_suspend@basic-s3:
>     - fi-blb-e6850:       [PASS][6] -> [INCOMPLETE][7] ([fdo#107718])
>    [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
>    [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
> 
>   * igt@kms_chamelium@hdmi-hpd-fast:
>     - fi-kbl-7500u:       [PASS][8] -> [FAIL][9] ([fdo#109485])
>    [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
>    [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
> 
>   * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
>     - fi-icl-dsi:         [PASS][10] -> [DMESG-WARN][11] ([fdo#106107])
>    [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
>    [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
> 
>   * igt@kms_frontbuffer_tracking@basic:
>     - fi-hsw-peppy:       [PASS][12] -> [DMESG-WARN][13] ([fdo#102614])
>    [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
>    [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
> 
>   
> #### Possible fixes ####
> 
>   * igt@gem_mmap_gtt@basic-short:
>     - fi-icl-u3:          [DMESG-WARN][14] ([fdo#107724]) -> [PASS][15] +2 similar issues
>    [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-u3/igt@gem_mmap_gtt@basic-short.html
>    [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@gem_mmap_gtt@basic-short.html
> 
>   * igt@prime_vgem@basic-wait-default:
>     - fi-icl-dsi:         [DMESG-WARN][16] ([fdo#106107]) -> [PASS][17]
>    [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-dsi/igt@prime_vgem@basic-wait-default.html
>    [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@prime_vgem@basic-wait-default.html
> 
>   
>   [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
>   [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
>   [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
>   [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
>   [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
> 
> 
> Participating hosts (48 -> 36)
> ------------------------------
> 
>   Missing    (12): fi-kbl-soraka fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus fi-cml-u 
> 
> 
> Build changes
> -------------
> 
>   * IGT: IGT_5059 -> IGTPW_3170
> 
>   CI_DRM_6291: 30a8dd688b1e9b56df650976b5058da5022dcfb8 @ git://anongit.freedesktop.org/gfx-ci/linux
>   IGTPW_3170: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
>   IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2)

[Saarinen, Jani]

HI, 

> -----Original Message-----
> From: igt-dev [mailto:igt-dev-bounces@lists.freedesktop.org] On Behalf Of Ser,
> Simon
> Sent: keskiviikko 19. kesäkuuta 2019 9.52
> To: guillaume.tucker@collabora.com; igt-dev@lists.freedesktop.org
> Subject: Re: [igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2)
> 
> On Tue, 2019-06-18 at 13:31 +0000, Patchwork wrote:
> > == Series Details ==
> >
> > Series: Use C11 atomics (rev2)
> > URL   : https://patchwork.freedesktop.org/series/62048/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_6291 -> IGTPW_3170
> > ====================================================
> >
> > Summary
> > -------
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with IGTPW_3170 absolutely need to be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in IGTPW_3170, please notify your bug team to allow them
> >   to document this new failure mode, which will reduce false positives in CI.
> >
> >   External URL:
> > https://patchwork.freedesktop.org/api/1.0/series/62048/revisions/2/mbo
> > x/
> >
> > Possible new issues
> > -------------------
> >
> >   Here are the unknown changes that may have been introduced in
> IGTPW_3170:
> >
> > ### IGT changes ###
> >
> > #### Possible regressions ####
> >
> >   * igt@i915_selftest@live_gem:
> >     - fi-cfl-guc:         [PASS][1] -> [DMESG-WARN][2]
> >    [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-cfl-
> guc/igt@i915_selftest@live_gem.html
> >    [2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@i91
> > 5_selftest@live_gem.html
> >
> >   * igt@runner@aborted:
> >     - fi-cfl-guc:         NOTRUN -> [FAIL][3]
> >    [3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@run
> > ner@aborted.html
> 
> Seems unrelated. Feel free to click the "Test again" button on
> https://patchwork.freedesktop.org/series/62048/
Martin, is this ok or just re-report? 
> 
> >
> > Known issues
> > ------------
> >
> >   Here are the changes found in IGTPW_3170 that come from known issues:
> >
> > ### IGT changes ###
> >
> > #### Issues hit ####
> >
> >   * igt@core_auth@basic-auth:
> >     - fi-icl-u3:          [PASS][4] -> [DMESG-WARN][5] ([fdo#107724]) +1 similar issue
> >    [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
> u3/igt@core_auth@basic-auth.html
> >    [5]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@core
> > _auth@basic-auth.html
> >
> >   * igt@gem_exec_suspend@basic-s3:
> >     - fi-blb-e6850:       [PASS][6] -> [INCOMPLETE][7] ([fdo#107718])
> >    [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-blb-
> e6850/igt@gem_exec_suspend@basic-s3.html
> >    [7]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-blb-e6850/igt@g
> > em_exec_suspend@basic-s3.html
> >
> >   * igt@kms_chamelium@hdmi-hpd-fast:
> >     - fi-kbl-7500u:       [PASS][8] -> [FAIL][9] ([fdo#109485])
> >    [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-kbl-
> 7500u/igt@kms_chamelium@hdmi-hpd-fast.html
> >    [9]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-kbl-7500u/igt@k
> > ms_chamelium@hdmi-hpd-fast.html
> >
> >   * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
> >     - fi-icl-dsi:         [PASS][10] -> [DMESG-WARN][11] ([fdo#106107])
> >    [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
> dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
> >    [11]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@kms
> > _cursor_legacy@basic-flip-after-cursor-varying-size.html
> >
> >   * igt@kms_frontbuffer_tracking@basic:
> >     - fi-hsw-peppy:       [PASS][12] -> [DMESG-WARN][13] ([fdo#102614])
> >    [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-hsw-
> peppy/igt@kms_frontbuffer_tracking@basic.html
> >    [13]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-hsw-peppy/igt@k
> > ms_frontbuffer_tracking@basic.html
> >
> >
> > #### Possible fixes ####
> >
> >   * igt@gem_mmap_gtt@basic-short:
> >     - fi-icl-u3:          [DMESG-WARN][14] ([fdo#107724]) -> [PASS][15] +2 similar
> issues
> >    [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
> u3/igt@gem_mmap_gtt@basic-short.html
> >    [15]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@gem_
> > mmap_gtt@basic-short.html
> >
> >   * igt@prime_vgem@basic-wait-default:
> >     - fi-icl-dsi:         [DMESG-WARN][16] ([fdo#106107]) -> [PASS][17]
> >    [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
> dsi/igt@prime_vgem@basic-wait-default.html
> >    [17]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@pri
> > me_vgem@basic-wait-default.html
> >
> >
> >   [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
> >   [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
> >   [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
> >   [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
> >   [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
> >
> >
> > Participating hosts (48 -> 36)
> > ------------------------------
> >
> >   Missing    (12): fi-kbl-soraka fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
> fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus fi-cml-u
> >
> >
> > Build changes
> > -------------
> >
> >   * IGT: IGT_5059 -> IGTPW_3170
> >
> >   CI_DRM_6291: 30a8dd688b1e9b56df650976b5058da5022dcfb8 @
> git://anongit.freedesktop.org/gfx-ci/linux
> >   IGTPW_3170: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
> >   IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @
> > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> >
> > == Logs ==
> >
> > For more details see:
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
> > _______________________________________________
> > igt-dev mailing list
> > igt-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> _______________________________________________
> igt-dev mailing list
> igt-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2)

[Peres, Martin]

On 19/06/2019 10:02, Saarinen, Jani wrote:
> HI, 
> 
>> -----Original Message-----
>> From: igt-dev [mailto:igt-dev-bounces@lists.freedesktop.org] On Behalf Of Ser,
>> Simon
>> Sent: keskiviikko 19. kesäkuuta 2019 9.52
>> To: guillaume.tucker@collabora.com; igt-dev@lists.freedesktop.org
>> Subject: Re: [igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2)
>>
>> On Tue, 2019-06-18 at 13:31 +0000, Patchwork wrote:
>>> == Series Details ==
>>>
>>> Series: Use C11 atomics (rev2)
>>> URL   : https://patchwork.freedesktop.org/series/62048/
>>> State : failure
>>>
>>> == Summary ==
>>>
>>> CI Bug Log - changes from CI_DRM_6291 -> IGTPW_3170
>>> ====================================================
>>>
>>> Summary
>>> -------
>>>
>>>   **FAILURE**
>>>
>>>   Serious unknown changes coming with IGTPW_3170 absolutely need to be
>>>   verified manually.
>>>
>>>   If you think the reported changes have nothing to do with the changes
>>>   introduced in IGTPW_3170, please notify your bug team to allow them
>>>   to document this new failure mode, which will reduce false positives in CI.
>>>
>>>   External URL:
>>> https://patchwork.freedesktop.org/api/1.0/series/62048/revisions/2/mbo
>>> x/
>>>
>>> Possible new issues
>>> -------------------
>>>
>>>   Here are the unknown changes that may have been introduced in
>> IGTPW_3170:
>>>
>>> ### IGT changes ###
>>>
>>> #### Possible regressions ####
>>>
>>>   * igt@i915_selftest@live_gem:
>>>     - fi-cfl-guc:         [PASS][1] -> [DMESG-WARN][2]
>>>    [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-cfl-
>> guc/igt@i915_selftest@live_gem.html
>>>    [2]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@i91
>>> 5_selftest@live_gem.html
>>>
>>>   * igt@runner@aborted:
>>>     - fi-cfl-guc:         NOTRUN -> [FAIL][3]
>>>    [3]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@run
>>> ner@aborted.html
>>
>> Seems unrelated. Feel free to click the "Test again" button on
>> https://patchwork.freedesktop.org/series/62048/
> Martin, is this ok or just re-report? 

Simon, re-runs take machine time and we are in bad need of it... So it
is just best for me to file the bug then re-report the run to unblock
the testing of shards.

Anyway, this was a known issue, but hitting in an unknown place:
https://bugs.freedesktop.org/show_bug.cgi?id=110943

As for you Guillaume, I guess this false positive could not have
happened to anyone better! This is good for you to experience our CI as
a user :) Please send all the feedback you have!

Martin

>>
>>>
>>> Known issues
>>> ------------
>>>
>>>   Here are the changes found in IGTPW_3170 that come from known issues:
>>>
>>> ### IGT changes ###
>>>
>>> #### Issues hit ####
>>>
>>>   * igt@core_auth@basic-auth:
>>>     - fi-icl-u3:          [PASS][4] -> [DMESG-WARN][5] ([fdo#107724]) +1 similar issue
>>>    [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
>> u3/igt@core_auth@basic-auth.html
>>>    [5]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@core
>>> _auth@basic-auth.html
>>>
>>>   * igt@gem_exec_suspend@basic-s3:
>>>     - fi-blb-e6850:       [PASS][6] -> [INCOMPLETE][7] ([fdo#107718])
>>>    [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-blb-
>> e6850/igt@gem_exec_suspend@basic-s3.html
>>>    [7]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-blb-e6850/igt@g
>>> em_exec_suspend@basic-s3.html
>>>
>>>   * igt@kms_chamelium@hdmi-hpd-fast:
>>>     - fi-kbl-7500u:       [PASS][8] -> [FAIL][9] ([fdo#109485])
>>>    [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-kbl-
>> 7500u/igt@kms_chamelium@hdmi-hpd-fast.html
>>>    [9]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-kbl-7500u/igt@k
>>> ms_chamelium@hdmi-hpd-fast.html
>>>
>>>   * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
>>>     - fi-icl-dsi:         [PASS][10] -> [DMESG-WARN][11] ([fdo#106107])
>>>    [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
>> dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
>>>    [11]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@kms
>>> _cursor_legacy@basic-flip-after-cursor-varying-size.html
>>>
>>>   * igt@kms_frontbuffer_tracking@basic:
>>>     - fi-hsw-peppy:       [PASS][12] -> [DMESG-WARN][13] ([fdo#102614])
>>>    [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-hsw-
>> peppy/igt@kms_frontbuffer_tracking@basic.html
>>>    [13]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-hsw-peppy/igt@k
>>> ms_frontbuffer_tracking@basic.html
>>>
>>>
>>> #### Possible fixes ####
>>>
>>>   * igt@gem_mmap_gtt@basic-short:
>>>     - fi-icl-u3:          [DMESG-WARN][14] ([fdo#107724]) -> [PASS][15] +2 similar
>> issues
>>>    [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
>> u3/igt@gem_mmap_gtt@basic-short.html
>>>    [15]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@gem_
>>> mmap_gtt@basic-short.html
>>>
>>>   * igt@prime_vgem@basic-wait-default:
>>>     - fi-icl-dsi:         [DMESG-WARN][16] ([fdo#106107]) -> [PASS][17]
>>>    [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
>> dsi/igt@prime_vgem@basic-wait-default.html
>>>    [17]:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@pri
>>> me_vgem@basic-wait-default.html
>>>
>>>
>>>   [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
>>>   [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
>>>   [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
>>>   [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
>>>   [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
>>>
>>>
>>> Participating hosts (48 -> 36)
>>> ------------------------------
>>>
>>>   Missing    (12): fi-kbl-soraka fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
>> fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus fi-cml-u
>>>
>>>
>>> Build changes
>>> -------------
>>>
>>>   * IGT: IGT_5059 -> IGTPW_3170
>>>
>>>   CI_DRM_6291: 30a8dd688b1e9b56df650976b5058da5022dcfb8 @
>> git://anongit.freedesktop.org/gfx-ci/linux
>>>   IGTPW_3170: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
>>>   IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @
>>> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>>>
>>> == Logs ==
>>>
>>> For more details see:
>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
>>> _______________________________________________
>>> igt-dev mailing list
>>> igt-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>> _______________________________________________
>> igt-dev mailing list
>> igt-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2)

[Guillaume Tucker]

On 19/06/2019 08:32, Peres, Martin wrote:
> On 19/06/2019 10:02, Saarinen, Jani wrote:
>> HI, 
>>
>>> -----Original Message-----
>>> From: igt-dev [mailto:igt-dev-bounces@lists.freedesktop.org] On Behalf Of Ser,
>>> Simon
>>> Sent: keskiviikko 19. kesäkuuta 2019 9.52
>>> To: guillaume.tucker@collabora.com; igt-dev@lists.freedesktop.org
>>> Subject: Re: [igt-dev] ✗ Fi.CI.BAT: failure for Use C11 atomics (rev2)
>>>
>>> On Tue, 2019-06-18 at 13:31 +0000, Patchwork wrote:
>>>> == Series Details ==
>>>>
>>>> Series: Use C11 atomics (rev2)
>>>> URL   : https://patchwork.freedesktop.org/series/62048/
>>>> State : failure
>>>>
>>>> == Summary ==
>>>>
>>>> CI Bug Log - changes from CI_DRM_6291 -> IGTPW_3170
>>>> ====================================================
>>>>
>>>> Summary
>>>> -------
>>>>
>>>>   **FAILURE**
>>>>
>>>>   Serious unknown changes coming with IGTPW_3170 absolutely need to be
>>>>   verified manually.
>>>>
>>>>   If you think the reported changes have nothing to do with the changes
>>>>   introduced in IGTPW_3170, please notify your bug team to allow them
>>>>   to document this new failure mode, which will reduce false positives in CI.
>>>>
>>>>   External URL:
>>>> https://patchwork.freedesktop.org/api/1.0/series/62048/revisions/2/mbo
>>>> x/
>>>>
>>>> Possible new issues
>>>> -------------------
>>>>
>>>>   Here are the unknown changes that may have been introduced in
>>> IGTPW_3170:
>>>>
>>>> ### IGT changes ###
>>>>
>>>> #### Possible regressions ####
>>>>
>>>>   * igt@i915_selftest@live_gem:
>>>>     - fi-cfl-guc:         [PASS][1] -> [DMESG-WARN][2]
>>>>    [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-cfl-
>>> guc/igt@i915_selftest@live_gem.html
>>>>    [2]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@i91
>>>> 5_selftest@live_gem.html
>>>>
>>>>   * igt@runner@aborted:
>>>>     - fi-cfl-guc:         NOTRUN -> [FAIL][3]
>>>>    [3]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-cfl-guc/igt@run
>>>> ner@aborted.html
>>>
>>> Seems unrelated. Feel free to click the "Test again" button on
>>> https://patchwork.freedesktop.org/series/62048/
>> Martin, is this ok or just re-report? 
> 
> Simon, re-runs take machine time and we are in bad need of it... So it
> is just best for me to file the bug then re-report the run to unblock
> the testing of shards.

I'm afraid I might have already started a re-run, feel free to
cancel that if need be.

> Anyway, this was a known issue, but hitting in an unknown place:
> https://bugs.freedesktop.org/show_bug.cgi?id=110943
> 
> As for you Guillaume, I guess this false positive could not have
> happened to anyone better! This is good for you to experience our CI as
> a user :) Please send all the feedback you have!

Absolutely!  I'll get back to you when I'm done with this.

Thanks,
Guillaume

>>>> Known issues
>>>> ------------
>>>>
>>>>   Here are the changes found in IGTPW_3170 that come from known issues:
>>>>
>>>> ### IGT changes ###
>>>>
>>>> #### Issues hit ####
>>>>
>>>>   * igt@core_auth@basic-auth:
>>>>     - fi-icl-u3:          [PASS][4] -> [DMESG-WARN][5] ([fdo#107724]) +1 similar issue
>>>>    [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
>>> u3/igt@core_auth@basic-auth.html
>>>>    [5]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@core
>>>> _auth@basic-auth.html
>>>>
>>>>   * igt@gem_exec_suspend@basic-s3:
>>>>     - fi-blb-e6850:       [PASS][6] -> [INCOMPLETE][7] ([fdo#107718])
>>>>    [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-blb-
>>> e6850/igt@gem_exec_suspend@basic-s3.html
>>>>    [7]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-blb-e6850/igt@g
>>>> em_exec_suspend@basic-s3.html
>>>>
>>>>   * igt@kms_chamelium@hdmi-hpd-fast:
>>>>     - fi-kbl-7500u:       [PASS][8] -> [FAIL][9] ([fdo#109485])
>>>>    [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-kbl-
>>> 7500u/igt@kms_chamelium@hdmi-hpd-fast.html
>>>>    [9]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-kbl-7500u/igt@k
>>>> ms_chamelium@hdmi-hpd-fast.html
>>>>
>>>>   * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
>>>>     - fi-icl-dsi:         [PASS][10] -> [DMESG-WARN][11] ([fdo#106107])
>>>>    [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
>>> dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size.html
>>>>    [11]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@kms
>>>> _cursor_legacy@basic-flip-after-cursor-varying-size.html
>>>>
>>>>   * igt@kms_frontbuffer_tracking@basic:
>>>>     - fi-hsw-peppy:       [PASS][12] -> [DMESG-WARN][13] ([fdo#102614])
>>>>    [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-hsw-
>>> peppy/igt@kms_frontbuffer_tracking@basic.html
>>>>    [13]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-hsw-peppy/igt@k
>>>> ms_frontbuffer_tracking@basic.html
>>>>
>>>>
>>>> #### Possible fixes ####
>>>>
>>>>   * igt@gem_mmap_gtt@basic-short:
>>>>     - fi-icl-u3:          [DMESG-WARN][14] ([fdo#107724]) -> [PASS][15] +2 similar
>>> issues
>>>>    [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
>>> u3/igt@gem_mmap_gtt@basic-short.html
>>>>    [15]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-u3/igt@gem_
>>>> mmap_gtt@basic-short.html
>>>>
>>>>   * igt@prime_vgem@basic-wait-default:
>>>>     - fi-icl-dsi:         [DMESG-WARN][16] ([fdo#106107]) -> [PASS][17]
>>>>    [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-
>>> dsi/igt@prime_vgem@basic-wait-default.html
>>>>    [17]:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/fi-icl-dsi/igt@pri
>>>> me_vgem@basic-wait-default.html
>>>>
>>>>
>>>>   [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
>>>>   [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
>>>>   [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
>>>>   [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
>>>>   [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
>>>>
>>>>
>>>> Participating hosts (48 -> 36)
>>>> ------------------------------
>>>>
>>>>   Missing    (12): fi-kbl-soraka fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
>>> fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus fi-cml-u
>>>>
>>>>
>>>> Build changes
>>>> -------------
>>>>
>>>>   * IGT: IGT_5059 -> IGTPW_3170
>>>>
>>>>   CI_DRM_6291: 30a8dd688b1e9b56df650976b5058da5022dcfb8 @
>>> git://anongit.freedesktop.org/gfx-ci/linux
>>>>   IGTPW_3170: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
>>>>   IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @
>>>> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>>>>
>>>> == Logs ==
>>>>
>>>> For more details see:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3170/
>>>> _______________________________________________
>>>> igt-dev mailing list
>>>> igt-dev@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>> _______________________________________________
>>> igt-dev mailing list
>>> igt-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>
> 

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for Use C11 atomics (rev3)

[Patchwork]

== Series Details ==

Series: Use C11 atomics (rev3)
URL   : https://patchwork.freedesktop.org/series/62048/
State : success

== Summary ==

CI Bug Log - changes from IGT_5060 -> IGTPW_3175
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/62048/revisions/3/mbox/

Known issues
------------

  Here are the changes found in IGTPW_3175 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_mmap_gtt@basic-small-bo:
    - fi-icl-u3:          [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-icl-u3/igt@gem_mmap_gtt@basic-small-bo.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-icl-u3/igt@gem_mmap_gtt@basic-small-bo.html

  * igt@gem_mmap_gtt@basic-small-copy:
    - fi-icl-dsi:         [PASS][3] -> [INCOMPLETE][4] ([fdo#107713])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-icl-dsi/igt@gem_mmap_gtt@basic-small-copy.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-icl-dsi/igt@gem_mmap_gtt@basic-small-copy.html

  * igt@i915_selftest@live_contexts:
    - fi-bdw-gvtdvm:      [PASS][5] -> [DMESG-FAIL][6] ([fdo#110235])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html

  
#### Possible fixes ####

  * igt@gem_ctx_switch@basic-default:
    - fi-icl-guc:         [INCOMPLETE][7] ([fdo#107713] / [fdo#108569]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-icl-guc/igt@gem_ctx_switch@basic-default.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-icl-guc/igt@gem_ctx_switch@basic-default.html

  * igt@gem_exec_suspend@basic-s3:
    - fi-blb-e6850:       [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html

  * igt@i915_selftest@live_contexts:
    - fi-skl-gvtdvm:      [DMESG-FAIL][11] ([fdo#110235]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-skl-6700k2:      [INCOMPLETE][13] ([fdo#104108]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-skl-6700k2/igt@kms_chamelium@common-hpd-after-suspend.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-skl-6700k2/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-icl-u3:          [FAIL][15] ([fdo#103167]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-icl-u3/igt@kms_frontbuffer_tracking@basic.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-icl-u3/igt@kms_frontbuffer_tracking@basic.html
    - fi-hsw-peppy:       [DMESG-WARN][17] ([fdo#102614]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html

  
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235


Participating hosts (43 -> 44)
------------------------------

  Additional (9): fi-cml-u2 fi-bxt-dsi fi-byt-j1900 fi-skl-guc fi-kbl-guc fi-whl-u fi-kbl-x1275 fi-skl-iommu fi-cml-u 
  Missing    (8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * IGT: IGT_5060 -> IGTPW_3175

  CI_DRM_6300: a0694108fecf62a79e0be32e578f25fdcbf466e4 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_3175: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/
  IGT_5060: c6a0e43633a399899278353e452a52bb41ac96e1 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.IGT: success for Use C11 atomics (rev3)

[Patchwork]

== Series Details ==

Series: Use C11 atomics (rev3)
URL   : https://patchwork.freedesktop.org/series/62048/
State : success

== Summary ==

CI Bug Log - changes from IGT_5060_full -> IGTPW_3175_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/62048/revisions/3/mbox/

Known issues
------------

  Here are the changes found in IGTPW_3175_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
    - shard-snb:          [PASS][1] -> [DMESG-WARN][2] ([fdo#110789] / [fdo#110913 ]) +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-snb4/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-snb7/igt@gem_persistent_relocs@forked-interruptible-thrashing.html

  * igt@gem_persistent_relocs@forked-thrashing:
    - shard-apl:          [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +2 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-apl2/igt@gem_persistent_relocs@forked-thrashing.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-apl7/igt@gem_persistent_relocs@forked-thrashing.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
    - shard-snb:          [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-snb2/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-snb1/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
    - shard-kbl:          [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +2 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-kbl7/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-kbl3/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html

  * igt@gem_workarounds@suspend-resume-fd:
    - shard-apl:          [PASS][9] -> [DMESG-WARN][10] ([fdo#108566])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-apl8/igt@gem_workarounds@suspend-resume-fd.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-apl4/igt@gem_workarounds@suspend-resume-fd.html

  * igt@i915_suspend@debugfs-reader:
    - shard-kbl:          [PASS][11] -> [INCOMPLETE][12] ([fdo#103665])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-kbl1/igt@i915_suspend@debugfs-reader.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-kbl2/igt@i915_suspend@debugfs-reader.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x21-sliding:
    - shard-apl:          [PASS][13] -> [FAIL][14] ([fdo#103232])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-apl8/igt@kms_cursor_crc@pipe-a-cursor-64x21-sliding.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-apl5/igt@kms_cursor_crc@pipe-a-cursor-64x21-sliding.html
    - shard-kbl:          [PASS][15] -> [FAIL][16] ([fdo#103232])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-64x21-sliding.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-64x21-sliding.html

  * igt@kms_cursor_legacy@cursorb-vs-flipb-atomic:
    - shard-hsw:          [PASS][17] -> [SKIP][18] ([fdo#109271]) +18 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-hsw6/igt@kms_cursor_legacy@cursorb-vs-flipb-atomic.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-hsw1/igt@kms_cursor_legacy@cursorb-vs-flipb-atomic.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
    - shard-iclb:         [PASS][19] -> [INCOMPLETE][20] ([fdo#107713])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
    - shard-iclb:         [PASS][21] -> [FAIL][22] ([fdo#103167]) +3 similar issues
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-iclb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc:
    - shard-iclb:         [PASS][23] -> [INCOMPLETE][24] ([fdo#106978] / [fdo#107713])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-iclb1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-iclb1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [PASS][25] -> [SKIP][26] ([fdo#109441]) +1 similar issue
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-iclb5/igt@kms_psr@psr2_cursor_render.html

  * igt@kms_vblank@pipe-c-ts-continuation-modeset-hang:
    - shard-glk:          [PASS][27] -> [INCOMPLETE][28] ([fdo#103359] / [k.org#198133])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-glk4/igt@kms_vblank@pipe-c-ts-continuation-modeset-hang.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-glk8/igt@kms_vblank@pipe-c-ts-continuation-modeset-hang.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@bcs0-s3:
    - shard-apl:          [DMESG-WARN][29] ([fdo#108566]) -> [PASS][30] +2 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-apl4/igt@gem_ctx_isolation@bcs0-s3.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-apl3/igt@gem_ctx_isolation@bcs0-s3.html

  * igt@gem_eio@in-flight-contexts-1us:
    - shard-kbl:          [DMESG-WARN][31] ([fdo#110913 ]) -> [PASS][32] +2 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-kbl2/igt@gem_eio@in-flight-contexts-1us.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-kbl7/igt@gem_eio@in-flight-contexts-1us.html

  * igt@gem_eio@in-flight-suspend:
    - shard-kbl:          [FAIL][33] ([fdo#110667]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-kbl2/igt@gem_eio@in-flight-suspend.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-kbl4/igt@gem_eio@in-flight-suspend.html

  * igt@gem_persistent_relocs@forked-thrashing:
    - shard-snb:          [DMESG-WARN][35] ([fdo#110789] / [fdo#110913 ]) -> [PASS][36] +1 similar issue
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-snb2/igt@gem_persistent_relocs@forked-thrashing.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-snb5/igt@gem_persistent_relocs@forked-thrashing.html

  * igt@gem_tiled_swapping@non-threaded:
    - shard-hsw:          [FAIL][37] ([fdo#108686]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-hsw2/igt@gem_tiled_swapping@non-threaded.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-hsw2/igt@gem_tiled_swapping@non-threaded.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy:
    - shard-snb:          [DMESG-WARN][39] ([fdo#110913 ]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-snb7/igt@gem_userptr_blits@map-fixed-invalidate-busy.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-snb7/igt@gem_userptr_blits@map-fixed-invalidate-busy.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
    - shard-apl:          [DMESG-WARN][41] ([fdo#110913 ]) -> [PASS][42] +4 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-apl8/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-apl3/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html

  * igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset:
    - shard-hsw:          [SKIP][43] ([fdo#109271]) -> [PASS][44] +24 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-hsw1/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-hsw4/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
    - shard-iclb:         [FAIL][45] ([fdo#103167]) -> [PASS][46] +5 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-wc:
    - shard-glk:          [FAIL][47] ([fdo#103167]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-glk2/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-wc.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-glk1/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-wc.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [FAIL][49] ([fdo#103166]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-iclb8/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-iclb2/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_sprite_render:
    - shard-iclb:         [SKIP][51] ([fdo#109441]) -> [PASS][52] +2 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-iclb8/igt@kms_psr@psr2_sprite_render.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-iclb2/igt@kms_psr@psr2_sprite_render.html

  * igt@kms_setmode@basic:
    - shard-apl:          [FAIL][53] ([fdo#99912]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-apl3/igt@kms_setmode@basic.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-apl1/igt@kms_setmode@basic.html
    - shard-hsw:          [FAIL][55] ([fdo#99912]) -> [PASS][56]
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-hsw8/igt@kms_setmode@basic.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-hsw5/igt@kms_setmode@basic.html

  * igt@kms_universal_plane@universal-plane-pipe-b-functional:
    - shard-apl:          [FAIL][57] ([fdo#110037]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-apl2/igt@kms_universal_plane@universal-plane-pipe-b-functional.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-apl6/igt@kms_universal_plane@universal-plane-pipe-b-functional.html
    - shard-kbl:          [FAIL][59] ([fdo#110037]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5060/shard-kbl6/igt@kms_universal_plane@universal-plane-pipe-b-functional.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/shard-kbl7/igt@kms_universal_plane@universal-plane-pipe-b-functional.html

  
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
  [fdo#106978]: https://bugs.freedesktop.org/show_bug.cgi?id=106978
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110037]: https://bugs.freedesktop.org/show_bug.cgi?id=110037
  [fdo#110667]: https://bugs.freedesktop.org/show_bug.cgi?id=110667
  [fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
  [fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913 
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (7 -> 6)
------------------------------

  Missing    (1): shard-skl 


Build changes
-------------

  * IGT: IGT_5060 -> IGTPW_3175

  CI_DRM_6300: a0694108fecf62a79e0be32e578f25fdcbf466e4 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_3175: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/
  IGT_5060: c6a0e43633a399899278353e452a52bb41ac96e1 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3175/
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev