I filed a bug report a long while ago, about Doom 3 BFG not working on WinXP. It was never answered, but that no longer matters since WinXP is now obsolete. I am hoping that AMD still supports OpenGL and is interested in fixing the driver so that indie devs who use open source engine from iD Software would deliver games to AMD users too, not only to Nvidia and Intel users.
We are using modified Doom 3 BFG engine (id Tech 4 with threading and renderer from id Tech 5) to power our upcoming game. Currently the engine works like a clock using Nvidia and Intel GPUs, but has severe performance issues on AMD.
Particularly it runs at ~60 fps on GeForce 670 GTX installed on AMD Phenom x3 2.2Ghz under Windows 7, but on the same scene it runs at ~20fps on AMD HD7850 installed on AMD Phenom x4 2.4Ghz under Windows 8.1.
Is there any specific person I can get a hold of to discuss whether it's possible for AMD to look into the issue and resolve it (it's strange that it hasn't been resolved, since RAGE has been out for loooong time and since then none of the id Tech 5 based games perform well on AMD GPUs) or if we should give up on AMD OpenGL driver and either add DirectX renderer (which is least likely to happen) or simply not support AMD GPUs (which of course doesn't matter to AMD, but matters to us since AMD has a larger user base than Nvidia and Intel, based on Steam hardware stats) ?
Thank you for your time.
One thing to note also is that a performance issue is not always related to a driver bug. Each OpenGL implementation has it quirks and certain use case may actually take the slow path through the implementation ( resulting in decrease performance ). Could you elaborate on how you are collecting your performance data ? FPS is not really a valid performance metric when it comes to development so it would be nice to see that actual GPU and CPU times for each subsystem or draw calls to help narrow down the culprit.
Here are most recent comparison screenshots (Nvidia gets less than 60fps, but the gap between Nvidia and AMD is obvious):
Note that on AMD dynamic rescaling is on. If it was off, fps would have been even lower. RB on the timers is rendering back end, and as far as I know it is the part of renderer that works with driver.
Both images seems to be showing the same thing and I'm not disagreeing with what you are seeing. However, as a developer I would not use FPS as a performance metric. I'm assuming you have the engine source available, put some debug hooks in to get actually CPU and GPU times NOT FPS to see the GPU and CPU hotspots on AMD platform vs Nvidia.
Images aren't showing the same thing. RB (render back end) on AMD shows horrible timing compare to RB on Nvidia. Those are built in tools for diagnostic. The unit of measure for those timers are not frames per second. They are actual ms spent on rendering.
My bad. I was posting it last night and mixed up the images (posted Nvidia's one twice). Will revise after I get home from work.
Fun fact - AMD R9 (don't know the exact model) has no issues running the engine. Someone suggested it's due to entirely new architecture.
It's definitely driver's issue. I asked someone with GeForce 560 GTX to test the same case, and his RB/GPU/fps values were lower than mine. So the question is how is it older Nvidia outperforms newer Nvidia GPU ? Easy - he was using older driver. So I downgraded my driver to exactly the same version as the test guy was using and bam!, GPU timer went down from 21.7ms to 12.7ms (which is still higher than it was on 560GTX test case, which was ~8ms).
So while Nvidia engineers got with me on the subject promptly, I am still wondering what I need to do to get attention of AMD engineers 😕
It's been a while since I posted this, but either AMD has bad customer service (specifically for OpenGL devs), or terribly short handed, or don't care for PCs and OpenGL any longer after monopolizing consoles market. On the contrary, Nvidia not only cooperates with developers of various caliber and helps to resolve issues, but also sends free hardware (some times) to expedite debugging on the spot.
I have a suspicion that the reason you haven't got an answer is the wrong engineers are looking at this. The Graphics Programming forum is more focused on OpenGL.
Let me see if I can drum up the right person, and will move this discussion into that forum if it makes sense.
What project is it for? Is it for a commercial game? Something else?
I am registered dev and I've been in touch with Nvidia devs since Steam on Linux went to live testing phase. So I do get respond via e-mail. I don't expect driver devs to hang out on the forums. Forums are for discussions between other devs, and for someone like Jim to notice critical issue and communicate it to the driver engineers. Perhaps your issue was fixed in the driver update (like mine was), and they expected you to update driver. It doesn't seem you were persistent enough on the forums, thus it might have been assumed that driver update fixed the issue ?
No one is perfect, not even nVidia. There are plenty of stones we could cast at any major company. I am quite sure that if we dug through the AMD forum we'd find more than one potential bug report with no or sub-optimal resolution. My goal is to minimize that happening to AMD developers as long as I'm here. We won't be perfect, but we should be better.
Let's keep this focused on the technical issues. I won't let this devolve into a comparative analysis of companies and/or nVidia bashing or praising.
I've been discussing this one privately with Alex, and the simple truth is I don't think we're going to be able to help him. There are only so many customer-focused engineers to go around, I had one who was going to look into this, and higher priority work got in the way as we ramp up for GDC. I'm sure this kind of non-maskable interrupt happens where you work.
I agree with jtrudeau..there is no need for fan-boyism or bashing in dev forums. I'm intimately familiar with both dev forums and the same thing happen on both, no exceptions. I can understand the opt frustration since I have posted issues on these forums and have received little or nor response, but development/life goes on...find a work around and proceed until the issue is addressed. If it can't be addressed by a workaround, then there is no need for name calling, the sad fact of the matter is that you may have to mark the platform as not supported or have some caveat in place to say that the end-user should expect perf issues on the platform.