Different line drawing output between OS/Hardware

Hardware
1

Dear PTB forum,

I am currently coding my first experiment with PTB and I’m running into an issue.
When drawing lines on the experimental computer (AMD RX 570, Ubuntu 20.04, PTB from Neurodebian), they aren’t displaying as they do on different hardware/OS. They look like this (notice how they are “cut” at both ends):

lines_bad
lines_bad1920×1080 12.3 KB

On my development laptop, they are displaying as expected (Same OS and PTB version, GPU is Nvidia GTX 1660 Ti or Intel UHD Graphics 630 [both are fine]). See here: https://imgur.com/a/1IeBhC4 (As a new user I can’t post 2 screenshots in a post, sorry). They are also displaying fine on the experimental computer when running Windows 10 (PTB 3.0.17).
Here is the snippet of code I use to create the lines. (pd is a function to convert degrees of visual angle to pixels).

function crosshair(x0, y0, color, targetRadius, scr)
    % x0, y0 = center of circle; color = RGB color triplet
    % targetRadius = Radius of the target in DVA; scr = screen information
    lineLength = 1/3; % Length of lines (DVA), from outer boundary of the target
    lineWidth = 3; % Width of lines (px?)
    xy = [];
    for theta = linspace(pi/4,7*pi/4,4)
        [x1, y1] = pol2cart(theta, pd(targetRadius, 1, scr));
        [x2, y2] = pol2cart(theta, pd((targetRadius - lineLength), 1, scr));
        xy = [xy, [x1 , x2; y1, y2]];
    end
    Screen('DrawLines',scr.dispWindow, xy, lineWidth, color, [x0,y0], 2);
end

Would you have any idea what could cause this and how to remedy it?

Best regards,
Martin Constant, PhD Student.

2

That seems to be a driver issue from what you describe. Are you using the opensource amd driver?

Perhaps as a work-around you could draw filled polygons for each line segment instead

3

Thanks for your answer, that’s what I thought too. I think I’m using the opensource driver (I haven’t installed any specific driver). If it helps to debug, here is the output of the console when opening Screen (with verbosity = 10): https://pastebin.com/0bjdd8en
The work-around could indeed work for this experiment but I’ll use this setup in the future so a more permanent fix would be good (and I also don’t know if this problem is just the tip of an iceberg of problems).

4

This is a driver limitation in the default open-source Mesa radeonsi driver atm. The hardware can only do line stippling by itself (cfe. Screen('LineStipple') if it uses non-perpendicular line endcaps. The TODO says roughly “change to perpendicular endcaps, once somebody writes a driver internal fragment shader implementation of line stippling to overcome this limit.” - So far nobody felt the calling… I gave it a stab sunday evening, but it turns out to be more involved than i hoped, so i don’t think i can complete it soon without proper funding in place – paid projects take precedence. This is one of the reasons we really need the labs to buy memberships, so we can build up a big enough pot of money to pay for my time doing such work… I do have a simple source-code patch to enable perpendicular endcaps, but as the code comments said, that breaks line stippling, so this is not going to fly, fixing one thing to break another thing…

This is btw. what the OpenGL standard says about line endcaps:

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glLineWidth.xhtml

My undestanding is that these vertical or horizontal line endings are exactly what is supposed to happen if you choose line smoothing flag 0 (ie. no line smoothing) , and the standard is not very strict about how implementations are supposed to draw lines. In principle they are also allowed to not draw smooth lines at all.

Anyway, i did a quick test of this feature on different OS + GPU combos, and in general, line rendering is quite inconsistent across systems:

macOS + AMD: Horizontl/Vertical line endings on wide lines, regardless what is requested.

Win10 + AMD: Smoothed lines are perpendicular, non-smoothed are horizontal/vertical, regardless if multi-sample anti-aliasing MSAA is on or off.
Win10 + NVidia: Smooth or MSAA perpendicular, hor/vert otherwise.
Win10 + Intel: Smooth on → perpendicular, smooth off → hor/vert. But if MSAA is also enabled, then lines are always hor/vert.!

Linux + Intel: Smooth on or MSAA on → perpendicular, hor/vert. otherwise.
Linux + Nvidia: Untestes.
Linux + AMD: What you found.

So it’s a bit all over the place also on Windows and macOS…

I guess the only way we’d get consistent line rendering on all OS + HW combos would be if we implemented our own line drawing by use of anti-aliased rectangles. Doable, but again, paying work takes precedence, unless enough labs contribute financially to PTB’s upkeep.

In general however, the combo Linux + AMD (and also the generation of AMD gpu you have) is the by far most well tested and well supported one by myself, followed by Linux + Intel, and maybe Linux + RaspberryPi. Everything else is a lower priority, because i couldn’t do anything about bugs or problems anyway, given other systems only have proprietary drivers.

In theory you could try installing the amdgpu-pro driver which is a hybrid out of open-source low-level kernel driver and proprietary OpenGL driver. In pracice, that driver will lose you all the high precision timing and other advantages of the mostly superior open-source driver, and in my experience that driver is way more buggy.

-mario