Patrol1985 Posted June 12, 2014 One of my netbooks features the following processor: AMD E1-2100 (2 x 1 GHz). The unit comes with an integrated Radeon HD 8210. When I run Chocolate Doom or PrBoom+ in 8-bit mode I get a surprisingly poor performance - the frame rate is constant, but it's easily visible that it's below Doom's 35 FPS. When I switch to OpenGL in PrBoom+, the frame rate goes significantly up offering a very smooth gameplay (uncapped FPS mode). Therefore I'd like to ask - is software mode in Doom source ports so CPU demanding or is there something I can do with my machine to improve performance? edit: My OS = Linux Mint 16 0 Share this post Link to post
plums Posted June 12, 2014 Don't know anything about that specific card, but I know ATI cards in Linux have a history of poor performance, even with 2D applications. IIRC the proprietary driver has better performance with 3D than 2D... but again I don't know if this applies to your specific card or not. Anyhow it's one possibility. Do other 2D programs/games run OK? 0 Share this post Link to post
Patrol1985 Posted June 12, 2014 I use proprietary drivers. I haven't really tested any other 2D game or program. I'm waiting for Linux Mint 17 XFCE to be released (probably in about two weeks time), because it runs on an updated kernel, which gives a MASSIVE performance boost for AMD cards (to give some numbers - I ran a Quake source port on the current system and received about 11 FPS, I tested one of the systems with an updated kernel and received 72 FPS on the same computer) It just puzzles me, because right now my AMD card performs even worse than my Intel integrated chip in a different netbook... and that's just... cruel! :D 0 Share this post Link to post
kb1 Posted June 12, 2014 Are you using 1024x768 resolution? If so, choose any other size (even larger), and try it. I have found that 1024 width wreaks havoc with memory cache, in general. You may find that 1280x1024 is actually faster, ironically. 0 Share this post Link to post
plums Posted June 13, 2014 Patrol1985 said:It just puzzles me, because right now my AMD card performs even worse than my Intel integrated chip in a different netbook... and that's just... cruel! :D As much as Intel's gfx chips suck, and they really do, they've got excellent driver support in Linux. They support their own open-source drivers, so performance in Linux doesn't suffer any compared to Windows. The same has definitely not been true about AMD/ATI cards, though again, I don't know how newer cards perform. 0 Share this post Link to post
Patrol1985 Posted June 13, 2014 So Linux users are stuck either with weak Intel graphics using good drivers, or AMD/nVidia graphics using weak drivers? Awesome... 0 Share this post Link to post
Blzut3 Posted June 13, 2014 Most of the software renderers are single threaded, so your issue is definitely your 1GHz clock rate. Although some ports have fairly optimized software renderers (ZDoom still uses hand tuned assembly), the way Doom does things is definitely not the best way to utilize a modern processor. As kb1 said, some resolutions may be hard on the cache.Patrol1985 said:Intel graphics using good drivers The Intel drivers are WAY over rated on all platforms, but Linux especially. They get a lot of praise since Intel uses the open source driver as their official Linux driver and drive a lot of progress in mesa. But honestly I've had a far more stable experience with Catalyst and a slightly less better experience with nvidia's blob than the Intel driver on any Intel graphics computers I have. I run into really obvious bugs like image corruption while scrolling and my Thinkpad X61 Tablet has issues with font rendering every now and then. Plus, no matter which way you go with the Intel driver, the standards compliance tends to be out dated (OpenGL mostly). The biggest issue I've had with Catalyst is the mouse cursor getting corrupted on one screen, and I had that happen maybe once in the last two years now. 0 Share this post Link to post
Spleen Posted June 13, 2014 Patrol1985 said:It just puzzles me, because right now my AMD card performs even worse than my Intel integrated chip in a different netbook... and that's just... cruel! :D The problem isn't Linux. HD 8210 is just a really bad card. You somehow managed to find an AMD card that has significantly lower performance than the last-generation Intel graphics: http://www.notebookcheck.net/AMD-Radeon-HD-8210.93728.0.html http://www.notebookcheck.net/Intel-HD-Graphics-4000.69168.0.html 0 Share this post Link to post
Patrol1985 Posted June 13, 2014 Blzut3 said:Most of the software renderers are single threaded, so your issue is definitely your 1GHz clock rate. Although some ports have fairly optimized software renderers (ZDoom still uses hand tuned assembly), the way Doom does things is definitely not the best way to utilize a modern processor. As kb1 said, some resolutions may be hard on the cache. If they're single threaded then it certainly can be the clock rate :/. My other netbook has an Intel Atom N570 working at 2 x 1.66 GHz and Chocolate DOOM / PrBoom+ (8-bit mode) work like a charm there. Could someone explain to me then the comparison of my two CPUs displayed here: http://www.cpubenchmark.net/compare.php?cmp[]=1968&cmp[]=623 Despite a lower clock rate, the E1-2100 scored more points in the benchmark and I thought it meant it generally "performs" better. What should I make of the situation? Spleen said:The problem isn't Linux. HD 8210 is just a really bad card. You somehow managed to find an AMD card that has significantly lower performance than the last-generation Intel graphics: http://www.notebookcheck.net/AMD-Radeon-HD-8210.93728.0.html http://www.notebookcheck.net/Intel-HD-Graphics-4000.69168.0.html It's certainly worse than the last generation Intel graphics, but my other computer has Intel GMA 3150, which is beyond terrible. Even as weak a card as Radeon HD 8210 should absolutely trample the Intel I mentioned. I doubt the card has meaning here though. Like I said, OpenGL runs smoothly, it's the software rendering I have trouble with. 0 Share this post Link to post
Graf Zahl Posted June 13, 2014 Patrol1985 said:http://www.cpubenchmark.net/compare.php?cmp[]=1968&cmp[]=623 Despite a lower clock rate, the E1-2100 scored more points in the benchmark and I thought it meant it generally "performs" better. What should I make of the situation? That's completely irrelevant here. The only thing that really matters is how fast data can be transferred from CPU to GPU by your driver. 0 Share this post Link to post
KuriKai Posted June 13, 2014 Try using the open source amd radeon drivers. I find them to be much better than the closed source ones. better 2d performance also. https://launchpad.net/~oibaf/+archive/graphics-drivers/ 0 Share this post Link to post
Patrol1985 Posted June 13, 2014 Graf Zahl said:That's completely irrelevant here. The only thing that really matters is how fast data can be transferred from CPU to GPU by your driver. Does that mean it's a driver related issue or clock speed related issue? In other words: can the situation still improve with better drivers? Also, why does OpenGL work well? Is that because the GPU does its calculations so there is no need for the driver to transfer anything? Sorry for my technical ignorance:( KuriKai said:Try using the open source amd radeon drivers. I find them to be much better than the closed source ones. better 2d performance also. https://launchpad.net/~oibaf/+archive/graphics-drivers/ I will look into that and post about the results. Thanks! 0 Share this post Link to post
Graf Zahl Posted June 13, 2014 Patrol1985 said:Does that mean it's a driver related issue or clock speed related issue? In other words: can the situation still improve with better drivers? Also, why does OpenGL work well? Is that because the GPU does its calculations so there is no need for the driver to transfer anything? Sorry for my technical ignorance:( Since OpenGL itself works fine the problem must lie somewhere else. I somehow doubt it's the software renderer itself, especially with Chocolate Doom which renders to a 320x200 screen only. So that only leaves the data transfer. It can be the bus, it can be the driver, it's hard to tell. But 1GHz should be fast enough. Doom ports worked on far weaker hardware during the last 16 years. 0 Share this post Link to post
Blzut3 Posted June 13, 2014 Oh right, chocolate doom is having a problem. 1GHz should definitely be fast enough for that. The reason I mentioned the clock speed is since Doom's renderer isn't the most cache friendly and architecture improvements can be negated by having to fetch everything from memory. Although some of the newer processors have really good caches. But yeah, if you're having problems rendering at 320x200 the problem is elsewhere. One thing to try is check that you have all "tear free" or vsync options off on your desktop as that can sometimes interfere with screen updates from software rendered games. Especially since vsync on X is horribly implemented from what I understand. 0 Share this post Link to post
ducon Posted June 14, 2014 Patrol1985 said:AMD/nVidia graphics using weak drivers? Awesome... What? O_o The nVidia drivers are not weak. 0 Share this post Link to post
Patrol1985 Posted June 15, 2014 A small update: The problems I originally described occurred in Linux Mint 17 MATE edition. Since I prefer XFCE desktop, I decided to go back to Linux Mint 16, until LM17 XFCE gets released. LM16 uses an older set of proprietary drivers: fglrx version 2:13.101-0ubuntu3 With those drivers, software rendering is perfectly smooth, as it should be... but OpenGL crashes. When I switch PrBoom+ to OpenGL the game freezes (there is a solid black screen) and the terminal gives the following messages: X Error of failed request: GLXBadRenderRequest Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 921 Current serial number in output stream: 922 I_ShutdownSound: Does anyone know what it means? EDIT: Ok, I think I know everything now: 1. The above error comes from the fact that LATEST PROPRIETARY drivers for Linux Mint 16 don't support OpenGL 2.0 (WHAT... THE... HELL?!) 2. Latest open-source drivers for Linux Mint 16 support OpenGL 2.0, but the performance is HORRIBLE 3. Linux Mint 17 uses drivers which support required OpenGL standards and their performance is vastly improved (I could play Half-Life 1 smoothly, but Half-Life 2 stuttered). I think this applies both to open-source and proprietary drivers. However, it's with those drivers that software mode performance DROPPED for me when compared to latest drivers from the older linux distribution. Conclusion: Linux drivers for AMD cards truly suck. It seems that eventually they will be able to utilize full potential of given Radeon models, but not for now :/ 0 Share this post Link to post
KuriKai Posted June 15, 2014 What Linux kernel are you using? "uname -a" in a terminal to find out. You used the open source drivers from the ppa in the link i posted before? 0 Share this post Link to post
Patrol1985 Posted June 15, 2014 KuriKai said:You used the open source drivers from the ppa in the link i posted before? I did. They perform equally to default open source drivers suggested by the operating system. KuriKai said:What Linux kernel are you using? "uname -a" in a terminal to find out. My kernel version is: 3.11.0.12 I know that updating the kernel would help, because drivers written for 3.12 and up feature a significant boost. However, I'm not knowledgeable enough to upgrade the kernel myself and a new Linux distribution (with updated kernel and drivers) will be out probably in no more than 2 weeks, so I'll just wait. I'm just surprised at how linux drivers are behind windows drivers. I'm lucky because I have to wait only for about two weeks, but I might as well have bought this computer half a year ago and that would have been a long wait. With open source drivers, I can understand it, but it's ridiculous that proprietary drivers perform so poorly. OpenGL 2.0 not provided by the driver (even though the card supports 3 or 4 I believe)? In 2014?! Really?! 0 Share this post Link to post
KuriKai Posted June 15, 2014 You can follow this guide on how to install this stable version linux kernel. http://linuxg.net/how-to-install-kernel-3-14-6-on-ubuntu-linux-mint-and-their-derivative-systems/ There are also different posts telling you how to install different versions of the kernel http://linuxg.net/tag/kernel/ I use this guide along with the open source ppa drivers from oibaf 0 Share this post Link to post
Patrol1985 Posted June 15, 2014 I upgraded the kernel and packages with oibaf drivers. Unfortunately, the performance is the same as earlier. Nevertheless, I thank you for your help KuriKai! I appreciate you took time to answer my posts! Right now I'll just wait for the new distro and see how things develop there. 0 Share this post Link to post
fabian Posted June 16, 2014 Patrol1985 said:I upgraded the kernel and packages with oibaf drivers. Unfortunately, the performance is the same as earlier. Maybe you need some additional firmware for your GPU to work properly. What does "dmesg | grep -i firmware" say? 0 Share this post Link to post
Patrol1985 Posted June 16, 2014 fabian said:Maybe you need some additional firmware for your GPU to work properly. What does "dmesg | grep -i firmware" say? A lot of stuff which tells me nothing, but looks serious: [ 0.317535] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 0.348406] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness [ 0.348470] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness [ 0.350259] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness [ 0.350297] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness [ 0.404740] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge [ 2.718415] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness [ 13.552270] psmouse serio2: elantech: assuming hardware version 3 (with firmware version 0x550f00) 0 Share this post Link to post
fabian Posted June 16, 2014 Patrol1985 said:A lot of stuff which tells me nothing, but looks serious: Na, not serious, you might have problems setting your display brightness via software, that should be all. It doesn't complain about missing firmware, so you seem to have the "firmware-linux-nonfree" package installed. Can you confirm this? Which versions of the "libdrm-radeon1" and "libgl1-mesa-dri" packages do you have installed? Edit: Ah, and what does 'glxinfo | grep -i "direct rendering"' say? 0 Share this post Link to post
Patrol1985 Posted June 16, 2014 fabian said:Na, not serious, you might have problems setting your display brightness via software, that should be all. It doesn't complain about missing firmware, so you seem to have the "firmware-linux-nonfree" package installed. Can you confirm this? Which versions of the "libdrm-radeon1" and "libgl1-mesa-dri" packages do you have installed? I have a package called "firmware-linux" installed (there is no "nonfree" part). As for other package versions: ||/ Name Version Architecture Description +++-===========================================-==========================================-============-============================================================== ii libdrm-radeon1:amd64 2.4.54+git1405200630.8fc62c~gd~s amd64 Userspace interface to radeon-specific kernel DRM services -- runtime ii libdrm-radeon1:i386 2.4.54+git1405200630.8fc62c~gd~s i386 Userspace interface to radeon-specific kernel DRM services -- runtime ii libgl1-mesa-dri:amd64 10.3~git1406160730.5cb8fd~gd~s amd64 free implementation of the OpenGL API -- DRI modules rc libgl1-mesa-dri:i386 10.3~git1406131930.03aab2~gd~s i386 free implementation of the OpenGL API -- DRI modules fabian said:Edit: Ah, and what does 'glxinfo | grep -i "direct rendering"' say? it says: direct rendering: Yes 0 Share this post Link to post
fabian Posted June 16, 2014 Patrol1985 said:I have a package called "firmware-linux" installed (there is no "nonfree" part). This *might* be the reason for your poor graphics performance. Could you try to install that package? As for other package versions: These look recent enough. How about "xserver-xorg-video-radeon"? direct rendering: Yes Good! 0 Share this post Link to post
Patrol1985 Posted June 16, 2014 fabian said:This *might* be the reason for your poor graphics performance. Could you try to install that package? I installed it. Nothing has changed. fabian said:These look recent enough. How about "xserver-xorg-video-radeon"? Is that the one you meant?: ||/ Name Version Architecture Description +++-==============-============-============-================================= ii xserver-xorg-v 1:7.3.99+git amd64 X.Org X server -- AMD/ATI Radeon 0 Share this post Link to post
fabian Posted June 17, 2014 Patrol1985 said:I installed it. Nothing has changed. The firmware is requested at kernel module loading time, so it is easiest to reboot the system to trigger that change (but maybe you did that already). Is that the one you meant?: Software-wise your system appears well equipped. I am sorry I cannot tell you the reasons for your bad video performance. :/ 0 Share this post Link to post
Patrol1985 Posted June 17, 2014 fabian said:The firmware is requested at kernel module loading time, so it is easiest to reboot the system to trigger that change (but maybe you did that already). Yes, I did. fabian said:Software-wise your system appears well equipped. I am sorry I cannot tell you the reasons for your bad video performance. :/ That's ok, I appreciate all the time you took to help me. Thanks! Linux Mint 17 XFCE RC was released yesterday, so in 2 weeks time the official release should be available and I know OpenGL will run faster (but software mode may suffer). We'll see. 0 Share this post Link to post