Linux Graphics Stack

Seagull So one thing I'm interested to know next is if your good and bad streams can be captured losslessly with those dithering effects still present? I guess this is exactly what @JTL is working on right now. A quick google and some are mentioning using NDI on OBS? I don't know what either of those terms are but it's probably a big thing in the streaming community.

The fact that one stream is good and one bad is promising though. If clips demonstrating a good and bad setup can be saved into some form of video format that retain the dithering etc this is hard evidence that can help us for future purchases and also to harass Nvidia with .

I suspect it's some sort of PCoIP being used. Just like my Shadow PC. Some blurb I found online below.

"PC-over-IP (PCoIP) technology delivers a secure, high-definition and highly responsive computing experience. It uses advanced display compression to provide end users with on-premises or cloud-based virtual machines as a convenient alternative to local computers. This virtual workspace architecture compresses, encrypts and transmits only pixels to a broad range of software clients, mobile clients, thin clients and stateless PCoIP Zero Clients, providing a highly secure enterprise environment.

From a user's perspective, there is no difference between working with a local computer loaded with software and an endpoint receiving a streamed pixel representation from a centralized virtual computer.

Because the PCoIP protocol transfers only display information in the form of pixels, no business information ever leaves your cloud or data center."

diop So it's all about the pixels?

It does SEEM to add evidence to the dithering theory, but as we know nothing is every as simple as it seems. As soon as @JTL gets setup this should be a very quick answer as he would be able to see if dithering was there and was translating through.

JTL It might be worth reverse engineering steamlink to see how it captures the image.

I think VMWare also uses PCoIP as an option but I doubt there's any free software using it.

If there's a way to reverse-engineer steamlink to at least show a difference in pixel data sent in a good/bad stream (not even looking at the output) then dithering still very much needs to be considered as the issue, at least there would be hard data to lean towards that theory.

I've been thinking about this for a while, but If anyone can use certain versions of Linux comfortably but not others on that same hardware, here's some information that should be collected along with the "distribution version"

1) Kernel version: Do uname -a in a console/terminal

example:

Linux linux 5.0.0-27-generic #28~18.04.1-Ubuntu SMP Thu Aug 22 03:00:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

2) Driver "binded" the GPU: Do lspci -v and copy+paste the block of text that starts with VGA controller

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83) (prog-if 00 [VGA controller])
	Subsystem: Apple Inc. Radeon R9 M370X Mac Edition
	Flags: bus master, fast devsel, latency 0, IRQ 69
	Memory at 80000000 (64-bit, prefetchable) [size=256M]
	Memory at b0c00000 (64-bit, non-prefetchable) [size=256K]
	I/O ports at 3000 [size=256]
	Expansion ROM at b0c40000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: radeon
	Kernel modules: radeon, amdgpu

3) Driver "binded" to X.Org. This one's a bit harder, you need to know the location of the X.Org log file that can change from system to system: Do grep "AIGLX: Loaded and initialized" /var/log/Xorg.0.log (At least on my system)

If all goes well you should get something like this

[    19.230] (II) AIGLX: Loaded and initialized radeonsi

JTL Thanks. I would share my output but mine isn't comfortable to begin with.

Has anybody had luck posting on popular distro forums for advice e.g. Ubuntu/Mint? Although nobody knows of dithering outside of this site.

The Arch community isn't known for being helpful (rtfm ) but they are probably tech-savvy enough to look into it - it's not an Arch-specific issue though but I'd be willing to bet Arch has the same dithering/rendering issues regardless of DE used.

Bumping this as I posted on AskUbuntu for advice to see if a bug can be reported or any support. (I assume the xrandr off setting still doesn't work)

It has already been reported as a bug before

Intel - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776642
Nvidia - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819023

One comment I noticed on the Nvidia thread above

"Also, I don't think "off" is a default that we should ever aim for. Upstream would probably reject that because for many types of monitor "off" will look worse.

Did "static 2x2" work for you? I am assuming the problem was "auto" defaulting to "dynamic 2x2"."

The thing I don't quite understand is that I'm running a 2019 monitor, yet connecting a 2009/2010 PC to it. Colours seem fine, I don't notice heavy banding. Why would 2019 Linux without dithering look "worse" than a 2009 OS?

It's probably better to contain all the Linux discussions to this thread.

I've created a bug with Ubuntu Launchpad here > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1853694

Latest reply:

the flicker is a driver bug, test a newer mainline kernel build

https://kernel.ubuntu.com/_{kernel-ppa/mainline/}

test with drm-tip, and if it still flickers, a bug should be filed upstream

I have installed the latest mainline kernel successfully and selected it during startup.

I have no experience with drm-tip, or it's usage, and I'm not the most tech-savvy. After googling on how to install I get as far as cloning the git and installing dependencies however upon compiling receive errors about 'missing ssh' or words to that effect. Anybody here better versed with compiling from github and can give any advice? I will give it another try from scratch.