Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Patrol1985

Software renderer in source ports

Recommended Posts

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

Share this post


Link to post

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?

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

So Linux users are stuck either with weak Intel graphics using good drivers, or AMD/nVidia graphics using weak drivers? Awesome...

Share this post


Link to post

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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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!

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
Patrol1985 said:

AMD/nVidia graphics using weak drivers? Awesome...


What? O_o
The nVidia drivers are not weak.

Share this post


Link to post

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 :/

Share this post


Link to post

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?

Share this post


Link to post
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?!

Share this post


Link to post

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.

Share this post


Link to post
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?

Share this post


Link to post
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)

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post
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!

Share this post


Link to post
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

Share this post


Link to post
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. :/

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×