help with a AMD/ATI performance (Quakespasm GLSL mdl patch)

Discuss programming topics that involve the OpenGL API.

Moderator: InsideQC Admins

help with a AMD/ATI performance (Quakespasm GLSL mdl patch)

Postby ericw » Wed Dec 17, 2014 7:39 pm

Hi, a while ago I was working on a patch for QuakeSpasm to speed up mdl rendering on glsl-capable hardware (lerping between frames done in glsl, one draw call per mdl, all mdl data in a static vbo). It works really well on my main system (nvidia 650gt); for maps like jam3_tronyn (with 120k epolys), I get around double the fps as before.

However, szo tested the patch for me on his radeon HD 7700 and reported r_speeds frame times going from ~60ms to ~175ms on ne_ruins. That's bad enough to suggest software fallback is happening somewhere, I think.

I guess I should find/borrow an AMD gpu system to debug on, but short of that, I was wondering if anyone with an ATI/AMD card would mind giving it a try. Any tricks for debugging software fallback? I am using 4x normalized GL_BYTE for the vertex normals, and 4x unnormalized GL_UNSIGNED_BYTE for the vertex coordinates, which are maybe a bit unusual / old-fashioned vertex formats, but they're listed in this (old) pdf as natively supported on ati: ... _Guide.pdf

Could calling glUseProgram, glBindBuffer, and glVertexAttribPointerFunc per-model be really fatal for performance on AMD? Or maybe combining glsl vertex shading with fixed-function fragment shading is a bad idea.

this is the glsl branch on github:
and a windows binary: ...

the master branch without the patch:

the diff: ... r...alias5

Posts: 90
Joined: Sat Jan 18, 2014 2:11 am

Re: help with a AMD/ATI performance (Quakespasm GLSL mdl pat

Postby revelator » Wed Dec 17, 2014 9:19 pm

glVertexAttribPointer gave me plenty of grief on Doom3 :S seems in some situations it goes haywire on AMD cards so i had to use the old vertex calls instead or the engine would grind to a halt.
Productivity is a state of mind.
User avatar
Posts: 2497
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: help with a AMD/ATI performance (Quakespasm GLSL mdl pat

Postby Spike » Wed Dec 17, 2014 9:23 pm

GL documentation specifies that you must use either attribute 0 or gl_Vertex(if the fixed function stuff is still supported), and that the drivers may or may not alias the two (enabling/disabling one may or may not enable/disable the other, which can be problematic).
both the ati 9600 pro and hd 3200 alias the two, while nvidia drivers do not.
the easy way around this is to always use gl_Vertex for at least one attribute (no, you don't have to use ftransform, thankfully).

also, you're making a lot of enable/disable calls. you should probably make a state manager to reduce all those calls.
personally I'm too paranoid to use vertex shaders without fragment shaders. I get the impression that its the worst of both worlds (though tbh I've not really tried it, I just don't trust it).
Posts: 2853
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: help with a AMD/ATI performance (Quakespasm GLSL mdl pat

Postby ericw » Wed Dec 17, 2014 11:01 pm

Thanks for the ideas so far!

I figured using generic attributes for everything and letting the driver pick the attribute indices would be foolproof, but it sounds like not using attribute 0 could be my problem.
Also there are some interesting details in this stackoverflow answer: ... s-disabled
So that's the first thing I'll try.

Changing it to use a fragment shader sounds like a good idea too, it should make the code more comprehensible.

re: excess state changes, yeah, I should probably refactor it so one function takes a list of all mdl entities to render, enables the shaders, draws everything, then switches back to fixed-function.
Posts: 90
Joined: Sat Jan 18, 2014 2:11 am

Return to OpenGL Programming

Who is online

Users browsing this forum: No registered users and 1 guest