Inconsistent rendering experience on SoC Computer, Intel HD Graphics card #86234

New Issue

Abnilson Rafael · 2021-03-03T15:29:53+01:00

Abnilson Rafael commented

2021-03-03 15:29:53 +01:00

System Information
Operating system: Ubuntu 20.10
Graphics card: Intel HD Graphics 400

Blender Version
Broken: 2.92, 02948a2cab, master, 2021-02-24 16:25
Worked: 2.80

Short description of error

Blender is slow, even when rendering simple objects using Eevee render engine, which was supposed to be lightweight. And strangest thing, there's still a good amount of system resources left. I know that my PC is low-end, but I believe that it can produce at least things with remarkable quality. And sometimes, it renders incorrectly some objects:

In case above, I was trying to add simple hair particle to Suzanne. I know 4.0m it's little too long, but the result isn't normal either. But I reduced the hair length to 0.02m to fast fix.

Steps to Reproduce:

Just open the blend file I've uploaded
Go to rendering viewport, using Eevee or Cycles engine

AnotherTest.blend

**System Information** Operating system: Ubuntu 20.10 Graphics card: Intel HD Graphics 400 **Blender Version** Broken: 2.92, 02948a2cab44, master, 2021-02-24 16:25 Worked: 2.80 **Short description of error** Blender is slow, even when rendering simple objects using Eevee render engine, which was supposed to be lightweight. And strangest thing, there's still a good amount of system resources left. I know that my PC is low-end, but I believe that it can produce at least things with remarkable quality. And sometimes, it renders incorrectly some objects: ![Screenshot from 2021-03-03 14-57-06.png](https://archive.blender.org/developer/F9862681/Screenshot_from_2021-03-03_14-57-06.png) In case above, I was trying to add simple hair particle to Suzanne. I know 4.0m it's little too long, but the result isn't normal either. But I reduced the hair length to 0.02m to fast fix. **Steps to Reproduce:** 1. Just open the blend file I've uploaded 2. Go to rendering viewport, using Eevee or Cycles engine [AnotherTest.blend](https://archive.blender.org/developer/F9862701/AnotherTest.blend)

Abnilson Rafael commented

2021-03-03 15:29:53 +01:00

Added subscriber: @UltraBurstXD

Abnilson Rafael changed title from ~~Inconsistent rendering experience on SoC with Intel HD card~~ to Inconsistent rendering experience on SoC Computer, Intel HD Graphics card

2021-03-03 16:40:01 +01:00

Will commented

2021-03-03 16:53:37 +01:00

Added subscriber: @WCN

Will commented

2021-03-03 16:53:37 +01:00

What is the specific problem, and expected behaviour? "Slow" on its own is vague, subjective, and a product of many factors, including hardware. Is it, E.G., 50% slower than it was in the last version? Or is it just "slow"? "Remarkable quality" isn't really related to speed. "Incorrectly" is also vague, unless you specify in what actual way it's incorrect.

The attached screenshot looks about right for 4BU hair particles on a 0.5BU object with lots of concavities/varied normals— You asked for hair particles that are almost ten times longer than the shortest dimension of the Suzanne and that's what you got, and they'll go all over the place at first because Suzanne's normals point all over the place. The attached file doesn't seem to include the behaviour either, making it impossible to check.

I think checking on system resources can be misleading for an OpenGL rasterizer like EEVEE, because most tools don't report GPU utilisation— Your GPU could be at 100% and using up all the (shared) VRAM it's allowed to, but your CPU, RAM, etc use could show as being at idle.

If the problem is only about subjective speed, then think about it this way: EEVEE is built using the same kinds of technologies that video game engines use, and Cycles is built using technologies that produce much more accurate results but are also many times slower. If you can't play new games on "Ultra" settings on your PC, then why would you expect to get smooth performance from a rendering engine using the same technologies? And I say this as someone who also uses an Intel GPU most of the time; since rendering isn't the biggest or most time-sensitive use of Blender for me, the lower speed that comes with this hardware is a reasonable trade-off that I accept.

Disclaimer: Am not a Blender developer.

What is the specific problem, and expected behaviour? "Slow" on its own is vague, subjective, and a product of many factors, including hardware. Is it, E.G., 50% slower than it was in the last version? Or is it just "slow"? "Remarkable quality" isn't really related to speed. "Incorrectly" is also vague, unless you specify in what actual way it's incorrect. The attached screenshot looks about right for 4BU hair particles on a 0.5BU object with lots of concavities/varied normals— You asked for hair particles that are almost ten times longer than the shortest dimension of the Suzanne and that's what you got, and they'll go all over the place at first because Suzanne's normals point all over the place. The attached file doesn't seem to include the behaviour either, making it impossible to check. I think checking on system resources can be misleading for an OpenGL rasterizer like EEVEE, because most tools don't report GPU utilisation— Your GPU could be at 100% and using up all the (shared) VRAM it's allowed to, but your CPU, RAM, etc use could show as being at idle. If the problem is only about subjective speed, then think about it this way: EEVEE is built using the same kinds of technologies that video game engines use, and Cycles is built using technologies that produce much more accurate results but are also many times slower. If you can't play new games on "Ultra" settings on your PC, then why would you expect to get smooth performance from a rendering engine using the same technologies? And I say this as someone who also uses an Intel GPU most of the time; since rendering isn't the biggest or most time-sensitive use of Blender for me, the lower speed that comes with this hardware is a reasonable trade-off that I accept. Disclaimer: Am not a Blender developer.

Robert Guetzkow commented

2021-03-03 16:56:55 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2021-03-03 16:56:55 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Robert Guetzkow commented

2021-03-03 16:56:55 +01:00

It seems you have already asked about this on Blender's Stack Exchange, but the question has since been deleted. While we always try to improve the performance of Blender, potential performance improvements are not handled as bug reports. That is unless they are performance regressions, meaning it worked significantly faster in a previous version of Blender. In particular using Cycles as render engine and trying to preview a scene with hair particles in rendered mode will not be instantaneous. It takes time to render the individual samples. Eevee should be significantly faster, but how fast will also depend on the hardware.

I could not find any issue with your project file. Please try to provide us with a precise use case where current versions of Blender perform worse, if you believe that you're experiencing a performance regression, otherwise we will have to close the ticket.

It seems you have already asked about this on Blender's Stack Exchange, but the question has since been deleted. While we always try to improve the performance of Blender, potential performance improvements are not handled as bug reports. That is unless they are performance regressions, meaning it worked significantly faster in a previous version of Blender. In particular using Cycles as render engine and trying to preview a scene with hair particles in rendered mode will not be instantaneous. It takes time to render the individual samples. Eevee should be significantly faster, but how fast will also depend on the hardware. I could not find any issue with your project file. Please try to provide us with a precise use case where current versions of Blender perform worse, if you believe that you're experiencing a performance regression, otherwise we will have to close the ticket.

Abnilson Rafael commented

2021-03-03 17:16:39 +01:00

In #86234#1123400, @WCN wrote:
What is the specific problem, and expected behaviour? "Slow" on its own is vague, subjective, and a product of many factors, including hardware. Is it, E.G., 50% slower than it was in the last version? Or is it just "slow"? "Remarkable quality" isn't really related to speed. "Incorrectly" is also vague, unless you specify in what actual way it's incorrect.

I don't know for sure, I used Blender 2.80 a long time ago and it seemed more faster. "Remarkable quality" for me means a good or specifically normal quality, neither good or bad.

The attached screenshot looks about right for 4BU hair particles on a 0.5BU object with lots of concavities/varied normals— You asked for hair particles that are almost ten times longer than the shortest dimension of the Suzanne and that's what you got, and they'll go all over the place at first because Suzanne's normals point all over the place. The attached file doesn't seem to include the behaviour either, making it impossible to check.

The main problem was related to speed, because the object is simple and I was using Eevee to render instead of Cycles. It's very expensive to me to use Cycles most of time. I think I'll use it, only when necessary. About particle length I corrected it by reducing some meters. I reduced Suzanne size to fit that place, in my tests with it's original (default) size, same thing was happening too.

I think checking on system resources can be misleading for an OpenGL rasterizer like EEVEE, because most tools don't report GPU utilisation— Your GPU could be at 100% and using up all the (shared) VRAM it's allowed to, but your CPU, RAM, etc use could show as being at idle.

If the problem is only about subjective speed, then think about it this way: EEVEE is built using the same kinds of technologies that video game engines use, and Cycles is built using technologies that produce much more accurate results but are also many times slower. If you can't play new games on "Ultra" settings on your PC, then why would you expect to get smooth performance from a rendering engine using the same technologies? And I say this as someone who also uses an Intel GPU most of the time; since rendering isn't the biggest or most time-sensitive use of Blender for me, the lower speed that comes with this hardware is a reasonable trade-off that I accept.

We can't compare games to modelling/sculpting an object. But in terms of quality, maybe is right to assume that. Some designers/artists render things separately to go ease on PC's resources. We all know that games are very interactive, and multiple objects with incredible quality are rendered in same time. And most were rendered using specific dedicated GPU cards technology (instruction set).

> In #86234#1123400, @WCN wrote: > What is the specific problem, and expected behaviour? "Slow" on its own is vague, subjective, and a product of many factors, including hardware. Is it, E.G., 50% slower than it was in the last version? Or is it just "slow"? "Remarkable quality" isn't really related to speed. "Incorrectly" is also vague, unless you specify in what actual way it's incorrect. > I don't know for sure, I used Blender 2.80 a long time ago and it seemed more faster. "Remarkable quality" for me means a good or specifically normal quality, neither good or bad. > The attached screenshot looks about right for 4BU hair particles on a 0.5BU object with lots of concavities/varied normals— You asked for hair particles that are almost ten times longer than the shortest dimension of the Suzanne and that's what you got, and they'll go all over the place at first because Suzanne's normals point all over the place. The attached file doesn't seem to include the behaviour either, making it impossible to check. > The main problem was related to speed, because the object is simple and I was using Eevee to render instead of Cycles. It's very expensive to me to use Cycles most of time. I think I'll use it, only when necessary. About particle length I corrected it by reducing some meters. I reduced Suzanne size to fit that place, in my tests with it's original (default) size, same thing was happening too. > I think checking on system resources can be misleading for an OpenGL rasterizer like EEVEE, because most tools don't report GPU utilisation— Your GPU could be at 100% and using up all the (shared) VRAM it's allowed to, but your CPU, RAM, etc use could show as being at idle. > > If the problem is only about subjective speed, then think about it this way: EEVEE is built using the same kinds of technologies that video game engines use, and Cycles is built using technologies that produce much more accurate results but are also many times slower. If you can't play new games on "Ultra" settings on your PC, then why would you expect to get smooth performance from a rendering engine using the same technologies? And I say this as someone who also uses an Intel GPU most of the time; since rendering isn't the biggest or most time-sensitive use of Blender for me, the lower speed that comes with this hardware is a reasonable trade-off that I accept. > We can't compare games to modelling/sculpting an object. But in terms of quality, maybe is right to assume that. Some designers/artists render things separately to go ease on PC's resources. We all know that games are very interactive, and multiple objects with incredible quality are rendered in same time. And most were rendered using specific dedicated GPU cards technology (instruction set).

Will commented

2021-03-03 17:29:51 +01:00

Again, "normal", "good", and "bad" are all subjective— They're not software bugs, they're opinions and judgements. And from the hardware you've listed and the scene settings you've described, the behaviour you've described sounds entirely "normal" to me, or at least plausible.

Software won't magically make strange settings look normal, and it can't provide more performance than your hardware is physically capable of. Slow hardware produces slow processing, and strange particle settings produce strange results. That's not a bug; that's just normal.

If you believe an older version of Blender was significantly faster, though, then that probably is a bug. To test this, you could download an older version, open the exact same file using the exact same setttings (viewport anti-aliasing, cavity effects, etc), and report either the render times or the "fps" readout from the 3D Viewport during animation playback:

https://www.blender.org/download/previous-versions/

Again, "normal", "good", and "bad" are all subjective— They're not software bugs, they're opinions and judgements. And from the hardware you've listed and the scene settings you've described, the behaviour you've described sounds entirely "normal" to me, or at least plausible. Software won't magically make strange settings look normal, and it can't provide more performance than your hardware is physically capable of. Slow hardware produces slow processing, and strange particle settings produce strange results. That's not a bug; that's just normal. If you believe an older version of Blender was significantly faster, though, then that probably *is* a bug. To test this, you could download an older version, open the exact same file using the exact same setttings (viewport anti-aliasing, cavity effects, etc), and report either the render times or the "fps" readout from the 3D Viewport during animation playback: https://www.blender.org/download/previous-versions/

Abnilson Rafael commented

2021-03-03 19:56:51 +01:00

In #86234#1123435, @WCN wrote:
Again, "normal", "good", and "bad" are all subjective— They're not software bugs, they're opinions and judgements. And from the hardware you've listed and the scene settings you've described, the behaviour you've described sounds entirely "normal" to me, or at least plausible.

Tested in Blender 2.80, and... It's just little times faster than 2.92 in some aspects though.

Software won't magically make strange settings look normal, and it can't provide more performance than your hardware is physically capable of. Slow hardware produces slow processing, and strange particle settings produce strange results. That's not a bug; that's just normal.

I wouldn't defend software that much... They are not perfect.

If you believe an older version of Blender was significantly faster, though, then that probably is a bug. To test this, you could download an older version, open the exact same file using the exact same setttings (viewport anti-aliasing, cavity effects, etc), and report either the render times or the "fps" readout from the 3D Viewport during animation playback:

https://www.blender.org/download/previous-versions/

FPS Test:

Blender 2.80 — 20 - 25
Blender 2.92 — 15 - 24

It's not big difference, but it looks like my hardware is too weak for 3D.

> In #86234#1123435, @WCN wrote: > Again, "normal", "good", and "bad" are all subjective— They're not software bugs, they're opinions and judgements. And from the hardware you've listed and the scene settings you've described, the behaviour you've described sounds entirely "normal" to me, or at least plausible. > Tested in Blender 2.80, and... It's just little times faster than 2.92 in some aspects though. > Software won't magically make strange settings look normal, and it can't provide more performance than your hardware is physically capable of. Slow hardware produces slow processing, and strange particle settings produce strange results. That's not a bug; that's just normal. > I wouldn't defend software that much... They are not perfect. > If you believe an older version of Blender was significantly faster, though, then that probably *is* a bug. To test this, you could download an older version, open the exact same file using the exact same setttings (viewport anti-aliasing, cavity effects, etc), and report either the render times or the "fps" readout from the 3D Viewport during animation playback: > > https://www.blender.org/download/previous-versions/ FPS Test: Blender 2.80 — 20 - 25 Blender 2.92 — 15 - 24 It's not big difference, but it looks like my hardware is too weak for 3D.

Robert Guetzkow commented

2021-03-03 20:03:28 +01:00

Changed status from 'Needs User Info' to: 'Archived'

Robert Guetzkow closed this issue

2021-03-03 20:03:28 +01:00

Robert Guetzkow commented

2021-03-03 20:03:28 +01:00

I'm closing this ticket as there doesn't seem to be an actual regression and is most likely just a limitation of the hardware.

Will commented

2021-03-03 20:12:28 +01:00

@UltraBurstXD I'd like to add that you shouldn't have to let weak hardware discourage you from CGI if it's something you're interested in or enjoy. I used to use a single-threaded Athlon64 with a similarly ancient and weak nForce 630 back in the Blender 2.5 days, I've heard of people who used original (1990s era) Pentiums around the same time and made amazing art, and I still rely on an Intel IGPU most of the time.

It's slow and frustrating sometimes, but really even with better hardware you still have to wait for complex renders to complete, and you can always leave it running overnight, rent out a renderfarm, or borrow a friend's old laptop for the final renders if necessary.

@UltraBurstXD I'd like to add that you shouldn't have to let weak hardware discourage you from CGI if it's something you're interested in or enjoy. I used to use a single-threaded Athlon64 with a similarly ancient and weak nForce 630 back in the Blender 2.5 days, I've heard of people who used original (1990s era) Pentiums around the same time and made amazing art, and I still rely on an Intel IGPU most of the time. It's slow and frustrating sometimes, but really even with better hardware you still have to wait for complex renders to complete, and you can always leave it running overnight, rent out a renderfarm, or borrow a friend's old laptop for the final renders if necessary.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Inconsistent rendering experience on SoC Computer, Intel HD Graphics card #86234