protonscr

Streaming gets us really messed up colors

steamclosed NVIDIA drivers3rd party gameStreaming
ValveSoftware/steam-for-linux#5947 · opened 2018-12-09 by grepwood · updated 2021-06-11 · 6 comments · github
Ggrepwood 2018-12-09 github

Your system information

  • Steam client version (build number or date): Nov 26 2018 at
  • Distribution (e.g. Ubuntu): Ubuntu 18.04 LTS
  • Opted into Steam client beta?: No
  • Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

I have a virtual machine with Ubuntu 18.04 LTS for amd64 with a dedicated GeForce 710GT, running the binary nVidia driver, that runs Civilization 5 on Steam. My hypervisor is Gentoo Linux, which can't unfortunately run this game due to bugs. After launching the game, I try to stream it from my hypervisor, but I get really messy colors.

For the record, I have used the suggestion from #5434, but to no avail.

Steps for reproducing this issue:

  1. Set up a VM with PCI passthrough and install Ubuntu 18.04 LTS for amd64 on it, including proprietary nVidia drivers, Steam and Civilization 5.
  2. Use x11vnc to take over the X screen and launch the game. Then exit the VNC session.
  3. From your hypervisor, stream Civilization 5 from the VM. You should experience this:
    obraz
Kkisak-valve maintainer 2018-12-09 github

Hello @grepwood, as a side note, https://bugs.gentoo.org/616402#c15 may interest you.

Is there a second video card involved in the setup? What is the hypervisor using to render to the display?

Ggrepwood 2018-12-09 github

Thank you @kisak-valve, I'll give this a shot. Meanwhile, I've also tested this with stock nouveau from Ubuntu 18.04 LTS. The free drivers also exhibit this strange behavior.

Ggrepwood 2018-12-10 github

I followed the advice in https://bugs.gentoo.org/616402#c15 and I'm running into the same problems as https://bugs.gentoo.org/616402#c17.
I have gone a step ahead and altered the CFLAGS for these packages. They were:
CFLAGS="-O2 -pipe -ggdb -march=znver1"
And now they are
CFLAGS="-O1 -pipe -ggdb -mstackrealign -march=486"
This will not work for these packages, as setting -march=486 for amd64 code will trigger the compiler to not compile as 486 doesn't support any amd64-specific machine code. So, to work around this, I have gone with
CFLAGS="-O1 -pipe -ggdb -mstackrealign -mno-sse2"
This will still prevent sys-libs/glibc from being built:

x86_64-pc-linux-gnu-gcc -m64 -pipe -ggdb -mno-sse2 -O2 -fno-strict-aliasing -Wl,-O1 -Wl,--as-needed ../sysdeps/ieee754/dbl-64/e_gamma_r.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall -Wundef -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -frounding-math -fstack-protector-all -ggdb -mno-sse2 -pipe -Wstrict-prototypes -Wold-style-definition         -U_FORTIFY_SOURCE  -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -I../include -I/var/tmp/portage/sys-libs/glibc-2.27-r6/work/build-amd64-x86_64-pc-linux-gnu-nptl/math  -I/var/tmp/portage/sys-libs/glibc-2.27-r6/work/build-amd64-x86_64-pc-linux-gnu-nptl  -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86  -I../sysdeps/ieee754/float128  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/include-fixed -isystem /usr/include  -D_LIBC_REENTRANT -include /var/tmp/portage/sys-libs/glibc-2.27-r6/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc-modules.h -DMODULE_NAME=libm -include ../include/libc-symbols.h  -DPIC     -DTOP_NAMESPACE=glibc -I../soft-fp -o /var/tmp/portage/sys-libs/glibc-2.27-r6/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/e_gamma_r.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.27-r6/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/e_gamma_r.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.27-r6/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/e_gamma_r.o
In file included from ../sysdeps/x86_64/fpu/math_private.h:49,
                 from ../sysdeps/ieee754/dbl-64/e_remainder.c:37:
../sysdeps/ieee754/dbl-64/e_remainder.c: In function ‘__ieee754_remainder’:
../sysdeps/generic/math_private.h:617:10: error: cleanup argument not a function
   struct rm_ctx ctx __attribute__((cleanup (CLEANUPFUNC ## _ctx))); \
          ^~~~~~
../sysdeps/generic/math_private.h:639:3: note: in expansion of macro ‘SET_RESTORE_ROUND_GENERIC’
   SET_RESTORE_ROUND_GENERIC (RM, libc_feholdsetround_noex, \
   ^~~~~~~~~~~~~~~~~~~~~~~~~
../sysdeps/ieee754/dbl-64/e_remainder.c:57:7: note: in expansion of macro ‘SET_RESTORE_ROUND_NOEX’
       SET_RESTORE_ROUND_NOEX (FE_TONEAREST);
       ^~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.27-r6/work/build-amd64-x86_64-pc-linux-gnu-nptl/sysd-rules:859: /var/tmp/portage/sys-libs/glibc-2.27-r6/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/e_remainder.o] Error 1

Goodness, what a mess. I think I'll need to research how RedHat and Ubuntu make their GNU libc to rectify this sideshow for good.

Kkisak-valve maintainer 2021-05-07 github

Hello @grepwood, are you still experiencing this issue on an up to date system?

Ggrepwood 2021-05-10 github

@kisak-valve I have not been able to even start Civ5 and CivBE since then, courtesy of https://bugs.gentoo.org/616402 and Aspyr defending their idleness tooth and nail.

Kkisak-valve maintainer 2021-06-11 github

Thanks for the feedback @grepwood, I'm going to close this issue for now because there isn't a good way to reproduce the issue, but if you get the testing blocker worked out in the future, let me know and I can re-open the issue.

Nothing extracted yet.