gl_vk_chopper
gl_vk_chopper copied to clipboard
Undefined reference glxSwapIntervalEXT
Building this on an ubuntu System with Nvidia-355.00.26 driver results in undefined reference to glxSwapIntervalEXT .
Commenting out glxSwapIntervalEXT(..)
call in shared_sources/main_x11.cpp allows linking to succeed. However, the resulting binary is likely not working as intended.
Hi Please can you rebuild this using main_glfw.cpp instead. (select use GLFW in the CMake UI)
Many Thanks
Chris Hebert NVIDIA
On linux, there may also be an issue with semaphores, I am looking into this at the moment, so these are the semaphores that synchronise the rendering with the display. I've had one or two reports of a hang on some linux systems, please let me know if you experience this.
Many Thanks
Chris Hebert NVIDIA
Building with disabled glxswapintervalEXT leads to a black window that hangs and actually brings the whole system to a very unresponsive state. The terminal output says it discovered some files.
I will try glfw build later.
Cheers
I've just pushed a change that provides a temporary work around for the semaphores issue. Please can you pull the latest source before rebuilding.
Many Thanks
Chris Hebert NVIDIA
GLFW build, using the latest VkeGameRendererDynamic.cpp, the binary will launch and display many helicopters and the ocean. It is very choppy and makes the system unresponsive. The system is an integrated gtx850m.
Ok. on line 315 of VkeGameRendererDynamic.cpp, try lowering the instance count to say 32. Ultimately there will be UI to do this. The heli is quite a detailed model, not really designed for realtime, though tests on desktop, (GTX980ti) we get 60fps for around 512.
I reduced it to 6. It runs much faster. There is still a "hickup", where every second the program will hang, and make the whole system hang at the same time. Seems to occur very regularily.
cheers
Yes this is because of the semaphores issue I'm working on right now. I'll let you know as soon as that's fixed.
Thanks chrisjhebert1973: your fix helped me on GNU/linux (ubuntu 16.04)- I experienced heavy GUI lock-ups and freezes(even mouse cursor movement was choppy), but after getting your last fix and re-compiling the binary I'm finally able to see the demo running smooth.(nvidia GTX Titan X, 355.00.26 driver). I want also to comment on initial glxSwapIntervalEXT issue: I experienced that because of wrong libGL.so library symlink - it was pointing to mesa libGL, not to nvidia one - this is known bug of ubuntu libgl1-mesa-dev package, see https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/943162. Had to manually fix the symlink and then the binary was linked successfully.
Hi Ddurnev. Thanks for the heads up on the mesa lib, it was puzzling me a bit, since I have 14.10 currently on my dev machine, I dont seem to experience the issue, but 15.xx and 16.xx seem to get it.
I hope to have the semaphore issue fixed soon, currently I use an array of fences for coordinating 2 frame's in flight, synchronising this is more important.
Glad it's working for you!
All The Best
Chris Hebert
It seems the mesa package bug is reproduced only in Ubuntu XX.04, i. e. LTS releases, since 11.10. BTW it's unfortunate that the demo doesn't support window re-sizing, it still runs in fixed 1024x768 resolution(maybe I could just change it somewhere in source code). On my TX it runs only with 50% GPU load.
Oh, You're running the TX1 version? That's actually not the same build that's no this particular github repo. The one on here does support resizing. However this source on this repo does now build for TX1 as well.
Hang on, I got confused ... TX -> TitanX (not TX1 L4T?). In that case this is the right repo, Is resizing not working? I'll look at that in the main_x11.cpp.
Incidently, there is a (currently hardcoded value) on line 315 of VkeGameRendererDynamic.cpp where the instance count is set. Should be 128 at the moment, try increasing or decreasing. Currently there is also a hardcoded UBO array (sized at 384) in std_vertex.glsl, The instance data is a single mat4x4 so you should be able to increase this to 1024 and be just the right side of the ubo size limit. The heli is quite high res, not really a real time model (round about 130000 triangles) so I think even a titan X would struggle with 1024 of them, but because this demo uses instancing and indirect, there's very little CPU work going on anyway, similar performance could easily be achieved with OpenGL if it was done right. A really good demo to show off the Multi threading friendliness of Vulkan is CSF Threadded (also Bk3D Models). It's worth checking that one out as well.
BTW I'm not able to even compile other vulkan demos on linux(gl_vk_threaded_cadscene or gl_vk_bk3dthreaded for example). Should I create issues in corresponding github projects or for now they are windows-only?
Ok, actually, yes Bk3D does use windows specific UI, But gl_vk_csfthreaded certainly should compile and run. What are the build issues you get with CSF Threaded?
I get for example
In file included from vulkan/nvpro-samples/gl_vk_threaded_cadscene/nvdrawvulkanimage.h:30:0,
from vulkan/nvpro-samples/gl_vk_threaded_cadscene/nvdrawvulkanimage.cpp:24:
/usr/include/vulkan/vulkan.h:1302:5: error: ‘int32_t’ does not name a type
and
/usr/include/vulkan/vulkan.h:2924:5: error: ‘int32_t’ has not been declared
compile errors. BTW the same is in gl_vk_bk3dthreaded. I guess the problem is that some system? .h file is not (properly?) included.
Do you have the 'shared_external' directory pulled down? If so, can you check in shared_external/NSight and see of there is a 'stdint.h' in there. There shouldn't be, but it may have found it's way back in. You dont need shared_external for the linux builds, If the stdint.h is there, try editing the CMake for gl_vk_csfthreaded and removing the line _add_package_NSight() (or something like that) near the top)
Yes it is there. I pulled shared_external repo because instructions in one of the projects mentioned it. Should I just locally remove shared_external folder(not to edit anything)?
What I would do for now is edit the CMake for vk_csf_threaded and remove the call to _add_package_NSight(), this will prevent it from being added to the make file. We will find a more permanent solution to the problem at this end.
Just removing the shared_external folder helped, now it compiles & works. BTW is there any way to see FPS in all demos?
Hi Glad it's working. The demo does show time per frame (in ms) in the top left of the window (pressing 'v' will turn V-sync off), there is also a dump of CPU/GPU timings in stdout.
Thanks for sharing this code! I am a complete beginner to Vulkan and this was the first precious stuttering pixels of Vulkan that I ever witnessed :smile:. My laptop sports dual GPU, one low-end intel for powersaving and one GTX780M for performance. It seems the code selecte the Intel GPU over the NVIDIA one. How can I stop that from happening? I am on Ubuntu 16.04LTS x64. Thanks!
Oops, sorry I just realized this was an issue-tracker.