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

Software renderer in source ports

Recommended Posts

Running a compositor (like xcompmgr or compiz) can dramatically slow performance. It could be the reason why some drivers are working differently than others. I found a couple pages on disabling the compositor on Linux Mint on Google; try that and see if it helps.

Also, make sure that you're using a low resolution that should definitely be fast during testing, like 640x480. You can bump it up later once you get a working solution.

Your video card will have practically no effect on your framerate in software mode. Like Graf Zahl said, the only thing that matters is how fast your CPU can send data to your GPU; but your GPU doesn't then do any rendering; it just passes it to your display. Sometimes some GPUs can provide "hardware surfaces" but this kind of thing is hit-and-miss, especially in SDL (which is what Choco and Pr+ use).

Which is all to say that your "slow" GPU isn't a problem, but a bad configuration probably is. Get the latest AMD driver from their site (the latest version is 14.4 and it supports up to OpenGL 4.4) and see if that solves your problem. Most people who use AMD/NVidia cards are used to using the drivers straight from the site and not from package managers because package managers are hopelessly out of date on everything, and this really hurts graphics drivers.

Finally, PrBoom+ can be configured to not use OpenGL 2.0 features (it should automatically detect stuff like that, but drivers can lie). Off the top of my head I can't tell you which GL options to disable, but you can mess with it.

Good luck!

Share this post


Link to post
Ladna said:

Get the latest AMD driver from their site (the latest version is 14.4 and it supports up to OpenGL 4.4) and see if that solves your problem.


Unfortunately it doesn't, because I just end up with a black screen or x start failure and I have to restore my xorg.conf etc. Official Linux Mint forums explicitly warn against downloading the lastest drivers from their authors' websites because an error might occur like the one I experienced. They advise to use only those drivers which are offered in repositories and they're correct in saying that they work right. So I'm stuck with whatever they offer until the next distro version gets released :/

Thanks for your advice!

Share this post


Link to post

I run Slackware Linux with nvidia and matrox cards.

The normal Doom behavior is to write to a framebuffer and then transfer the framebuffer to the video card. Very fast, even on a 100Mhz machine.
On modern machines things got more complicated because they rarely use 8bit paletted colors. So, usually some software, somewhere, is converting that 8bit color framebuffer to 32 bit RGB for the graphics card.

Worse, they may buffer it again, and if video memory is tight they have to move something to main memory to do it. Turn off double buffering when the hardware is already adequately buffering (probably a code edit).

Try some of the video switches on PrBoom to draw directly in the native bpp.

DoomLegacy has a switch (-native) to select the software renderer that draws directly in the native bpp of the video card. Otherwise you can directly try each of the drawers ( 8bit, 15bit, 16bit, 24bit, 32bit) to see if one of them is fast.

If OpenGL is not supported by your card, then SDL will fall back to emulating it in software, which is really slow. It sounds like the same thing your software renderer is encountering, some slow software conversion of a mismatch with the hardware. In windowed mode I would suspect a compositor or emulator is converting your Doom output to the video card mode that selected. Do you have differences in speed between windowed and fullscreen draw modes ?

OpenGL uses the driver code to draw. Part of the driver is the OpenGL support for the video card. This MUST be matched to the driver. On Linux, leaving an opengl support library around from a previous driver is an invitation to OpenGL crashes. Read your installation instructions carefully concerning removing the old opengl library.

Share this post


Link to post

The funny thing is that different driver versions have different problems on my machine.

Linux Mint 16 drivers = good software mode, but bad OpenGL mode.

Linux Mint 17 drivers = bad software mode, but good OpenGL mode.

They (driver programmers) obviously can get it right for both modes, I wonder why they don't :/

Share this post


Link to post
Patrol1985 said:

They (driver programmers) obviously can get it right for both modes, I wonder why they don't :/

Because the combination of Kernel + X + mesa you might be using is a very rapidly moving target.

Share this post


Link to post
Patrol1985 said:

Meaning that each is developed independently and thus they may not work together well?

More like, it's hard to develop an integral part of the system (graphics driver) when you cannot be sure what other integral parts of the system (kernel, display server, OpenGL implementation) are. There are just too many distributions out there and you simply cannot support them all - especially as a third-party vendor. It is thus usually best advice to use your distribution's packages, because they are known to work with the combination of other packages. However, sometimes that means you have to stick to outdated versions and may lose some features that only newer versions provide.

Share this post


Link to post
fabian said:

Because the combination of Kernel + X + mesa you might be using is a very rapidly moving target.


What fabian said. Mesa in version 7.5 removed all of the old drivers (3dfx/Matrox/older ATI cards) and switched to a new driver framework (Gallium) for the cards that they still do support (newer ATI/NVidia/VMware/Intel), so if you have version 7.x or 8.x of the Mesa 3D libs in your distro, expect some things to be broken. Debian Wheezy (7.x) comes with Mesa version 8.0.5, and the ATI drivers in that version work in software render mode only, but the NVidia drivers are hardware accelerated.

Like you said, you're probably going to have to wait until your distro updates, since they are the ones doing all of the testing of combinations of Linux kernel + X + Mesa. Or you can compile latest Mesa and be your own guinea pig ;)

List of currently supported cards in Mesa: http://mesa3d.sourceforge.net/systems.html

Share this post


Link to post

I could see it being tough to develop a video driver, especially if you're testing it on your development box. Especially if a bug makes your display un-viewable :)

Share this post


Link to post
fabian said:

Ah, and what does 'glxinfo | grep -i "direct rendering"' say?


I'll return to this fragment once again. Even though the output is:

Direct rendering: yes

When I try to run Steam I get an error saying:

"OpenGL GLX context is not using direct rendering"

So maybe it's not running after all? I'm confused :(

Share this post


Link to post
Patrol1985 said:

I'll return to this fragment once again. Even though the output is:

Direct rendering: yes

When I try to run Steam I get an error saying:

"OpenGL GLX context is not using direct rendering"

So maybe it's not running after all? I'm confused :(


https://github.com/ValveSoftware/steam-runtime/issues/13
Follow the instructions on that page, that will fix your steam glx issue, it's a bug in the steam runtime

Read over that bug report first to find the fix and to make sure that it's the same bug you have with steam

Share this post


Link to post

Do you try different drawing bpp in prboom or Legacy, to see if one of them will bypass the software rendering driver problem ?

How about the SYNC vrs drawing without SYNC ?


Download the Phoronix test suite phoronix-test-suite.com/ and give it a try.
One of the tests may point more directly to something specific.
It has several tests for graphics and gaming.

Share this post


Link to post
wesleyjohnson said:

Do you try different drawing bpp in prboom or Legacy, to see if one of them will bypass the software rendering driver problem ?

How about the SYNC vrs drawing without SYNC ?


Download the Phoronix test suite phoronix-test-suite.com/ and give it a try.
One of the tests may point more directly to something specific.
It has several tests for graphics and gaming.


Thanks! I didn't know about this tool. It offers a very wide variety of tests. Are there any particular I should run which would indicate where the problem may be?

As for SYNC and bpp, I haven't tried changing those yet. I will though.

Share this post


Link to post

I have got it but have not had time to try it out yet. I will have to before trying some other video cards. Got other downloaded software to fight with right now.

If you were testing with DoomLegacy this would be easier because it has many drawing options and because I rewrote the entire framebuffer rendering so I know what it does and what hardware interactions might be happening. The linux-X port specifically has some 8bit to other bpp conversions that are run when the X-window is not 8bit (which now is just about always). It used to be the standard to double buffer, but it may not be needed anymore because so many drivers do it already and video memory is tight. If the driver must swap framebuffers out of video memory, that alone would be a speed killer.
Using the -native switch lets it detect the native resolution and draw directly in it. This might have a dramatic impact and that would tell us something. Trying -bpp15 might do something different too, worse or better, or the same.

There is an SDL DoomLegacy and one that draws directly in X-windows.
That would be a big test too.

Need more variety of tests, on the one particular driver that is software slow.

With the driver that is OpenGL slow, the problem is going to be determined by the OpenGL library. MESA is software and is slow. The hardware accelerated OpenGL must match the card by having the right proprietary driver. The Nouveau driver is better on some cards than others. Even there, the SDL OpenGL (DoomLegacy SDL) may perform differently than the X-windows OpenGL (DoomLegacy X-window).

Share this post


Link to post
wesleyjohnson said:

MESA is software and is slow.

MESA *does* have hardware drivers

  • for the most common systems:
    http://mesa3d.org/systems.html

    It's not 1999 anymore...

    Edit:
  • drivers making use of hardware acceleration, that is

  • Share this post


    Link to post

    UPDATE! :D

    Linux Mint 17 XFCE got released recently so I updated my system and fortunately received some nice performance gains. I also disabled display compositing per your suggestion.

    Right now I'm using an open-source driver suggested by the system, namely: xserver-xorg-video-ati ver. 1:7.3.0-1ubuntu3.1 which gives me the following numbers.

    I used -timedemo demo1 to obtain these:

    1. Chocolate Doom 2.0.0, 800x600 = 67 FPS*

    2. PrBoom-plus 2.5.1.4.test, 8-bit, 800x600 = 52 FPS**

    3. PrBoom-plus 2.5.1.4.test, OpenGL, 800x600 = 79 FPS***

    Those are some sweet results and they allow me to play Doom the way I want.

    However, I still think the card is capable of better performance. For instance, the very first Half-Life works at about only 15 FPS.

    There is something peculiar I noticed - the system's GUI seems to have problems with rendering each frame. A slight lag occurs as I can see each frame being drawn from top to bottom whenever I open or close a window. Same goes for the menu - before it appears I can see a "loading" icon for a couple of seconds. Neither of those occurred under Linux Mint 16, so I assume some feature got added, which causes the lag and it may hinder the performance in general. The above is true for both MATE and XFCE desktops.

    Does anyone have any ideas what it might be?

    *Chocolate Doom uses no uncapped framerate, so I assume this means constant 35 FPS

    **uncapped framerate, no vsync, the rest of graphical settings were default

    ***same as above, but OpenGL

    Share this post


    Link to post

    I knew as I was typing, that someone would be replying that MESA does have hardware rendering, or something like that.

    I cannot get phoronix to do any tests here because it wants an internet connection and my working machine is off-internet. Much frustration there.

    Opening or closing a window causes the window manager to ask every window to refresh its graphics. All you need there is one window that is slow to respond. You may have some new option turned on, or some background process that has a desktop icon that updates itself as a status. Even a running music player on the status bar can have effects.
    Some of those will not shutdown when closed, they just minimalize and sit on the lower bar.

    Share this post


    Link to post
    wesleyjohnson said:

    You may have some new option turned on, or some background process that has a desktop icon that updates itself as a status. Even a running music player on the status bar can have effects.
    Some of those will not shutdown when closed, they just minimalize and sit on the lower bar.


    That's what I think as well, but I don't know how to identify this background process.

    Share this post


    Link to post

    Hmm, I'm not sure if this helps, but a friends of mine runs linux and uses Odamex. If you're just looking for the software render to run smoothly, hopefully this will work for you. It's possible to set things to compatibility mode, if you're looking for a vanilla experience.

    Share this post


    Link to post

    Doom works fine now, both software and OpenGL. I'd be more happy knowing that my computer can render both in at least 60 FPS, but there is nothing about the current performance I can complain about.

    Now I'd like to remove all other stuff which hinders my system's performance.

    Share this post


    Link to post
    Patrol1985 said:

    That's what I think as well, but I don't know how to identify this background process.


    As a first check you can run the "top" command in a terminal window which will show a self-updating list of processes ordered by CPU time consumption. Press 'q' to close the list again.

    Share this post


    Link to post
    fabian said:

    As a first check you can run the "top" command in a terminal window which will show a self-updating list of processes ordered by CPU time consumption. Press 'q' to close the list again.


    Thanks! Unfortunately, the most consuming process is xorg... which is kinda necessary :P

    I guess all that could have been done, has been done. Thanks everyone for your input!

    Share this post


    Link to post

    Akonadi is my favorite to turn off (system settings).

    To see all processes in a useful way
    >> ps -A

    This lists all processes in order they were created (by their process number). Those created before the KDE or window manager stuff is not windows related. Those near the end are your latest processes.
    Stuff that says KDE are usually one of the KDE subsystems. Even xfce4 uses much of the KDE runtime, it just uses the xfce4 window manager.

    Look for something that would have a window.

    Look for things hanging around on the bottom bar, often in the lower right corner. They almost always have a handle there to access them.
    Just open them one at a time until you find something you don't like.

    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
    ×