A friend of mine just bought Radeon R7 260
That card gives poor qw perfomance in ezquake comparing even to Radeon 5770.. twice worse.
and 1.5 better in darkplaces..
As for me it's a good reason to avoid bying that card. )

Check what CPU he is using with it and also what the processor utilisation (per core) he has whilst playing.

I have a GeForce GTX 770 which is a beast but because I only have an AMD FX 4100 CPU which has poor single-core performance I find I cannot get the FPS that i should in QW. I overclocked the CPU from 3.6Ghz to 4.2Ghz and it made a big improvement but the CPU is still a bottleneck. Even if I overclock to 4.4Ghz it still runs at 100% CPU on that single core. I explored the idea of upgrading my CPU but in the AMD FX series I can really only add more cores but I wouldn't get much more single-core performance so there is no point.

Apparently I would get better performance with a lesser GFX card. It is worth noting that on modern games that utilise multiple cores I get quite excellent performance with the same GFX/CPU combination. (Such as Titanfall, Left4Dead2, Quake Live, etc)

really, he's using athlon x4 @3.6
but i'm still thinking it's the vcard whose to blame.. i use phenom 955@3.9 (it has L3 cache- don't know it's impact on qw perfomance ), and really can't tell which cpu is faster - internet ratings tell they are nearly the same.
by the way cpu utilization in quake will always be 1 full core, even small opengl programs i write for my pleasure utilizes 1 full core always, no matter what king of scene is rendered.

(Edited 2014-05-20, 19:33)

Isn't the golden rule to completely avoid Radeon if planning to play Quake?

not really, if you can dance with -nomtex and can force your heart, your nerve and sinew to serve your turn long after they are gone.. )

This -nomtex is an interesting command. I did some timedemo's with it and i get a 40fps increase on my desktop PC and get 55fps LESS on my laptop. What exactly does it enable/disable?

By the way, if you have a single core at 100% it is a bottle-neck. Try overclocking CPU and maybe it does still stay at 100% but you will get more FPS.

shortly it disables multitexturing (GL_ARB_MULTITEXTURE extension)
main difference can be seen in R_DrawSequentialPoly function,
by default quake tries to set (pass to opengl) texture and lightmap simulteniously,
with -nomtex - consiquently.
May be it was featureous feature back in the days and worked well..

Well interestingly I get a large 40 FPS boost from it so that is great. Any other CMDLine parameters for FPS you would recommend?

no can't recommend anything more.
i know about -nomtex impact on perfomance only because mhquake.blogspot.com wrote about it..
took only a brief look over glquake code, but i'm pretty sure that there would be no other command with such a big impact.
i don't see anything in drawing functions as frequently used as multitexturing.

//i disagree about bottleneck.. it's seems to me that opengl implementation actively waits for video to finish it's work(mb critical section in opengl driver..), so you'll get 100% 1 core load in q1 even on core i7 + voodoo banshee. maybe that rule about 100% load and bottleneck could be apply for more modern games..

(Edited 2014-05-21, 11:58)

I think -nomtex will screw up your powerup glows (test when enemy has quad or pent), and also if you use a semi-transparent weapon model (r_drawviewmodel 0.x) that won't work either.

I almost exclusively play 1on1 so that is no big deal.

Also, I am not able to use anything other than r_drawviewmodel 0 because of the huge FPS drop i get with the SNG with the new weapon GFX in nQuake. I made a thread about it a while ago http://www.quakeworld.nu/forum/topic/6141/huge-fps-drop-when-firing-sng

Someone with gfx-skills is more than welcome to rewrite the rendering in ezQuake. It's really old and needs to be replaced, however I don't have enough knowledge on the subject and haven't found anyone with enough knowledge to fix it. That way it remains as is unfortunately.

when mhquake.blogspot.com existed there were many materials about attempts to optomize quake rendering,
there were many improvements BUT none of them gave advantage on old maps and old monster counts ) 400knights worked really faster 4 didn't
afair he tried using vertex shaders, many lighting technics - may be display list, vertex buffer object - i can't distinctly remember
ezquake is a competitive engine, not eyecandy, maybe it doesn't need complete rewrite.. graphics should be improved but i don't see clearly how that can be done - may be more detailed lightmaps.. that squares makes me feel as an old outdated man ;-)

The intention would only be to rewrite it to use more modern API's and design, mostly to improve performance and perhaps make it possible to use the client on mobile devices.

I digged this topic, because I just made change of my gfx from HD6850 (sic!) to RX580.
And, well, with i5-2400 CPU without the -nomtex during unready glowning I get 600 (sic!) fps less than after geting ready.
W.T.F.? Before that I haven't even heard about the -nomtex function because probably I didn't need it.
So, thx for the -nomtex command but to the hell why does it take 600 fps without it with the glow effect...

try the new ezquake renderer meag by meag:
https://github.com/meag/ezquake-source/releases
(download testing____.zip)

I have been re-writing/updating the renderer, a long slow slog... (as Dimman said, there was no active developers heavily into graphics and god knows I wasn't (still possibly not) qualified either but other projects stalled so I started). I'd be interested to know what version you're using, and also what the base FPS is (i.e. what the impact in frametime is - a 600 fps from 800 is different from a 600 fps drop from 2000).

I don't have a proper AMD card to test on so have no idea if the newer changes fix it, but to try and explain an answer to your question:

• Each surface in the map is stored in a lightmap texture atlas, usually there are several of these (smaller maps might have 3 or 4, larger maps around 20, ridiculously large map will break the 192 lightmap limit in < 3.5).
• ezQuake allocates these lightmaps in surface order as they're found in the map - this is very naive in terms of reducing number of lightmap textures and also leads to lightmaps for one material being spread out over multiple lightmap textures (ideally we'd allocate lightmaps to reduce texture switches based on rendering each vis area, but I doubt that's easily calculable and I haven't gone that far yet. Might be a nice project for someone, then cache the resulting allocations for TB5/3/etc)
• Without -nomtex, the world is rendered by material A, B, C ... each lightmap 1, 2, 3 etc is switched in a different texture unit. The surfaces aren't ordererd in 3.1 etc, so rendering might be: A1, A2, A4, A1, A4, A2, B1, B4, B1, B4 etc. In 3.5 it's always A1 A2 A3 A4 etc, in next version this is a lot more efficient.
• With -nomtex the world is essentially drawn multiple times, first fullbright, then blending in the lightmaps, then adding any lumas (or adding 'luma' first, depending on config settings). The lightmap rendering is done per lightmap texture, so we traverse the world in memory two or three times but have far fewer texture binds.

In 3.5-glsl, the system always uses multitexturing and uses a texture array to store all lightmaps so the lightmap array is bound once at the beginning and then it's texture switches after that (textures are also grouped into arrays where possible). Or you can use r_dynamic 2 and the GPU will update the lightmaps instead of the CPU, which makes it much more parallel. In 3.5-classic, some of the other issues above have been fixed or alleviated as well.

I believe that generally (happy to be corrected, as I haven't done any performance testing on AMD cards yet), on AMD... well, classic OpenGL doesn't get best performance out of the card anyway, but also texture uploads & texture binds are very expensive operations.

I generally develop on a 1060, the only AMD card I have is a R7 240 2 GB which is in the spare PC that just died. I'll try plugging that in and seeing if I can improve 3.5 performance, but it's a weak card so I'm not sure if it's a good test, I might just end up optimising for CPU instead.

First of all thx u meag for elaborating.
I just made some tests for my case

The biggesr impact without -nomtex happens ,idd, on the small maps like DM4, when sticked to the wall ready/unready 1600 vs 1000, well same ratio is when just
jumping around 400 vs 1000 (r/u). With -nomtext is like 1000 vs 1300 here.
@ DM3 the difference is around 300 fps, but the interesting thing is when I stuck to the wall (seeing only wall) the difference depends on which one wall I've chosen, sometimes the difference is barely noticeable. I tried to use some gl_ commands with those buffors etc - no signitificane results.
Anyway, so far the -nomtex command made the job, I'm getting ~100 less frames compared to unready-glowing effect without that command, so no problem. since I can handle some decent 600 fps stable @ dm3, and 900 @ dm4 — its quite enough for my needs.

The last thing I wanted to write is I'm stick to the 2.2 (4306) version (sic!) for some reassons.
Everytime I tried to upgrade something annoyed me too much (like sound-effect, random fps drops, or lag spikes).
Tbh, the only one thing I would like to have from newer is the dedicated sound device chosen indepedent on windows' one.
I left that info for end because I didn't want u to to break reading early
But, maybe I should work with newer clients hardly, but believe me I'm not any tester, just want to run it and play without problems and without solving all issues.
As u see the change from 6850 to rx580 is like 5 generations difference so I didn't complain here much before
Imo the r7 240 should be in the middle of them and rather good platform to test the Radeon issues.

To get the new and improved stuff you need to update the software, that’s just how it works

Prior to 2.2 there were other devs involved, I took over for 2.2 IIRC and then meag joined and has been keeping the ship floating (and floating a lot better).
Anyway, there’s a junp going from 2.x to 3.x, as it’s a major upgrade. The plan was to make important things like input (moise movement feeling etc) not change after this point, or atleast make as few changes as possible related to this kind of changes. So funny enough you have to spend some time going from v2 to v3, but after that point you (hopefully) won’t have to do it again.

The renderer in v2 and older is from the 90’s basically, so nothing strange that it needs a big update. Some people wonder ”why do you keep changing the software? Isn’t it done already?”, the truth is that it’s never done; OS’s, software libs and hardware constantly keeps changing so there’s always things to do, if just to keep it at the same functional level.

Ok, I just left the 2.2 behind, focusing on the 3.1.
So far — nothing changed with the fps drop issue - still exists.
-nomtex still works fine, but what do i loose puting it in my cmdline, anything noticable for visual gameplay?
maeg, the r_dynamic 2 doesn't exist, or doesn't do anything noticable.
Well, finally I just set the maxfps to 462 and that's all.
I guess only vulcan API coul'd help in that case heh.
Anyway alittle bit pitty AMD users are passing over during development :/
Dimman, so in that case newer doesn't mean better :S

If you want to try the new renderer improvements, you need to use 3.5-glsl, not 3.1!
See here

Regarding -nomtex, it's been years since I tried it but I remember that you won't see e.g. enemy quad glow as easily.

For an alternative take on this:

[18:16] gnz: @Milton the new renderer on AMD: incredible on Linux opensource driver... but limited by AMD’s poor OpenGL implementation in their windows driver
[18:17] gnz: 1155 stable FPS with dynamic lights and all fancy shit in linux, not stable in windows... dips to 300s with dynamic lights
[18:18] gnz: Rx580
...
[18:21] gnz: By far the biggest difference was OS
[18:22] ciscon: yeah, the oss driver is much faster than the "pro" one now, pretty ridiculous but hey, c'est la vie
[18:22] gnz: Specifically in OpenGL

As I wrote, I'm sort of happy with that -nomtex.
Considering fact I don't participate in the 1000fps+ competition nor any qw tournament though. So.. no need for change gfx or OS for me so far, but thx for advises ;S
It's even quite funny ppl just need zillion fps @ qw at the same time beeing happy having 60fps @ modern games.

Ok. I've tried toi run the latest 3.5 glsl and it crashed (freezed for ever) during map loading.
The worst thging is that the changed gamma stays in windows after the crash, though none of the gamma/contrast parameter on my sadeon's driver setting had not got changed. Why so?, only windows restart helps in that case, running normal ezquake and closing it havn't helpt.
Where is the best place to report those issues, forum/irc?

Everyone (pretty much) is on discord now: http://discord.quake.world/
Please also try the non-glsl version -std, as it has speed improvements as well.
"Changed gamma stays in windows after the crash" - this has been true of every ezQuake, the hardware gamma adjustment is set. Fastest way to reset in Windows 10 is start menu > "Calibrate display color" to start a calibration (then exit).

Freezed for ever... compared to 3.1? It takes longer to prepare the 2d texture atlas as the map finishes loading, but typically that's around 1 second.

My standard request when people have problems with 3.5 is:

Then send me renderer.cfg. If I can't replicate it then you might also need to send me your gfx/env/etc directories. Then I (probably) still won't be able to replicate it and it will get added to the list of issues stopping it from coming out of alpha. Sadly I don't expect this list to ever be finished.