GL.DrawElements doesn't work with hybrid graphix card about opentk HOT 18 CLOSED

Which version of OpenTK are you using? What does GL.GetString() return for Renderer and Version?

https://github.com/opentk/opentk/tree/develop contains a number of fixes for hybrid graphics, which might help. It is also worth giving the SDL backend a try.

from opentk.

I tried to use compiled version of OpenTK.dll from github, but nothing changed. No errors, no primitives in gl control. Just doesn't work.
Renderer: Intel(R) HD Graphics 4000
Version: 4.0.0 - Build 10.18.10.3316

I used my own realization of DrawElements instead, then graphics appears. But GL.DrawElements still doesn't works.

from opentk.

I've had this same issue for a while and I'm getting by with marking my game as one that should use the discrete GPU in the NVIDIA control panel. If OpenTK could do the switching by itself, that would make things a lot easier. I'll give the develop branch a shot in a little bit.

from opentk.

Is there a Khronos API (WGL or GLX) for GPU selection? Last time I checked, Nvidia required static linking to an unmanaged library, or exporting a specific C symbol - none of which can be implemented in C#.

Unfortunately, I do not own any devices with hybrid graphics, so I cannot test this directly. Given that GL.DrawElements does work on single-GPU systems, the failure with hybrid graphics is either caused by a driver bug or by an invalid function pointer.

@AlexKerman try calling GL.LoadAll() to reload OpenGL function pointers after the GLControl is constructed. Make sure you are not calling any OpenGL functions before that point, or you might encounter difficult-to-trace bugs.

Edit: a possible solution is described at http://www.opentk.com/node/3144

from opentk.

That solution will probably work best.

I've been looking into how other graphics libraries in managed languages are doing it, a lot of people seem to be referring to WGL_NV_gpu_affinity, but from what I read, it looks like it's only supported on Quadro cards. which makes it useless.

Pretty much everyone else is saying to set up a profile through the NVIDIA control panel and to tell their users to do the same if they have Optimus cards, which is completely backwards.

I think the best way to do this if you want OpenTK itself to handle it is to integrate the SOP workaround as part of GameWindow, check for an Optimus card on initialization, create the new profile if it doesn't exist, and attempt to cleanly restart the application.

If you'd rather not do that automatically, then expose some APIs to let the user create the profile and check whether or not a restart is needed.

from opentk.

GL.LoadAll() before first opengl command didn't change anything. Most simple method to run my build on optimus card is change nvidia control panel settings to "High perfomance NVIDIA processor". But it's not automatic solution.
Another way to do it is set nvidia profile by SOP.cs. It works, but it isn't solution for me. I don't know how will work DllImport nvapi.dll on computers without nvidia drivers. And there no ways to check this graphics card is realy optimus, not only intel 4000. Also, this method require to restart programm.
I added opencl routine (Mandelbrot example) before opengl initialization. My graphics card switched to NVIDIA without restarting.
And I have only two questions.

1. Why DrawElements doesn't work on integrated card (intel 4000)?
2. Can OpenCL properly work on non-nvidia graphics cards?

from opentk.

1. Weird, I'll give it a shot on my laptop with an Optimus card (that also has the Intel HD 4000 as the IGP)
2. Yes, OpenCL is supposed to be vendor and platform neutral, much like OpenGL.

I wrote an answer for a StackOverflow question about this saying that DirectX, CUDA, C++ AMP, and OpenCL calls would automatically switch to the dedicated GPU, but I couldn't find the same page I got that information from or any other page providing that same list of APIs, so I figured I'd leave it out of my last comment.

But if OpenCL calls trigger the switch, then I guess all you have to do is make a few OpenCL calls before initializing an OpenGL context. Is creating an OpenCL context then immediately releasing it enough to trigger the switch?

from opentk.

Hm.
You even don't need initialize OpenCL context.
Enough to insert one line before init OpenGL context:
var openCLPlatform = OpenCL.GetPlatform(0);
I placed this line at the end of main form constructor. It didn't work in OnShown (before opengl initialization) event.

from opentk.

The thing is, GL.DrawElements should work on the Intel GPU. It is supported and I can confirm to work on my single-GPU desktop (Intel 2000HD, Windows) and dual-GPU laptop (Intel 4000HD, Mac OS X 10.9.1). It is such a fundamental API, that there would have been dozens of bug reports about it if it didn't work.

Since GL.LoadAll() doesn't help, and since there is no crash, then this cannot be an issue with how OpenTK is loading entry points. This leaves the potential for an application error or a driver bug.

As a sanity test, can you please run the "OpenTK.Examples" project and check whether "Static VBO" and "Dynamic VBO" work? The first should show a spinning cube and the second should show points moving outwards from the center of the window.

from opentk.

Sure I can. Both tests passed successfully. Thanks for help I will searching for my mistake.

from opentk.

My mistake is using GL.Enable instead GL.EnableClientState before running DrawElements.

from opentk.

And Nvidia drivers accepted that, even though they shouldn't.

from opentk.

I just found this thread and wanted to catch up with our experience regarding the Intel HD graphics and recent OpenGL. We are using OpenTK for the OpenGL part of our rendering engine. The following is valid for Mobile versions of Intel HD, especially HD 2500 and HD 4000 and Windows 7, 8 and 8.1 (all x64).
While the simple OpenTK examples are working fine, the HD driver simply crashed with some AccessViolationException on DrawElements() until version 10 of the Intel drivers. I've tried to debug the problem but gave up and since then recommend our users to stay away from the onboard graphics.
Now, with version 10.18 I've tried again and there is some progress: The application does not crash anymore. But it still behaves strange and unreliable: We do not use the fixed function pipeline. There seems to be wrong matrices (uniform buffers) ending up in the shaders, shuffling values with every frame, hence completely destroying the scene. Still everything runs fine elsewhere.
I would like to track the problem down in the hope it was caused by a bug on our side. I wonder, if there are more recent examples for OpenTK, using Vertex Array Objects, VBOs, Uniform Buffers and no fixed function pipeline?
I would prefer an OpenTK example over some C++ examples, because it would take the managed memory storage into account. Just in case, the HD driver does not copy some buffers correctly, or so ...

from opentk.

@hokb I think you want to look at this example: https://github.com/opentk/opentk/blob/develop/Source/Examples/OpenGL/3.x/HelloGL3.cs
Though be aware that this is a bug report and not a forum thread.

from opentk.

There seems to be wrong matrices (uniform buffers) ending up in the shaders, shuffling values with every frame, hence completely destroying the scene. Still everything runs fine elsewhere.

I've faced similar problems when testing code on Intel graphics, even when said code works fine on AMD/Nvidia. In my case, I traced the issues to:

1. Incorrect assumptions on uniform id assignments (Intel was laying out sampler uniforms in a different manner, so textures were bound to the wrong samplers)
2. Incorrect behavior of GL.GetUniformLocation for array uniforms and structures on Intel.

I would suggest using a utility such as https://github.com/apitrace/apitrace to record and analyze what is really happening.

There are several examples demonstrating both VBOs and shaders. The HelloGL3 example demonstrates VAOs, VBOs, shaders without relying on the fixed function pipeline. There is no UBO example at this point, but feel free to submit a feature request.

from opentk.

Thanks a lot for the links! Especially apitrace looks really promising. I'll try to track down the reason for the issues with its help. I will also consider creating a UBO example and will then ask again for its addition to the OpenTK examples – in the general forum ;)

from opentk.

Thanks, let me know if you find anything!

2014-04-14 9:35 GMT+02:00 Haymo Kutschbach [email protected]:

Thanks a lot for the links! Especially apitrace looks really promising.
I'll try to track down the reason for the issues with its help. I will also
consider creating a UBO example and will then ask again for its addition to
the OpenTK examples - in the general forum ;)

Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-40339839
.

from opentk.

I found the problem: it appears that the Intel HD driver (other than NVIDIA) does not initializes/zeros uniform buffers automatically. I couldn't find it in the GL specs, but in general I wouldn't blame this on Intel but rather on our renderer. However, NVIDIA (again) seems to be more strict / less forgiving than Intel. It does zeros the buffers.
apitrace has been a great help. Unfortunately it does not support the inspection of uniform buffer objects. Thanks again for your hints!

from opentk.