How do you guys debug GLSL? - debugging

I recently attempted to write some GLSL shader code and did not have much luck when the shader didn't draw what I expected (basically, everything is black on screen). Here are the tools I tried:
Nvidia NSight VS integration - It crashes right away when I start the application, try couples other application even with the simple triangle drawing and still have no luck. Search through the internet and Nvidia forum and seem it is a common issue, and didn't seems to find any solution.
glslDevil - It can start the application but then the program keeps exiting before any rendering happens, the GL Trace is
wglMakeCurrent(0, 0)
wglDeleteContext(00010000)
ChildProcess exited
Get another crash when running another application when after calling
glDeleteTexture(1, 0314EF74)
Child process exited
I have no clue what is going on.
AMD PerfStudio 2 - It seems it is the most promising tools, successfully run my application and display the required information. However, it didn't seems support debugging GLSL, I cannot step through the shader and watching the local variables etc? It seems only support DirextX shader
gDebugger - It works pretty well tool, similar to AMD PerfStudio, but again it is not a debugger, cannot step through the shader code and watching any local variables.
Printf - ?? Someone on stack overflow saying using printf, how can I do printf() in the shader?
Convert DirectX shader to GLSL - Since DirectX shader have better debugging tool, and there are tools like http://sourceforge.net/projects/hlsl2glsl/ to automatically convert the hlsl to glsl, it seems it can be an alternative. I personally didn't like this solution, and really wish I have another choice.
Can anyone suggest how you debug your GLSL? What tool you are using successfully?
I am running on:
NVidia GFX 460v2
Visual Studio 2008 and 2010
GLEW
OpenGL 2.0

You can specify extra outputs using the glDrawBuffers and then inspect that (your printf).
However that doesn't fixes anything when the primitive is outside the drawing area.
Otherwise it's old school programming by pure reasoning and mental debugging.

After many hours struggle, I finally make my NSight working on my machine, and I write up the process in here and hope it will help someone with similar problem,
Download NSight from https://developer.nvidia.com/nsight-visual-studio-edition-downloads, and it involves couple download steps, just follow the instruction. I have Nsight Tegra install before and get a NSight menu in my Visual Studio, however, when I start the graphics debugger, the application crash right away. I think the NSight integration come with the NSight Terga is broken, and reinstall the NSight follow the above link seems fix the problem
When running the NSight graphics debugger, I am not able to debug my shader code due to the fact that my app is using some incompatible function, such as
glTexImage2D()
glTexEnvf()
and much more. The graphics debugger told me I can call a tool named Nav.Launcher.exe to find out a list of incompatible functions in my application. However, I cannot find the tool in my hard drive.
Then I decide to use the gDEBugger to run my application again and turn on Breakpoints->Break On Deprecated Function. This allow my to know all deprecated functions I called in my code. After removed all deprecated functions, the NSight graphics debugger's frame debugger feature can be enabled and I can finally step through my shader code line by line in Visual Studio
Hope this help.

Related

Fortran .for file and Microsoft Visual Studio. How Can I Run It?

I'm new in Fortran and I need your help.
I'm a space engineering student and I'm used to code in MATLAB.
Right now I'm writing my MSc thesis and I have to deal with a code written in fortran77 (I'm guessing it by its extension ".for"). The code has already been tested and used in other occasions.
I use Windows 10 as an operating system and I know that sometimes an old code could show problems depending on the system in which it is run (for instance I've heard about the need of running old versions of an operating system through emulators to solve some problems).
I hope I can still use Win10 for the purpose.
So, I have done the following steps (based on what I have found on internet) in order to configure my system:
I have installed the last version of Microsoft Visual Studio Community 2019
I have installed Intel OneApi Basic Toolkit and then Intel OneApi HPC Toolkit (the last one is an add-on that contains the fortran compiler).
It seems that both are well configured/integrated and I think they are working properly.
Now, when I try to open the project from Visual Studio, the .for extension isn't apparently recognized.
So I've tried to open it as a simple file, and in doing so, I can visualize it on VS.
I don't know If It is the right procedure, and I don't know if it works as it should.
How can I prove it?
I try to run it, but nothing seems to happen (no error flag by the way).
I'm totally new in this field, so any "obvious" suggestions will be really appreciated.
I'm open to any tips, even If it is better to change compiler (I've heard about gfortran) or use other kinds of softwares. I would be also grateful if someone could suggest me a beginner useful guide.
Thanks to whoever wants to help me out.

android ndk hw debuggning memory

Backgrond
I am very experienced in C and pretty new to Android and Java, but this is rather environmental issues that programming.
I have developed an administrative application in ANSI-C to be ported to any OS, just adding a UI in OS-dependent code. Well it uses quite some memory, especially for huge user files. I have a working Win32 program, trying to make an Android app using Android Studio with NDK.
Android studio bundle NDK installation works fine
I have installed and made a Win7 ultimate Android Studio 1.3 with bundle NDK and made compiling and running the ActionbarStyled (non NDK) hello-jni (NDK) sample in the emulators, smooth and nice. I also in the emulator been successfully running Hello-jni sample with a bunch of extra c-files (not called, at present just garbage, compiled without errors, in this step)
Then I tried to connect my Samsung TAB3 SM-T110 template (one need a Win7 Samsung driver SAMSUNG_USB_Driver_for_Mobile_Phones.zip) to my Win7 and tried it. ActionbarStyled sample works just fine. So does the Hello-JNI sample.
But
Running Hello-jni sample with a bunch of extra c-files I get this error message:
Error while starting native debug session: java.lang.IllegalArgumentException: Unable to find process for com.example.hellojni on device samsung-sm_t110-47900bc50c0c3100
I try to understand what is the issue? Is it lack of memory, the Samsung is full of active running apps, the emulator obviously not.
What makes the Samsung unit to halt the application? Error message is not that describing?
Some more questions supporting handling this kind of issues
We are talking about Android studio 1.3 bundle NDK, how much from earlier setups (in articles) are applicable for this new future NDK standard use?
Memory?
Running the pure Hello-jni sample I have about 6Mb memory (where 5Mb are used), that is pretty poor for my needs, is there something I need to do have my app getting more memory allocated? Is the error message due to running out of memory?
How large Android Apps are possible to do? Are we in a world like the 8-bit DOS 64Kb segment business again? I know it from past but that isen't the case? And if need to know to handle it. The Library for unrestricted heap memory for bitmaps using NDK on Android question is interesting to read, but here we are talking about the jni (C-)code rather than java.
Compiler optimisation?
I have some really huge C-files due to that they are machine generated converting an XML library of documents to C-code (made a program writing C-code from the XSD definitions). In an application I most of the time use only say 5% of all the C-function, the rest are in Windows dev studio/compiler optimised away. Certainly I can reorganise my source code to quite some extra work, but I need to know. How is the optimisation in the Android Studio NDK support?
Thing is in this test no extra C-functions are called except the same regular as in the hello-jni sample. Actually the compiler should make exactly the same in both cases (the modified and the original hello-jni). But obviously it don't. Please explain a bit more how the environment works so I know?
General interest
I tried to find any spot in the Android developers that describe things like compiler behaviour, memory management and environment (the Java handles such completely different, but in C-programming on need to be aware). I think for NDK use it would be interesting getting a good answer here, for the general understanding of the environment, somewhere in the Android developer pages, rather than here. That also includes how the compiler optimises in different situations. But also how to make environmental settings.

OpenGL fails to render on windows 8

I am encountering an issue where nothing is rendered when running a simple OpenGL application through VS 2012 on Windows 8.
I had a little debug renderer I was using to prototype some projects and had it up and running on Windows 7 using VS 2012 Express Edition.
I upgraded to Windows 8, and cloned the git repository with my work on. After installing the latest drivers and installing VS 2012, I ran my application, but nothing displayed, all I get is the screen clear colour. I was getting an exception before but that's because I didn't have the right drivers so when calling glGetIntegerv(GL_MAJOR_VERSION,...) I'd get -1 as OpenGL wasn't set up correctly. It is initialised correctly now and when stepping through, it looks like everything is working fine, the only problem is I'm not seeing anything.
To make sure it wasn't just my code I downloaded some of the Swiftless OpenGL examples and got the exact same thing. My application was using OpenGL 3.2 and no deprecated functionality. My hardware can support up to 3.3, and if it is of any use I am running Window 8 through Boot Camp on a Macbook air.
I have been bashing my head against a wall for the last couple of days trying to solve this but I'm not having much luck, I thought I'd throw it out there to see if anyone has had a similar problem, I'd be really grateful if anyone can offer any information. If someone with Windows 8 could download and build a simple OpenGL application though VS just to see if they can get something up on screen that would be interesting!
Do you use the good old and deprecated fixed function pipeline, namely immediate mode draw calls like glBegin(), glVertex*() and glEnd()? If so, try to draw your stuff using vertex arrays. Even if this doesn't help in your specific situation, immediate mode draw calls should be avoided at all cost to make the code forward compatible. The OpenGL 3.x core profile doesn't contain these old API functions anymore. I had also a blank screen on my new Win 7 notebook (OpenGL 3.3) because of some stale immediate mode draw calls (FTGL).
EDIT:
For independent GL debugging, I recommend this:
http://www.gremedy.com/
This program allows you to pause the execution and investigate buffer contents, shader programs and more.
After installing the latest drivers
Where did you get the drivers from? Only drivers you download directly from the GPU vendor's website ship with proper OpenGL support. The drivers automatically installed by Windows have only poor OpenGL support.
opengl support is not available for windows 8.their are still techniques to use it on windows its better to search on google coz i tried for minecraft game or u can check here too

Improve performance of "Accelerate your Widgets with OpenGL" Qt Sample?

I have been studying the Qt Quarterly article about QGraphicsScene and OpenGL for the purpose of using it in a project. I have already decided to use Qt, given its all-round excellence, but have gone down the road of implementing a class derived from QGLWidget, however I would then still need to implement the UI elements. Using techniques from the quoted article would mean I could also use Qt widgets for the UI as well, making the program dependent on Qt alone (and not CEGUI or similar).
Anyway I have been running the sample under a desktop Linux machine, which has an Core i7 and a fairly good Nvidia card and it runs well, however my on my 2010 MacBook Pro (Core i5 and Nvidia 330) it runs very poorly indeed, especially when interacting with it using the mouse.
Question: can anyone suggest ways of improving the performance of this sample? I'm no Qt expert but I think the poor response is due to calls to update() from within the mouse handling code coupled with the timed calls to update() at the end of the method itself. I think what is needed is a background thread to update the object movement and a timed but constant call to update().
Can anyone comment on this?
EDIT: I have already tried removing all calls to update(), apart from the timer reset, and it makes very little difference.
Unfortunately the performance that you get when using the suggestions from that article is pretty bad. We tried that on an embedded system and it was far to slow.
For us the solution was to use QML, the new "declarative" UI capability in Qt 4.7. We have QML embedded in our C++ application. We are seeing huge speed improvements with QML widgets overlaid on top of our GL scene.
We are using the QDeclarativeView widget in our C++ application, which is capable of displaying our QML content. See: http://doc.qt.io/archives/qt-4.7/qdeclarativeview.html.
This should work fine on the desktop (works for me on Ubuntu).
More useful links:
Using QML Bindings in C++ Applications
Integrating QML Code with Existing Qt UI Code
UPDATE! 1/20/2015:
In Qt5.4 there is a new class called QOpenGLWidget that basically makes it so you can use "classic" Qt widgets with an OpenGL background with great performance. They finally adressed this issue directly! Read the blog post, and then the docs:
Qt Blog Entry about QOpenGLWidget
QOpenGLWidget Docs

Debugging Assembly Code (Intel 8086)

I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.

Resources