Inertia's picture

Catalyst 9.4

I'm experiencing some problems with Catalyst 9.4 and GL 2.1 contexts created by OpenTK. GL 3.0 contexts work fine, and GL2 contexts created by humus demos work fine aswell. I'm positive that the issue also appears with release builds, problem is not related to debug geterror spam.

The problem is simply very poor performance, 2.5fps in applications that ran over screen refresh rate with Catalyst 9.3. No GL Error is reported, I've attached a log of running the FBO example from OpenTK. Looks ok though.

Is anyone experiencing the same issue? :|

AttachmentSize
Catalyst 9.4 prob.log7.33 KB

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Ok, I am installing the drivers right now, let me see if this happens here, too.

Inertia's picture

It's a really odd thing, I can reproduce it every time after reboot to both my partitions. But what puzzles me most is that GL 3.0 contexts work flawless, one would assume it would be the other way around O.o

the Fiddler's picture

Ok, installed the drivers but cannot reproduce the issue (4850, Vista x64). Both OpenGL 2.1 and 3.0 seems to run as it should. Don't know what could cause this.

Inertia's picture

Guess I'll reinstall monitor drivers and doublecheck the settings in catalyst control center, I've had issues related to the monitor driver before already but they were noticable in flickering not in framerate death.

Thanks for checking it out :)

Btw. does your system find the uniform buffer object extension string? All function entry points could be found, but testing for the extension string returns false. Does that imply it's some kind of beta-test? ;)

kanato's picture

I'm also unable to reproduce this issue on my 4650, Server 2008 x86.

Inertia's picture

Did you install the driver-only, or the catalyst control center too?

the Fiddler's picture

Yes, CCC is installed here. Entry points without the relevant extension string tend to indicate that the feature is not complete.

First impressions: slightly improved performance. FBO blit with 24bit/32bit depth renderbuffers no longer results in corruption/crashes respectively. In fact it no longer works, period (the depth buffer is filled with zeroes). Still testing.

Edit: Scratch that for FBO blit, turns out I was not setting the correct blit mask.

Edit 2: And nope, FBO blit not fixed. Corruption is still there and I now get a crash even with 16bit depth renderbuffers, which used to work before. Way to go.

Edit 3: I also cannot create a DepthStencil attachment no matter what I try. This might be an error in my code, but I'm stumped:

...
GL.GenRenderbuffers(1, out id);
GL.RenderbufferStorageMultisample(RenderbufferTarget.Renderbuffer, samples,
                                  RenderbufferStorage.Depth24Stencil8, width, height);
...
GL.FramebufferRenderbuffer(FramebufferTarget.Framebuffer,
                           FramebufferAttachment.DepthStencilAttachment,
                           RenderbufferTarget.Renderbuffer, id);

Storage is allocated without error, but the last line gives an InvalidEnum error (depth and color attachments work fine, though). Has anyone ever managed to get a depth-stencil attachment to work with OpenTK?

Inertia's picture

It seems the low framerate is only appearing when running the Examples.exe that ships with 0.9.7, my own programs run fine no matter what version context I request. My best guess so far is that ATI Overdrive does not increase clock properly, that's what you get when you have no patience and buy the last "New! Shiny! factory overclocked golden sample! t3h l337!" box on the shelf instead of waiting for delivery of the card you originaly intended to buy. :p

You never call GL.BindRenderbuffer in your code (?!), maybe GL.GetRenderbufferParameters can help further, too. That the last line gives InvalidEnum is weird, it should be fine. Did you try FramebufferTarget.DrawFramebuffer (and maybe FramebufferTarget.ReadFramebuffer too just to see what error you get)? If that is no help, it might be worth a shot looking up the tokens in the ARB_FBO spec and see if they maybe got confused when you merged the GL2 and GL3 specs?

the Fiddler's picture

Even with overdrive off (leaving the card on 2d clocks), I get 3-digit numbers for the fractal example on my 4850. Are you positive the same problems occurs in release builds?

You are right, I do call BindRenderbuffer right after the GenRenderbuffers call - missed that detail because it's hidden in a using region, i.e:

using (this.Use()) {
    GL.RenderbufferStorageMultisample(RenderbufferTarget.Renderbuffer, samples,
                                      RenderbufferStorage.Depth24Stencil8, width, height);
    ...
}

I'll try your other suggestions, hopefully it's just a simple oversight (and not a bug in the merged specs).

Inertia's picture

I've triple checked that it's not related to debug build, in my current sandbox a frame with release.dll takes 6 ms to draw, with debug.dll 8ms. That's nowhere near the 2.5 fps I get running any of the examples, and besides the julia set none of them does anything computationally expensive. It's a really weird thing that's happening there.

Regarding Ati and depth buffers I've not the best things to report either, besides that the float depth format worked flawless so far. Any integer depth buffer seemed to be restrained by the context's depth, only 16 bit depth buffer was somewhat reliable to use.