Closed paoletto closed 5 months ago
I would need to see a reproducible test case.
I would need to see a reproducible test case.
how can i provide?
My setup: Intel NUC8 Ubuntu 18.04 KDE plasma desktop Nomachine NX Workstation 6.4.6-25 (trial) Qt5.15 built from git a qtopengl app (https://github.com/paoletto/qdemviewer)
So you get the error when running the Qt app in question using vglrun
?
So you get the error when running the Qt app in question using
vglrun
?
yes, correct, /opt/VirtualGL/bin/vglrun
I carried out one more test, using the qt included computegles31
example :
paolo@nuc:/tmp/computegles31$ /opt/VirtualGL/bin/vglrun -d egl0 ./computegles31
Support for GL 2.0 noprof yes
Support for GL 2.0 core no
Support for GL 2.0 compat no
Support for GL 2.1 noprof yes
Support for GL 2.1 core no
Support for GL 2.1 compat no
Support for GL 3.0 noprof yes
Support for GL 3.0 core no
Support for GL 3.0 compat no
Support for GL 3.1 noprof no
Support for GL 3.1 core no
Support for GL 3.1 compat no
Support for GL 3.2 core no
Support for GL 3.2 compat no
Support for GL 3.3 core no
Support for GL 3.3 compat no
Support for GL 4.0 core no
Support for GL 4.0 compat no
Support for GL 4.1 core no
Support for GL 4.1 compat no
Support for GL 4.2 core no
Support for GL 4.2 compat no
Support for GL 4.3 core no
Support for GL 4.3 compat no
Support for GL 4.4 core no
Support for GL 4.4 compat no
Support for GL 4.5 core no
Support for GL 4.5 compat no
Support for GLES 2.0 no
Support for GLES 3.0 no
Support for GLES 3.1 no
Support for GLES 3.2 no
Error: This system does not support OpenGL Compute Shaders! Exiting.
The fact that you are passing -d egl0
is an important detail. Does the issue also occur if you use the GLX back end?
The fact that you are passing
-d egl0
is an important detail. Does the issue also occur if you use the GLX back end?
With the glx backend (so just vglrun
, without options, or with -d ":0"
) the example works alright, but for some reason my app still throws the same error, as if it is still using egl somehow?
Update: i think i was doing something wrong, i managed to get it to run semi-properly finally! i was LD_PRELOADing qt libs, and apparently this isnt cool somehow? So setting LD_LIBRARY_PATH instead seem to have fixed the issue (with GLX though).
Now i have a different, and probably much harder to solve, problem: the tiles of that app always come out flat, as if the shader doesnt work or the uniforms aren't passed through. But the app runs without errors. Data checked, texel values before uploading are correct. So shader is apparently failing to imageLoad() them correctly from a r32f image
No idea. No one else has reported that, nor have I observed it. The best I can do is attempt to reproduce it, but I need exact reproduction steps rather than a vague description of the problem. It may be specific to the Intel GPU/drivers, in which case I may not be able to reproduce it.
No idea. No one else has reported that, nor have I observed it. The best I can do is attempt to reproduce it, but I need exact reproduction steps rather than a vague description of the problem. It may be specific to the Intel GPU/drivers, in which case I may not be able to reproduce it.
Would a binary build of the app for your platform help you check if it is a reproducible issue with a different gpu/system?
Considering that sampling a texture (sampler) seems to work, it seems something related to layout(binding=0, IMGFMT) uniform readonly highp image2D dem;
and related glBindImageTexture
A binary build is unnecessary. Just post build instructions.
A binary build is unnecessary. Just post build instructions.
Thanks, building the above project would be simple, usual qt5 qmake/make. But i can also try to strip it down to a minimal example that reproduces the issue and post that one here, if it can help :-) most likely in the next couple of days
Yes, that would be helpful. I will not have a chance to look into it before the end of the month, anyhow.
I am available to look into the issue as soon as you can provide a reproducer.
I am available to look into the issue as soon as you can provide a reproducer.
Hi, i didn't manage to strip the project down but https://github.com/paoletto/qdemviewer still reproduces that issue. If you have problems building it, i can provide a build for it. However, i suppose it would still take a linux host to reproduce the issue, is that a problem for you?
I don't mind building the application. I just need to know how to repro the issue using the application.
I don't mind building the application. I just need to know how to repro the issue using the application.
To reproduce here's one workflow that, on virtualgl, should reproduce the issue:
https://github.com/VirtualGL/virtualgl/assets/6912425/55913402-ace3-437a-afc7-125d33f5b72b
Controls on the maps are:
-scrollwheel to zoom
right map: -shift + scroll to rotate -ctrl + scroll to tilt
left map: -hold shift + left click to select a polygon -hold shift + right click to fire the query and get the elevation on the right -right click to clear the selection
OK, but given that I have no experience with the application, I am unclear as to what exactly the issue is. How is it supposed to look?
``
OK, but given that I have no experience with the application, I am unclear as to what exactly the issue is. How is it supposed to look?
So the issue in my case is that on the right map, the terrain is flat, that is no elevation shows. If you change the right map slider, the gray patches remain flat
I can't get the right map to update. I tried shift + right click, as you instructed.
I can't get the right map to update. I tried shift + right click, as you instructed.
shift + right click on the left map, correct? if so you can try to see in the console if there is any networking error, like tiles not downloading
If by "flat" you mean white, then I can reproduce the issue. On my system, the application works properly with an nVidia GPU and nVidia's drivers. It fails in the manner you describe with an AMD GPU and the AMDGPU drivers, which are Mesa-based (as are the Intel drivers.) However, it also fails on the local display without VirtualGL when using the same drivers. This appears to be a Mesa issue, not a VirtualGL issue.
I see. Well, in my case the application works alright on intel locally, but doesn't over virtualGL. However, thanks for verifying the issue. I will run more tests to find if the issue may be somewhere else in the setup (f.ex. i have ran it locally on a UHD620, but remotely on an iris plus 655)
I should also clarify that the failure or success was irrespective of the VGL back end used. GLX and EGL back ends behaved the same.
Hi, and thanks for the great project! it's my first attempt at virtualgl, i checked the docs and tried what i could, but it seems that even though the app is requesting an OpenGL 4.5 context, and the hardware supports OpenGL 4.6, the app seems to be getting only an OpenGL ES 3.0 context:
QOpenGLShader::compile(Vertex): 0:2(10): error: GLSL 4.50 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.00 ES, and 3.00 ES
any idea?