Spinnies black on Windows 10 with Angle and Gallium #11930
Comments
ronso0
changed the title
back or black? |
|
Upsi, black. Edited. |
|
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. |
|
When I replace the GLSL Spinnies here by the non GL Types, it works: |
|
difficult to debug why it fails... especially when the glsl waveforms still work... nothing suspicious in the log? |
|
I have updated to 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) I can imagine to set up an extra VCPKG build, that produces these DLLs and just add them to the windows installer. What do you think? |
|
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. |
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 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. |
|
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.
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. |
I agree, however from what I've double checked already, they should have the same requirements pretty much. |
|
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. :-/ |
|
@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? |
|
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... |
|
Yes, this should do one with a windows build environment. |
|
How should somebody on Windows debug a bug in the Mesa driver for Linux? For me on native Windows the spinnies work flawless. |
|
This is the Mesa driver on Windows, uses as a opengl32sw.dll in case the windows driver is rejected |
|
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. |
|
On Ubuntu Focal, the spinnies are working with: 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. , |
|
Could you please rephrase that? |
|
Situation on windows without sufficient GL support: Angle (direct 3d):
Mesa Gallium:
Idea to do:
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. |
|
This issue happens also with Qt5 Mixxx 2.4-beta and ANGLE on the same VBox Windows 10. |
daschuer
changed the title
|
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 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. |
|
I tried this in a slightly modified setup, where I can run OpenGL ES under Angle - which is affected by this bug. |
|
With mixxx-2.4-alpha-1657-gd89e8995fb.msi the new flags have no effect. How about using the GL Types on Windows as a workaround until we have a solution? This way we decouple this Isse from the release date. |
Not sure what you mean by that. What does that have to do with the spinnies?
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. 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. |
|
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. |
The 2.3 non Shader Spinies work. Can we just use them on windows and carry on?
Yes, I am not sure about the side effects so ...
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. |
The issue also happens with the OpenGL Gallium (non ES) software rendering driver that should be entirely hardware independent. |
|
I tried to start with |
|
@daschuer can you try https://github.com/m0dB/mixxx/tree/wspinnyoption and run with |
|
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. |
|
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. |
|
But you could confirm the black spinny on a native install using ANGLE as well, right? Do you experience any notable performance gain with the new spinnys ? |
|
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. |
|
Maybe @m0dB can confirm, but for my understanding it is just not using the Shafers but based on the QOpenGlWidget like the legacy GL waveforms. I consider that something is broken with the GSLS types, so it would be the best to solve that root cause, but since it will probably thakr some time, we need a band aid. An alternative would be to merge the flag as it is and tell all users that have a spinny issue to set it. Some of them will never complain and use Mixxx without spinnies. We have also the situation (like in 2.3) that users without GL have No spinnies at all. Is that something we may consider here as well, introducing a software spinnie, that will likely outperform the MESA Gallium glsl type? This is a Qt 6 topic anyway where we have no ANGLE driver without patching it back in. |
|
It is interesting, to say the least, that this works while the most basic GL (without GLSL) of calling glClear doesn't while the waveforms do. I will look into this once more to see if there is a significant difference with how the waveforms code is called. Maybe some missing initialisation. I am not near my laptop though so this will have to wait a bit. In any case, as I understand, this is quite corner case and for most users it will work, right? I'd go for simply adding the command line option, also for the reasons @JoergAtGithub mentions. |
|
OK, that is at least a workaround that can be used instantly. The useres will tell us if this was a good decision or not and we can change it any time later. Can you prepare a PR for that? Maybe the issue is cause by the widget stack? We may create a skin with only a spinnie and check if the issue persists. |
|
Hold your horses! I seems that, contrary to the waveform renderers, initializeOpenGLFunctions() is not called for WSpinnyGLSL! This certainly would explain what we are seeing. Note that I found this browsing the source code on my phone so I might have overlooked something. I will add the call to this branch later on tonight so you can try if it makes a difference. |
|
Sorry, no time. I will do this tomorrow. Or if you want to try, add the call to initializeOpenGLFunctions in WSpinnyGLSL::initializeGL |
|
@daschuer @JoergAtGithub changes commited to https://github.com/m0dB/mixxx/tree/wspinnyoption |
|
Juchhu 🎉 it works, on both also with --enable-vumetergl. Some thoughts:
Does it make sense to replace the No Shader GL spinnie with a software version? |
Can confirm this with ANGLE on Windows11
It seems, that GL VU Meter are now also fast on Windows - no more GUI lag. But this needs confirmation by other users too. |
|
On macOS as well it is smooth. I propose the following: I turn this branch into a PR that makes the GLSL based spinny and vu meters the default and adds command line options to revert to the legacy spinny and the legacy vu meter. What do you think? |
|
That works for me. The alternative with a little more flexibility would be to replace the GL Spinnie that has probably no use case anymore with a software based type. It will probably behave better than the Gallium fallback once we switch to QT6 where we have no ANGLE anymore (unless we use the angle patches). If it is really only a matter of placing the inherited base widget, this should be not much of a deal. If the efforts are bigger we may rely on Gallium and spend our time elsewhere. |
|
I am not sure what you mean with "the GL Spinnie". We have WSpinny and WSpinnyGLSL both derived from WSpinnyBase, which in turn is derived from the WGLWidget. WSpinny does all its drawing with QPainter, but on the QOpenGLWindow as paint device, because it uses swapBuffer. We could change WSpinny so it doesn't use a QOpenGLWindow, but that's not trivial, because of the baseclass that it shares with WSpinnyGLSL and because we would need to replace the swapBuffers call with a repaint or update. We could make the use of QOpenGLWindow in WGLWidget optional. That way WSpinny and WSpinnyGLSL could still use the same base class. Or we could derive WSpinny from QWidget and WGLWidget from WSpinnyGLSL respectively, and use the common code from WSPinnyBase in both either through multiple inheritence or encapsulation. I am not sure though if any of this is worth the hassle and the risk so short before release. |
|
Let's not to major changes before the release of 2.4 !!! |
|
Yes, I agree! But I wanted to expose the situation to clarify what I think @daschuer is suggesting. |
|
PR created |
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
The text was updated successfully, but these errors were encountered: