Page MenuHome

Nvidia GT 430: Poor frame rate with Anti-aliasing set to single pass
Closed, InvalidPublic

Description

System Information
Operating system: Void Linux
Graphics card: Galaxy Nvidia GT 430 1GB (GL 4.6 supported by driver 390.116)

Blender Version
Broken: (public download) 2.80 (sub 75) branch: master, commit date: 2019-7-29 14:47, hash f6cb5f54494e, type: Release
Worked: 2.79b

Short description of error
0.5FPS in all windows

Exact steps for others to reproduce the error
Based on the default startup or an attached .blend file (as simple as possible).
1: start Blender 2.8.0
2: configure preferences and set Anti-aliasing to single pass (disabling doesn't affect anything)
3: set texture management to GLSL
4: do whatever, even the preferences window displays at this framerate.

step 2 boosted the FPS from 1.5 to 0.5
step 3 doesn't seem to have done anything

my card can handle minor anti-aliasing, in fact I'm even using it in 2.79b at more than 50FPS with the default scene

my guess is poor frame-loop optimization, which I'm rather disappointed would make it into a release.

Event Timeline

Cannot reproduce here (linux, 970m, 430.26 drivers).
Seems like that driver is the last one provided for your card.
Not sure if there is anything we can do here...

Philipp Oeser (lichtwerk) renamed this task from Poor frame rate to Nvidia GT 430: Poor frame rate with Anti-aliasing set to single pass.Sep 12 2019, 10:07 AM

Not sure if there is anything we can do here...

I'm fairly certain my issue is not with my driver, or I'd likely be having issues with running anything at all
Xonotic, RedEclipse, and Minetest run just fine (above 50FPS) with the detail set fairly high.

also I can't quite agree with the issue rename, but I'll leave it
it's stated in the issue that even disabling anti-aliasing makes no change from 0.5FPS

check your frame loop for anything that might be using CPU
CPU use does spike to about 80% when I simply rotate the default scene
when idling CPU use is about 10%

in 2.79b this CPU spike doesn't happen

You did not mention what CPU you have, how much ram. CPU Spike could be happening with libraries that are needed by Blender, but your distro have problem with them. Do you have another PC with another Linux version to check?

Tcll 5850 (Tcll) added a comment.EditedSep 27 2019, 1:39 AM

the reason I didn't give my specs was because I don't believe they are the problem
be warned though, my PCs are anything but powerful (that said though, it's not the reason for Blender's poor performance)

it's possible though a library could be causing the CPU spike if that's what's going on.

but anyways, here's my specs:
CPU: x64 Intel Pentium 4 3.5GHz with hyperthreading enabled
RAM: 3.5GB (8GB installed) DDR2
GPU: Galaxy Nvidia GeForce GT 430 1GB PCIe1 on nvidia-390.116

I do have another compact machine: (the only machine on internet currently)
CPU: x64 Intel Atom D2550 1.83GHz with hyperthreading disabled
RAM: 2.0GB DDR3 SO-DIMM
GPU: onboard Nvidia GeForce GT 610 PCIe1 on nvidia-384.130
OS: Xubuntu 16.04 latest updates

after testing the same version (literally copied from my Void install)
it appears there's no frame issues on this machine (my Atom)
looks like the library assumption might be correct :)
any ideas as to what library I might need to copy??
yes I intend to overwrite the bad library if possible

in the meantime if I may request another solution to this library issue
May I request an appimage release to guarantee the release works just as well for everyone else? :)
(the needed libraries are bundled, which is why it's guaranteed to work, just download and run like a portable executable)

Thanks for the info about your hardware. I'm not totally sure, but Blender might use some CPU extensions that are not supported by the old Pentium 4 (Like SSE), but are present on the newer Intel Atom.

Not that the CPU is bad, but Blender might try to use theses extension. As I mentionned, it's only a hint, not 100% sure.

Can you replace the CPU with a CORE2DUO? There might be some that are pin compatible with the old P4 and might have the required CPU extension.

Theses extension make it faster to do math, or other task, when theses are not available, some system might switch back on software (lib) and be very slow. This could explain the spike.

unfortunately, this PC was passed down to me, and is only a temporary replacement for my Athlon II that died a while back
I can't (nor have been able to) afford any sort of upgrade in my current position

you're probably right on that guess though if you were able to roughly pinpoint the issue before even knowing my hardware... heh
so I can see how an appimage might not even work there

but there's also the case of Blender27 working just fine
could that functionality be added to Blender28??
perhaps turning EEVEE into something like Blender27's Material view for older hardware
I'm not asking for automated detection, a simple toggle or selection box in the options will do
I'm probably not the only one who'd benefit from this :)

Unfortunately, If I'm not wrong, this are compiler directives to build using theses CPU extensions.
The only way I would know is to modify the code to not use the extensions your CPU is not supporting (still a guess, I'm not sure the developper uses theses extension, but it would made sense as it accelerate lots of things)

Checked the requirement for CPU for Blender and they are using SSE2:

32-bit dual core 2Ghz CPU with SSE2 support.

And the Pentium 4 you have seem to support it. There must be something else, but I'm about sure this has something to do with the CPU. Unless the developper used new extensions like AVX and did not update the site.

Since your other PC run XUbuntu there still might be a chance there is something with the distro. If you can have access to a spare hdd, install Xubuntu on it and try Blender again (with all hardware drivers installed)

Tcll 5850 (Tcll) added a comment.EditedSep 27 2019, 2:42 PM

interesting, yeah I don't really know my CPU too well since I don't really care about it too much (I shouldn't have to anyways from a user perspective)
I don't really like Intel since they don't seem to apply common sense to their CPU architecture, overpricing aside...

I'm sure though there are other ways to support the tech other than just using compiler directives :/
granted I'm not much into compiled languages yet, or I'd explain how...
I'm still stuck on python34 for my projects... heh
why?
for the exact same reason we're having this compatibility discussion (py34 was the last version of python to support WinXP, and works on Win10)
I want to make sure my projects support systems that date all the way back to the Win2000 days, while also supporting modern hardware.
once I can compile my own portable interpreters, I'll be able to upgrade to a later python version. (I'm accepting my current losses for broader support)

this drive is why I'm pushing for compatibility in Blender rather than simply digging in the trash for a hopeful Core2Duo score.
(I don't get to see my monthly income, and have more important things to worry about with life than upgrading my hardware)

I can understand you. I don't have much income too. If you can do it, you could try to install XUbuntu on this old PC just to be sure it's not related to the distro, since your other PC run fine on this distro. If you install XUbuntu and there is no issue, the you will know it's something in your distro, if it's still persist in the problem then we will have a confirmation that it's hardware related.

actually you just reminded me
while I've destroyed everything from Xubuntu because systemd and lightdm are insecure
I do have a roughly updated xubuntu installation as a way to recover my void installation if something should happen
(I wasn't sure how good Void would be as a recovery OS at the time I set things up...)

giving that a test, yep that works perfectly
though I'm not using the nvidia driver on my recovery OS, so I'm not sure if it's because of nouveau
that said though, if the nvidia driver works fine on my Atom, I'm willing to set that test aside in favor of an issue with Void,
due to Void not being as highly maintained as other major distros (a sacrifice I was willing to make for better security)

looks like an appimage might just work after all :)
adding to my earlier request though, given this new knowledge, it might actually be necessary to release an appimage.

Richard Antalik (ISS) closed this task as Invalid.Jan 11 2020, 12:03 AM
Richard Antalik (ISS) claimed this task.

Thanks for your report.

This seems to be system issue after all, so I will close this report.

Does that mean an appimage is in the works like the issue requested??
I don't see an appimage download on the page :/

I was also never given a hint as to what library blender uses that's broken in Void Linux so I could manually repair the issue if possible.

I would prefer not to have to drop Void Linux just to be able to use blender 2.8

I know there's a bum library in Void linux, but I can't use Blender until:
1: I know the name of the library I need to segregate from my system
2: there's an available appimage that wraps the library for me

What's been done since this issue was last addressed?? :/

This report was closed, is because it doesn't describe bug in Blender.

I am not familiar with latest linux app distribution systems, but if I am not mistaken we provide only one type of package for all linux paltforms.
That said, if special package needs to be created for whatever reason, it is up to the maintainers of the distribution itself.

I am pretty sure there are methods for creating packed version of software, so you can build appimage on system that works and try it on your distribution. There is still possibility, that this won't resolve your problem.

I think that consulting this problem on forum with people that are familiar with this distribution will be more productive.

oof with that elitist "build it yourself" attitude
the linux community is more mature that that, and that's not to be expected of the general user, come on guys. :/

and appimage is not a binary package distribution system
there is NO linux distribution associated with the appimage portable software format

I understand it was closed because it doesn't specifically relate to Blender...
but it's also an issue the blender devs can fix by releasing an appimage binary that can be run on any linux distro,
or by telling me what library blender uses that I can fix in my preferred distro myself.

you guys are the app developers
I'm conversing with you because the developers of Void Linux don't have the knowledge of what libraries the latest Blender binary uses
they only know what dependencies are used by the XBPS package they would provide.

stop making FOSS apps and your software look bad and answer me one of the 2 above questions please.

just wanted to update 2.81a downloaded as tar.bz2 just now (no appimage binary)
same issue as previous

if you guys don't wanna tell me what library might be the cause of such poor frame rate
then at least tell me a simple solution that could help me figure it out
cause so far you guys haven't been constructive, and I'm rather disappointed with your service (and so are others)

also I want to note

but if I am not mistaken we provide only one type of package for all linux paltforms.

actually you provide 2, and a poor choice for the 2nd IMO
appimage is a better choice than snap or flatpak (IMO)
and flatpak is a better choice than snap (fact)

the reason appimage is opinionated to be the best is because auto-updating isn't as managed in most cases as others would prefer...
but that's how I prefer it, and usually have multiple appimages of different versions of the same app on a separate HDD that I can run directly
(if I want to update, I'll just manually delete the old appimage and paste the new in it's place)

the difference between tar.bz2 and appimage is you can't run a tar.bz2

you guys could just fix the issue I'm having by bundling the unknown offending library with an appimage
since the unknown library is what's breaking things and forcing me to stay on 2.79b

solutions:
1: tell me what library Blender requires that could possibly be broken
2: tell me a good method I can use to figure out what library is broken
3: provide that library within a self-contained appimage

this issue is not solved yet and should not be closed

solutions 1 and 2 I can repair myself
solution 3 is to be provided by the blender devs

personally I'd prefer it if you replaced the snap download with an appimage download
fanboys can flame me all they want, I'm glad I don't have auto-updating or I wouldn't be able to use Blender.

@Tcll 5850 (Tcll) Sorry, I disscussed this off tracker, so I assumed you gots some response from us.

1: tell me what library Blender requires that could possibly be broken
2: tell me a good method I can use to figure out what library is broken

You could build Blender from sources following https://wiki.blender.org/wiki/Building_Blender/Linux
I think that you should follow Portable Builds secion specifically. However reading that section already implies, that official Linux releases are portable already.
This may not tell you which library is "broken" but it should tell you IF any library is broken.

@Bastien Montagne (mont29) can you give any statement on official appimage builds, if there is planned support?

@Bastien Montagne (mont29) can you give any statement on official appimage builds, if there is planned support?

@Richard Antalik (ISS) not sure why you ping me here, I’m not exactly deeply involved in releases currently… Think that I’ll pass on the mic to @Nathan Letwory (jesterking), our release manager. ;)

Tcll 5850 (Tcll) added a comment.EditedFeb 4 2020, 6:25 PM

@Richard Antalik (ISS) thanks for a better response :)

I followed the portable builds section which just informed me to check the make deps in CMakeLists.txt here:
https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/CMakeLists.txt
what's annoying about this is it's not in an easy to read format, but at least I understand a bit about C/++ to be able to make this out...
also white text on a white BG is pretty annoying to read btw (dark theme) ;)

reading through this though, it's pretty difficult to pinpoint what exactly could be causing it as almost everything here uses system-level binaries
SDL, OpenAL, GLFW, and all the smaller dependencies for png, ffmpeg, zlib, etc can all be bundled (I'm doing this with my python program)
but stuff like xvidcore, and I'm not sure what else cannot

if the portable stuff was bundled, I could probably pinpoint it to xvidcore since that relies on xorg
which Void's nvidia driver builds could be a possible cause of this issue

but I was hoping you guys might know of a possible CheatEngine solution that could scan my system to figure out the broken lib
also, sorry for sounding like I was demanding, now that I see that, I'm glad you only took it like the suggestion it was meant to be :)

also regarding this bit:

However reading that section already implies, that official Linux releases are portable already.

technically that's not wrong as the tar.gz package should be able to run on almost any linux distro...
and that's especially true for the windows build if all those portable .dll binaries are still included
(I say "if" because I haven't used Windows since my last XP64 installation killed itself (NTFS corruption) in 2012, so I wouldn't know)
but the countering bit here is what's included in the CMakeLists.txt who's portable .so binaries are not included in the tar.gz
heck for all I know, my problem could be caused by Void's build of SDL

this is exactly why I package these portable binaries with my python program :)
(I'm actually going an extra mile and working on loading dll and so binaries from zip archives without extraction to make portable distribution even easier)
and this can be done in both the tar.gz, and the appimage if you release that
if doing this doesn't fix my issue, then at least I know I can pinpoint it if the portable binaries are included.

broken OS binaries is something I've grown fond of since 2013, which is about when I started working on a portable python interpreter for my program
(I started with Portable Python for 2.7 and moved to Anaconda for 3.4)
^ I'm gonna have to learn to compile my own interpreters if I want to move to 3.5+ because I still use WinXP for testing. :P

so yeah, just a few notes there
hopefully the issue is caused simply from not including the portable binaries
the only system binaries that should be relied on should be core binaries related directly to the OS itself, for example xorg (xvidcore)

EDIT:

heck for all I know, my problem could be caused by Void's build of SDL

actually now that I think of it, this could actually be the case, as I remember RedEclipse being unplayable with a similar issue...
though I'm not sure if that was running on SDL or GLX as it's been a few years, and playing it now doesn't have the issue.