View Bug Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001560DCP-o-maticBugspublic2019-05-13 21:262023-09-01 21:51
Reporteralexthebassist Assigned Tocarl  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSFedoraOS Version29
Product Version2.14.0 
Summary0001560: Crash on player start when using new OpenGL renderer
Description

When trying to use OpenGL output on DCP-o-Matic player, I get the following:
(dcpomatic2_player:20508): Gdk-ERROR **: 23:01:20.729: The program 'dcpomatic2_player' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 1438 error_code 8 request_code 151 minor_code 11)

Afterwards, the program crashes with a core dump, result of which can be downloaded from here (the link is totally safe): https://yadi.sk/d/qlo089rbJ0XzWA

It works quite well with a “simpler” XCB renderer which was there from the start, but it's slow, and there's still bug 0001472 which makes it too dangerous to use in a “production grade” environment. From what I've briefly read from the core dump, it seems to be a renderer problem, possibly wrong API usage on display initialisation.

Steps To Reproduce
  1. Set up DCP-o-matic Player to use OpenGL for output;
  2. Launch it;
  3. …
  4. ???
  5. PROFIT!

Works on Fedora, but not on every machine. Another Fedora powered computer we have at our lab works well with OpenGL, but for now I can't tell what hardware is it equipped with. I'll fill in more as soon as I get to know what's the other machine exactly. My personal thought is that it is bound to different graphic drivers and, possibly, different OpenGL calls allowed.

Additional Information

CPU: AMD Ryzen 7 2700X
RAM: 16 Gb of DDR4-2400
Video: AMD Radeon R7 240
Video driver: AMDGPU
Displays: two Full HD devices, primary display is a monitor, secondary is used exclusively for movie playback.

While it seems to be easily worked around, the bug is still a showstopper.

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredUndecided

Activities

alexthebassist

2019-05-16 14:35

reporter   ~0003348

Also I can add that if playing, say, a 2K DCP on a Full HD monitor, resize doesn't work. Frames are shown in original size, but shifted vertically (and, possibly, horizontally, can't tell at the moment), subtitles are displayed correctly.

carl

2019-05-21 00:54

administrator   ~0003350

Do you have glxinfo on the non-working Fedora system? If so, can you do

glxinfo | grep version

in a console, and post the output?

carl

2019-05-21 00:56

administrator   ~0003351

Also, I'm struggling to reproduce the scaling problem you mention. Do you mean that a 2K flat DCP on a 1920x1080 monitor is not correctly scaling down to monitor resolution?

alexthebassist

2019-05-23 15:24

reporter   ~0003355

Here's the GLX info:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.6
OpenGL core profile shading language version string: 4.50
OpenGL version string: 4.5 (Compatibility Profile) Mesa 18.3.6
OpenGL shading language version string: 4.50
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

And no, I meant a scope 2K DCP isn't properly scaled. Flat (FHD) DCPs play without problems except the Open GL rendering (if it ever happens) is much slower than the old XCB way. This is clearly seen even without any measurements: the smoothness of XCB playback is almost perfect, if 24 FPS can be considered smooth at all, while the OpenGL renderer looks more like a slideshow that went out of control. I think this can be fixed by choosing a proper vblank sync algorithm.

carl

2019-06-04 11:44

administrator   ~0003366

2.15.6 should have vblank sync.

alexthebassist

2019-06-04 16:22

reporter   ~0003367

Still doesn't start on most launch attempts, both on Fedora 29 and CentOS 7.

carl

2019-06-04 20:54

administrator   ~0003368

Would you be interested/able to do a teamviewer/similar session so I can log in to your machine and diagnose this?

alexthebassist

2019-06-09 13:20

reporter   ~0003370

Yes, but not Teamviewer or other services that transfer the data through an obscure third part infrastructure. As soon as we arrange that with our sysadmins, you'll be granted with direct SSH and VNC access to both of our playback PCs, since they've got somewhat different problems besides non-working OpenGL renderer.

carl

2019-06-09 21:55

administrator   ~0003372

Great!

carl

2022-02-17 00:22

administrator   ~0004877

I think to take this further we need an up-to-date bug report - leave a comment if you're still having problems with this!

Bug History

Date Modified Username Field Change
2019-05-13 21:26 alexthebassist New Bug
2019-05-16 14:35 alexthebassist Note Added: 0003348
2019-05-21 00:54 carl Note Added: 0003350
2019-05-21 00:56 carl Assigned To => carl
2019-05-21 00:56 carl Status new => feedback
2019-05-21 00:56 carl Note Added: 0003351
2019-05-23 15:24 alexthebassist Note Added: 0003355
2019-05-23 15:24 alexthebassist Status feedback => assigned
2019-06-04 11:44 carl Note Added: 0003366
2019-06-04 16:22 alexthebassist Note Added: 0003367
2019-06-04 20:54 carl Note Added: 0003368
2019-06-04 20:54 carl Status assigned => feedback
2019-06-09 13:20 alexthebassist Note Added: 0003370
2019-06-09 13:20 alexthebassist Status feedback => assigned
2019-06-09 21:55 carl Note Added: 0003372
2022-02-17 00:22 carl Status assigned => resolved
2022-02-17 00:22 carl Resolution open => fixed
2022-02-17 00:22 carl Note Added: 0004877
2023-09-01 21:51 carl Status resolved => closed