Spinnies black on Windows 10 with Angle and Gallium

[daschuer]

Bug Description

The spinnies are black. All Waveform Types are working. Legacy GL types are loosing frames.

OpenGL-Version: 3.0 Mesa 12.0.0-rc2 (Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits))

With --enable-vumetergl, the VU-Meters are black as well.

In Virtual Box 7.0

Version

2.5.0-alpha

OS

Windows 10

[Swiftb0y]

With --enable-vumetergl, the VU-Meters are back as well.

back or black?

[daschuer]

Upsi, black. Edited.

[JoergAtGithub]

This is not a general problem, on my Windows 11 system with AMD GPU the Qt6 spinnies look good and work smooth:

[Swiftb0y]

This is not a general problem, on my Windows 11 system with AMD GPU the Qt6 spinnies look good and work smooth:

Thanks for confirming. I suspected that the virtualization was at fault here. I guess the next step would to be try gallium on linux and see if the issue persists.

[daschuer]

When I replace the GLSL Spinnies here by the non GL Types, it works: https://github.com/daschuer/mixxx/commit/1c5f6f0e484cd1d624b2bbd9efad067f27bd8b55

[Swiftb0y]

difficult to debug why it fails... especially when the glsl waveforms still work... nothing suspicious in the log?

[daschuer]

I have updated to 4.5 (Compatibility Profile) Mesa 23.0.1 (llvmpipe (LLVM 15.0.7, 256 bits)) The latest opengl32sw.dll + liglapi.dll + libgallium_wgl.dll from VCPKG and it works everything with no regressions.

The only issue is that this extends the 2.5-rel package by 2 GB and exceeds the GitHub build time limits of 6 hours by far.

Since it is a plug-In DLL, we don't need anything else from the 2 GB than the three DLLs of together 44.1 MB (packed 16,7 MB) Our windows installer is 83 MB

I can imagine to set up an extra VCPKG build, that produces these DLLs and just add them to the windows installer. This will not be relevant for 2.5 with the QWindgets interface but is a prerequisite for QML on non GL machines.

What do you think?

[daschuer]

By the way, with the same DLLs and the 2.4-beta the spinnies are still broken, not black, but wit artefacts:

So I guess there is something tricky going on with the GLSL spinnies. The Mixxx log looks good:

Debug [Main] OpenGL driver version string "4.5 (Compatibility Profile) Mesa 23.0.1", vendor "Mesa", renderer "llvmpipe (LLVM 15.0.7, 256 bits)"
Debug [Main] Supported OpenGL version: 4.5

[Swiftb0y]

This will not be relevant for 2.5 with the QWindgets interface but is a prerequisite for QML on non GL machines.

This will all be irrelevant for the QML UI anyways since that runs on QRhi and thus uses the native APIs. IIUC the problem here is only relevant for Qt6 without QML (so 2.5 and (hopefully not) later).

I can imagine to set up an extra VCPKG build, that produces these DLLs and just add them to the windows installer.

I don't know much about packaging so I can't give my opinion on that. But yes, the best way would probably to ship the up-to-date translation layer while avoiding the size and build-time overhead somehow, not sure how best to do that though.

[Swiftb0y]

At least we now confirmed this to be a driver issue...

[daschuer]

At least we now confirmed this to be a driver issue...

This conclusion is not 100 % confirmed. For me it is a combination of both.

• GLSL Waveforms work with any drivers.
• GLSL Spinny:
  • Work with QT6 and recent Mesa 23.0.1
  • Don't work with QT5 and recent Mesa 23.0.1
  • Don't work with QT6 and outdated Mesa 12.0.0-rc2

Conclusion: There is something fishy in the GLSL Spinnies that puts high demands on the Gallium Mesa Diver AND on the QT framework. Since we have many different drivers and GPUs out there, it would be good to remove that part from the GLSL and lower the requirements to the same level as the GLSL Waveforms.

[Swiftb0y]

it would be good to remove that part from the GLSL and lower the requirements to the same level as the GLSL Waveforms.

I agree, however from what I've double checked already, they should have the same requirements pretty much. IIRC Mesa has validation layers, have you tried to enable them to see whether it can tell us whats wrong?

[daschuer]

Not yet, all that is quite cumbersome because I am not at windows and need to do everything remote, and on a virtual machine. I hope a windows contributor can take over.

Now the Qt6 version has also the artefacts. :-/

[daschuer]

@m0dB do you have an idea what we can do here? Something like minimal GLSL testing spinnie to check if GLSL is working at all?

For now I think we should just disable GLSL spinnies on windows by default and proceed to the other issues and finally release 2.4. The GL Spinnie was never a bottle neck on Windows.

What do you think?

[Swiftb0y]

alternatively, asking the mesa team for help could also be an option. They usually don't seem to have problems investigating mesa-related GUI issues in applications...

[daschuer]

Yes, this should do one with a windows build environment.

[JoergAtGithub]

How should somebody on Windows debug a bug in the Mesa driver for Linux? For me on native Windows the spinnies work flawless.

[daschuer]

This is the Mesa driver on Windows, uses as a opengl32sw.dll in case the windows driver is rejected

[m0dB]

This is very strange. The shader used in WSpinnyGLSL, mixxx::TextureShader, is also used in all the GLSL-based Waveform types (in WaveformRenderMark). I will compare the code of both locations to see if I spot something that could explain this.

There is another shader used in WSpinnyGLSL, mixxx::VinylQualityShader, which is only used there. It shouldn't be used if vinyl quality isn't enabled, but it is always instantiated,so it might be good to comment m_vinylQualityShader out entirely to see if that makes a difference.

While looking at the code, it did spot two erroneous calls to m_textureShader.setAttributeArray instead of m_vinylQualityShader.setAttributeArray in WSpinnyGLSL::drawVinylQuality. I will create a PR with a fix.

[daschuer]

On Ubuntu Focal, the spinnies are working with: 3.1 Mesa 21.2.6 (llvmpipe (LLVM 12.0.0, 256 bits))

The issue is that I see lost frames on 60 Hz. So my conclusion is that providing the Gallium (llvmpipe) driver on Windows has no benefit on for the waveforms, but the it allows spinnies. ,

[m0dB]

Could you please rephrase that?

[daschuer]

Situation on windows without sufficient GL support:

Angle (direct 3d):

• gpu waveforms, No spinnies

Mesa Gallium:

• Heavy to build and ship
• Additional waveforms perform bad.
• Spinnies broken

Idea to do:

• Fix Angle GLSL ES waveforms
• Fix Angle GLSL ES spinnies
• Introduce a CPU software spinnie.

We have no benefit from gallium if we provide a CPU solution for all widgets.

ES support is also desired for Raspberry Pi and friends.

[daschuer]

This issue happens also with Qt5 Mixxx 2.4-beta and ANGLE on the same VBox Windows 10.

[m0dB]

I think the way to find the issue is to start with something minimal and gradually add features to the spinny and see when it fails. It must be something silly. I will prepare something this weekend but I'll need someone else to test it.

[daschuer]

@m0dB Does a software spinnie makes sense? Is it just a matter of replacing the base widget? Did you make progress with the debugging?

Since we are long past our original 2.4-beta, we need to consider a quick hack solution. As a bandaid we may replace the "No GL" label with the software spinnie that is not spinning?
Or just carry on ... :-/

[daschuer]

I will prepare something this weekend but I'll need someone else to test it.

I can test on my virtual machine. However I do not consider this as a significant user device. So tests on a real GLES device would be helpful.

@JoergAtGithub can you reproduce the issue with https://github.com/mixxxdj/mixxx/pull/11982 and QT_OPENGL=angle?

[m0dB]

On my macOS the difference is noticeable so if we want to go for a workaround, I'd restrict that to Windows. But let's do one attempt to figure this out.

[m0dB]

I actually think I know what it is (something very simple, but let's see)

Please try with this branch, or just take the attached wspinnyglsl.cpp and wspinnyglsl.h

https://github.com/m0dB/mixxx/tree/wspinnyglsltest

wspinnyglsl.zip

Load a track and click on the spinny to walk through 13 different states, starting with full red, full green, full blue.

[daschuer]

I still see artifacts with the gallium driver on Windows 10 VBox:

I cannot test the ANGLE version, because the angle PR is not included.

[JoergAtGithub]

@daschuer I think this was not supposed to fix the issue. I think this should generate 13 different pictures, which should help to understand the issue on your system.

[daschuer]

The spinnie looks always the same; even after repeatedly ckicking on it.

[m0dB]

That really makes no sense. In the initial state it just should be a red square; the only thing the code does is clearing the color as red. When you click on it, it should change to green. I really don't understand how this cannot be working.

[m0dB]

void WSpinnyGLSL::paintGL() {
    glDisable(GL_DEPTH_TEST);
    glEnable(GL_BLEND);
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

    if (m_state == 0) {
        glClearColor(1.f, 0.f, 0.f, 1.f);
        glClear(GL_COLOR_BUFFER_BIT);
        return;
    }

Are you 100% sure you have the attached files compiled in?

[daschuer]

I am not able to compile on windows. So I have used the Installer form the linked GitHub from https://github.com/m0dB/mixxx/actions/runs/6190360626. Let me try again.

[daschuer]

My guess is that something is messed up initially so that the test code not even starts.

[m0dB]

Yes, looks like it. I will simplify things even more. I'll let you know when I commit another test version.

[m0dB]

@daschuer can you try with my last changes? they add to command line options

--skipSpinnyTextures and --skipSpinnyVinylQuality

Please try with both, and with either one.

It also reduces the number of states to click through.

[JoergAtGithub]

I tried this in a slightly modified setup, where I can run OpenGL ES under Angle - which is affected by this bug. With angle the spinnies are always black, independent of the option: with normal OpenGL, they are colored (red before I click on it):

[daschuer]

With mixxx-2.4-alpha-1657-gd89e8995fb.msi the new flags have no effect. All combinations have the visual moving artefacts.

How about using the GL Types on Windows as a workaround until we have a solution? Or introduce CPU Spinnies? Is the later just a matter of changing the wiget type?

This way we decouple this Isse from the release date.

[m0dB]

How about using the GL Types on Windows as a workaround until we have a solution?

Not sure what you mean by that. What does that have to do with the spinnies?

Or introduce CPU Spinnies? Is the later just a matter of changing the wiget type?

Only for Windows, right?

As I don't understand why this is not working, I am not sure if changing the widget type is sufficient. But I can add a command line option to try this.

[JoergAtGithub]

Only for Windows, right?

As I don't understand why this is not working, I am not sure if changing the widget type is sufficient. But I can add a command line option to try this.

The problem only occurs on old Windows systems with broken OpenGL drivers. In that case Qt5 falls back to ANGLE OpenGL emulation. ANGLE supports OpenGL ES only, and OpenGL ES shows the broken(black) spinnies. I needed to enforce this fallback on my system by setting $env:QT_OPENGL = 'angle'.

For Windows we could discontinue ANGLE support easily - because it's not supported by Qt6 anyway. But AFAIK OpenGL ES is also needed for real Embedded Systems like a Raspberry Pi. This is not needed to be supported in the official Mixxx packages of cause, but some users compile it for these platforms themself.

[m0dB]

But I don't understand why the waveforms do render correctly, and why the Spinnies, with even the most basic OpenGL - without any shaders, just calling glClear with a glClearColor, do not work. That makes me think that the maybe the problem is that the QOpenGLWindow based widget does not work with small windows with ANGLE? In any case, adding some command line options to force the use of the old spinnies might give more insight. But this would still be QOpenGLWindow based.

[daschuer]

How about using the GL Types on Windows as a workaround until we have a solution?

Not sure what you mean by that. What does that have to do with the spinnies?

The 2.3 non Shader Spinies work. Can we just use them on windows and carry on?

Or introduce CPU Spinnies? Is the later just a matter of changing the wiget type?

Only for Windows, right?

Yes, I am not sure about the side effects so ...

As I don't understand why this is not working, I am not sure if changing the widget type is sufficient. But I can add a command line option to try this.

Of cause understanding the root cause would be the best foundation. But If this releases some pressure form us it is welcome. Just as an idea.

[daschuer]

That makes me think that the maybe the problem is that the QOpenGLWindow based widget does not work with small windows with ANGLE?

The issue also happens with the OpenGL Gallium (non ES) software rendering driver that should be entirely hardware independent. Interestingly it fails however only on windows and not on Linux. So Windows or MSVC is also part of the game. The Galium HUD is by the way rendered correctly in the spinnie areas on top of the garbage.

[JoergAtGithub]

I tried to start with --enable-vumetergl and than the VUMeter are also black:

[m0dB]

@daschuer can you try https://github.com/m0dB/mixxx/tree/wspinnyoption and run with --enable-legacy-spinny ?

[daschuer]

Works on Windows 10 Virtual Box 7 with Angle and MESA GALLIUM. Without the flag both is broken.

How to continue? It looks like the legacy version is good enough on windows and I propose to always use the legacy spinny but keep a flag that allows to switch to the Shader version. This should offer a good experience by default. What do you think?

[JoergAtGithub]

I don't think we should change this short before release. The current version is confirmed to be working by every Windows test user I know. Only with Virtual Box and ANGLE the problem occurs, therefore we should change it only for these special setups.

[daschuer]

But you could confirm the black spinny on a native install using ANGLE as well, right? And we had never spinny issues with 2.3 on windows using the GL No-Shader version. From that point of view I consider it better tested than the Shader version and a good band aid to lower the risk.

Do you experience any notable performance gain with the new spinnys ?

[JoergAtGithub]

No, performance is the same. But the combination of old and new is completly new and untested. I consider this as too risky to solve such a rare case.