Dynamic texture refresh cpu performance problem #41037
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#41037
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
So to put a video in play on a dynamic textured I have to refresh the texture every frame to ensure update of the texture.
So I created a logic brick to run the code that performs the refresh of the texture.
The logic brick that I created is set to always without delay, also the only code that is executed in the logic brick is the refreshing of the dynamic texture.
http://www.blender.org/documentation/blender_python_api_2_71_release/bge.texture.html
you need to call this function every frame to ensure update of the texture.
logic.video.refresh(True)
Is it possible to implement the refresh of the dynamic texture as a texture properties which if set to true will be executed automatically (inside bge), without load on the cpu with a logic brick?
A core of my cpu spikes to 99% when I run that code.
Thank you very much
Giulio
Changed status to: 'Open'
Added subscriber: @Trixymoon
Added subscriber: @brita
The example code in that documentation should work fine without a 99% load in either the CPU or the GPU.
Can you provide the file (a minimal example) of your setup? I'll need it to follow this as a bug.
test.blend
System Information
First computer:
System:
Linux lucy 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
on Mint Mate 17
Graphics card:
nvidia Geforce GTS 250
blender --version
Blender 2.71 (sub 0)
build date: 2014-06-13
build time: 08:56:24
build commit date: 2014-06-12
build commit time: 18:39
build hash:
169c95bbuild platform: Linux
build type: RelWithDebInfo
build c flags: -Wall -Wcast-align -Werror=declaration-after-statement -Werror=implicit-function-declaration -Werror=return-type -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -Wno-unknown-pragmas -Wpointer-arith -Wunused-parameter -Wwrite-strings -Wlogical-op -Wundef -Winit-self -Wnonnull -Wmissing-include-dirs -Wno-div-by-zero -Wtype-limits -Wuninitialized -Wredundant-decls -Wno-error=unused-but-set-variable -fopenmp -msse2 -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing
build c++ flags: -Wredundant-decls -Wall -Wno-invalid-offsetof -Wno-sign-compare -Wlogical-op -Winit-self -Wmissing-include-dirs -Wno-div-by-zero -Wtype-limits -Wuninitialized -Wundef -Wmissing-declarations -D__STDC_CONSTANT_MACROS -fopenmp -msse2 -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing
build link flags: -Wl,--version-script=/build/buildd/blender-2.71~git201406121839.169c95b/source/creator/blender.map -pthread
build system: CMake
Second computer:
Operating system: 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux
on Debian Testing
Graphics card: nvidia G98M
blender --version
Blender 2.71 (sub 0)
build date: 2014-06-13
build time: 08:56:24
build commit date: 2014-06-12
build commit time: 18:39
build hash:
169c95bbuild platform: Linux
build type: RelWithDebInfo
build c flags: -Wall -Wcast-align -Werror=declaration-after-statement -Werror=implicit-function-declaration -Werror=return-type -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -Wno-unknown-pragmas -Wpointer-arith -Wunused-parameter -Wwrite-strings -Wlogical-op -Wundef -Winit-self -Wnonnull -Wmissing-include-dirs -Wno-div-by-zero -Wtype-limits -Wuninitialized -Wredundant-decls -Wno-error=unused-but-set-variable -fopenmp -msse2 -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing
build c++ flags: -Wredundant-decls -Wall -Wno-invalid-offsetof -Wno-sign-compare -Wlogical-op -Winit-self -Wmissing-include-dirs -Wno-div-by-zero -Wtype-limits -Wuninitialized -Wundef -Wmissing-declarations -D__STDC_CONSTANT_MACROS -fopenmp -msse2 -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing
build link flags: -Wl,--version-script=/build/buildd/blender-2.71~git201406121839.169c95b/source/creator/blender.map -pthread
build system: CMake
Third computer:
Mac OSx:
Darwin Silvio.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
Graphics card: nvidia Geforce 9400
Blender 2.71 (sub 0)
build date: 2014-07-08
build time: 20:27:39
build commit date: 2014-06-25
build commit time: 18:36
build hash:
9337574build platform: Darwin:64bit
build type: Release
build c flags: -DWITH_FREESTYLE -DWITH_QUICKTIME -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -arch x86_64 -pipe -funsigned-char -ftemplate-depth=1024 -I/Volumes/Workdata/Blender/Development/lib/darwin-9.x.universal/openmp/include -fopenmp -DNDEBUG -O2 -msse -msse2 -msse3 -ftree-vectorize -mssse3 -m64 -DWITH_MOD_FLUID -DWITH_MOD_OCEANSIM -D__LITTLE_ENDIAN__ -DWITH_AUDASPACE -DWITH_AVI -DWITH_OPENNL -DHAVE_STDBOOL_H
build c++ flags: -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -arch x86_64 -pipe -funsigned-char -ftemplate-depth=1024 -I/Volumes/Workdata/Blender/Development/lib/darwin-9.x.universal/openmp/include -fopenmp -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.6 -arch x86_64 -DNDEBUG -O2 -msse -msse2 -msse3 -ftree-vectorize -mssse3 -m64 -DWITH_MOD_FLUID -DWITH_MOD_OCEANSIM -D__LITTLE_ENDIAN__ -DWITH_AUDASPACE -DWITH_AVI -DWITH_OPENNL -DHAVE_STDBOOL_H
build link flags: -mmacosx-version-min=10.6 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -arch x86_64 -m64 -fexceptions -framework CoreServices -framework Foundation -framework IOKit -framework AppKit -framework Cocoa -framework Carbon -framework AudioUnit -framework AudioToolbox -framework CoreAudio -framework OpenAL -framework QTKit
build system: SCons
Anyway I can not slow down the logic brick pulse otherwise the video stutters.
I remain at your disposal
Added subscriber: @raco
Please provide a fully functional, but small example. The blend you provided is incomplete.
What do you mean whit fully fictional? The blend file contain a simple script that refresh the texture every frame, even without a video file a sigle core of cpu go to 100%.
Please explain me what is missing.
I have made an UV mapping of the texture, now you have just to add a video whit the name test.ogg in the same directory of the blend file.
test_refresh2.blend
It would be better to provide a complete example file so you're not giving developers more work than necessary.
I tested your file anyway, but I think I don't have an *.ogg anywhere on my disk so I replaced this with *.mp4 instead. My processor usage is about 20% when playing (and no CPU core peaks to 100%). I guess this is normal, but now I don't know if this maybe has to do with using *.mp4 instead of *.ogg. See?
So now I searched my disk for an *.ogg but could only find audio files. Now to the web, googling 'ogg sample video' and found one: http://techslides.com/demos/sample-videos/small.ogv
It's the same as with the *.mp4, but now I wonder if it may be because it were small files...
Aside of the fact that this took me over ten minutes, I'm still not sure if I reproduced the same circumstances as you are having. So I hope this gives you an answer to your question.
I have to apologize I think I explained myself badly yesterday, thanks to the tiredness, it was 4 in the morning for me, and my bad English.
The python code executed by the brick logic is associated with only a single core of my cpu cores and it is that which goes to 99%, not all of the cpu.
Also there is no really need to start a file video in the project to get that result.
In fact, in the screenshot I provided, the video had not been put in play, nonetheless a core, the first one, of my cpu was at 99%.
The problem is that the logic brick executes an infinite loop, without delay, on a piece of code that does the refresh of the texture. It is this infinite loop, which uses the first core of my cpu.
So on an Intel cpu, like mine, with 4 cores and 8 threads cpu usage is 12.5%.
The problem comes when you need to run python code in another project (eg: receive tons of OSC messages from a socket on which you are listening).
All the python code continues to be associated with a single core on 8 available and if I have a piece of code that loads me on that thread everything else is slowed down.
Furthermore, in python 3 threads are not implemented using the threads of the operative system.
Thank you for your patience
I remain at your disposal
Giulio
ps: The video file "trailer_400p.ogg" mentioned in blender documentation (where I got the code for the test.blend file) was this one here:
http://upload.wikimedia.org/wikipedia/commons/7/75/Big_Buck_Bunny_Trailer_400p.ogg
Thanks for the link, Giulio, I tested with this *.ogg, but like before no CPU core is peaking (not more than 20%). However I had no sound, but that's another issue probably.
So, I'm afraid I couldn't reproduce your issue on my system, hope someone else can. Here's my specs:
Windows 7 64 bit, Nvidia GeForce GT540M Cuda; Blender 2.71 hash 9c48ea3
To make it easier for everyone, here's a complete example: Video_refresh_CPU_issue.zip
Thank you for your prompt response! :-)
Can you be more precise?
Have you monitored the usage of every single core of your CPU?
How much is the load of every core of your CPU when you launch my test file?
About sound is not a problem, VideoFFmpeg only reproduce video, if you want to reproduce the audio of the video you have to use aud module separately, with all the problems that playing the audio separately from video implies (lip sync, etc.).
Maybe it's another issue but could be also a strange implementation choice. I don't know.
Here a screenshot on my Windows 7 64 bit SP1 pc
I just waited a bit to see this chart, surely the implementation of the threads in windows and linux is different, so it in linux the problem is more noticeable.
OS: Windows 7 64bit SP1
cpu: Intel I7 2600k 3.40 Ghz;
ram: 8gb
graphic card: nvidia gts 250, 1gb ram
blender --version
Blender 2.70 (sub 0)
build date: 19/03/2014
build time: 20:35
build commit date: 2014-03-19
build commit time: 14:34
build hash:
cc2cdfbbuild platform: Windows
build type:
build c flags: /W3 /w34062 /wd4018 /wd4065 /wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /we4013 /we4431 /J /Gd /MP /openmp
build c++ flags: /W3 /w34062 /wd4018 /wd4065 /wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /we4013 /we4431 /nologo /J /Gd /EHsc /M P /openmp
build link flags: /MACHINE:X64 /OPT:NOREF /SUBSYSTEM:CONSOLE /STACK:2097152 /INCREMENTAL:NO /NODEFAULTLIB:msvcrt.lib /NODEFAULTLIB:msvcmrt.lib /NODEFAULTLIB:msvcurt.lib /NODEFAULTLIB:msvcrtd.lib
build system: CMake
As I've said before, I think the problem is the infinite loop of the logic brick, regardless of the video that is played on the texture.
Thanks again and sorry for my bad English
Giulio
I use Open Hardware Monitor to monitor my CPU levels.
I wonder which monitor is displaying correctly.
But you can see it peaks around 25%.
@brita Maybe could you have a look?
Well both the charts are correct. :-)
In the windows task manager you cas see eight graphs.
In fact your cpu have eight core thanks to Hyper Threading Intel tecnology: http://en.wikipedia.org/wiki/Hyper-threading
from wiki: "For each processor core that is physically present, the operating system addresses two virtual or logical cores, and shares the workload between them when possible."
So, the windows task manager shows you eight core half of these are virtual. The Open Hardware Monitor show you the real four cores.
Since each core is divided into two virtual cores, the sofware, rightly, shows you use close to 50% of the first core.
Or about 12.5% of the cpu. Now think what would happen with an old PC with a single core without Hyper Threading.
I hope I have allayed your concerns
Giulio
Thanks, Giulio, for this valuable information. Since I'm not an expert on this, I hope someone else could confirm if this CPU usage is due to a bug in the BGE. Maybe brita_ can redirect this to someone who's familiar with these type of things.
Well, strictly speaking this is not a bug, I thinks it is a implementative choice.
In fact, it is this choice that I am questioning, with the greatest respect for the developers.
(No sarcasm here seriously, I do not know what's in the behind the scenes of Game Engine.)
The point of the situation is that to view a video or a picture on a dynamic texture you need to run an infinite loop on the method "refresh(true).", moreover, you can not slow down the logic brick pulse otherwise the video stutters.
Any infinite loop is a quick way to erode the the computing capacity of the CPU.
The cycle can also be empty, but that is enough to have a work load on the CPU (or in one of its core). :P
The question is, is there a way to do otherwise, always maintaining the dynamic texture?
It is possible this problem has not been noticed? Or more simply, there is no other way to do it?
The best of the ideas that come to mind is setting a property to True, to make sure that the BGE know which dynamic texture needs to be updated, leaving the burden of updating the texture to the BGE and not to the logic brick.
Then, when you no longer need to update the dynamic texture, you can put the same property to False.
One last thing the class "bge.texture.VideoFFmpeg" is not the only one suffering from this problem.. (sig.)
Giulio
I see. But I'm wondering if automating the video refreshing would actually make a (noticeable) difference. If you think about it, to playback video, the bge has to convert every frame. It's not like we have a real player in the bge. And I think this is what is taking so much processing power/time. But I don't know for sure. It's an interesting topic so I hope some else could tell us more about this. Maybe you could start a new thread on the BA forum to ask around? Just an idea.
In my opinion, there is a substantial difference.
The blender game engine performs the refresh of the image at 60fps, by default, while an infinite loop executed by the CPU is much faster.
In fact, the call to "refresh(true)" method, on the texture dynamics, is performed a number of times greater than the real need to update the texture, instead, leaving the refresh of the texture to the bge would optimize its performance since the refresh would be limited to the number of frames per second on which the bge has been set and not to the number of cycles of the cpu.
You can argue that you can slow down the logic brick but the unit of measurement of the logic brick are the fps, so set the delay to 1 introduces the loss of a frame during playback of the video and then the image would be jerky.
It is not even possible to run the sleep method of python, because it blocks the bge.
sorry @raco, this did not notify me,
I just tested on Linux and i don't get anything above ~20%
I don't think there is a performance problem here (about refreshing). This video texture module should definitely be redesigned, but it also should not cause 99% CPU usage. Infinite loops should not happen.
@brita can you specify please? ~20% of your entire CPU or of a single core? I'm talking about the usage of a single core.
The loop I was talking about is what you do by setting the logic brick (always sensor) to perform the refresh of the dynamic texture. More fast is the cycle, more it's the use of the cpu.
I was talking about all classes on which you must call the refresh method if you need update the texture:
bge.texture.ImageMirror
bge.texture.ImageMix
bge.texture.ImageRender
bge.texture.ImageViewport
The code of the test file was tested on four different platform:
Linux Mint 17 - Blebder 2.71 (irie ppa)
Linux Debian Testing - Blebder 2.71 (irie ppa)
MacOs 10.6 - Blender 2.71 (downloaded from the official site)
Windows 7 - Blender 2.70 (official)
Usually I do not use windows for work and program, i rebooted in windows just for doing a test.
I remain at your disposal
Giulio
20% of an i7 Q740 - 1.73GHz. it's 8 cores, 4 of them virtualized. The OS is Linux 64bit, I have a dedicated nvidia GPU.
I do not have an intel single core machine to test.
@Trixymoon You are saying that you have your cpu spiking on window, mac and linux, with blender 2.71 (2.70 on windows..).
Is it all the same machine?
@brita I think that my bad english can generate misunderstanding but I have specified many times that (with the support of some screenshot too) is just a single core of my CPU that is experiencing peaks.
No, only the first one and the last one are the same machine. I7 2600K with nvidia Geforce GTS 250,
the second and the third one are different.
Just to further clarify I don't have a single core processor.
Added subscriber: @Sergey
I'm sorry then, I misunderstood.
You have one of your cores spiking to 99% in different OS and hardware...hmm @Sergey ?
Added subscriber: @Moguri
Are you sure it's the video texture module? At least on Windows, the BGE will consume a whole CPU core due to busy-waits in the GPU driver (I know NVIDIA has a busy-wait in their driver).
Added subscriber: @pippo
I have the same problem on a system with an NVIDIA card too but your hypotesis is not so persuasive: @Moguri have you tryed the test file posted by Trixymoon? Have you tryied it without the refresh of the texture(commenting that line of code)? The CPU core spike to 100% anyway, so I think that the NVIDIA driver cannot be the cause of this problem unless there are some calls to NVIDIA driver indipendently from texture refresh.
I think that should be some problem with the always logic brick, but I didn't reviewed the code so I can't determine it for sure.
My opinion on the matter is that creating a logic brick, which is set to always and pulse 0, to perform the refresh of the texture is absolutely inefficient.
The logic brick execute this code cyclically, the faster is the cycle, the more CPU is used. (not all the cpu: 1 core of it)
For this reason, if the logic brick executes a piece of empty code the cpu consumption is more noticeable.
The problem is that you can not do otherwise, if you need to update the texture then you need to do so. In addition, you can not slow down the logic brick otherwise the video shutters.
So I was wondering if doing the refresh of the dynamic texture inside the bge could solve the problem.
At least, the bge can perform the refresh of the texture for the number of frames per second that was set.
While a always sensor performs the refresh of the texture a number of times greater than the real needs.
@Moguri You were able to reproduce the problem on your system?
In some executions of the test file the peak of use of the core can be reached in about one minute.
Giulio
I max out a single CPU core regardless of whether or not the logic bricks are connected. The BGE's main loop has no sort of wait, so it is expected that it will try to take as many CPU cycles as possible.
So refreshing a texture or everything else must be executed many time more then necessary (CPU clock instead than bge framerate) consuming all core that is assigned to bge process...
There is no way to solve this issue?
Thanks Moguri I understand the problem perfectly now.
I was thinking that the problem was the brick logic which was set to always without delay, now I understand that it is the bge, which uses one core of the cpu.
Ok, take me for a naive, but I have to ask, can you get around this problem?
I do not know, maybe in a future release of blender / bge?
I dared to ask this because I know it has been planned to rewrite the bge, and frankly I do not know if this is a reasonable request. I don't know the source code of the bge and as far I can understand the BGE main loop is an architectural choice.
The python code executed by the bge is performed within this main loop?
This is my situation:
In my project I have a two logic brick.
The first one is an always sensor which is executed only once.
The second one is the logic sensor which perform the dynamic texture update.
The first logic sensor create some python class and start a thread which reads from an UDP socket created in blocking mode (no busy waiting).
The messages read form the socket are OSC commands, these commands are executed and perform basic action like rotate, move, set visibility, play, pause, stop of a video on a dynamic texture, etc.
Whenever these message are few all is well, but when these message are a lot (like the rotate/move commands sent from a leap motion sensor) a delay is introduced in the execution of the commands.
I have optimized the code reducing the message rate from the sensor and, where possible, more messages are merged into one, which reduces drastically the context changes (user space <-> kernel space) for reading messages from the socket.
The result is that, the delay in the animation is almost completely disappeared.
Then my attention fell on others potential bottleneck of my source code.
Although it is clear to me who is consuming the cpu now, it is reasonable to expect that the refersh a dynamic texture is performed by the bge rather than the python code?
Also, as noted by raco in a previous post of this discussion, the class "bge.texture.VideoFFmpeg" doesn't play the audio track of the video, is this a bug, an implementative choice or simply this feature has not been implemented and never will be? (the lip sync problem caused me quite a few headaches)
Anyway, thank you so much for your patience.
Giulio.
If you're wasting cycles on a busy-wait in the GPU driver, then it should show up under GPU Latency in the profiler. If that is the case, just add more logic/animations/physics/whatever to make use of more CPU cycles. In other words, you have spare cycles that you can make use of without affecting your framerate.
You should not use blocking sockets (or anything for that matter) in the BGE. They stall the engine (the engine cannot continue it's main loop until scripts finish executing, which cannot happen if at least one script is waiting on a blocking call).
Unfortunately, VideoTexture only handles video, not audio. There are examples showing how to use the Audaspace library to play (and synchronize) audio data from video files.
About gpu latency I can't say nothing for sure because I have different latency on different hardware so I'm doing some more tests to understand this thing better.
The blocking socket I use it's inside a python thread lunched by BGE, so this thread it's independent from BGE and I can use a blocking socket without blocking the esecution of BGE itself.
In fact, even if the BGE is not receiving any OSC message it's esecution isn't blocked in any way.
"There are examples showing how to use the Audaspace library to play (and synchronize) audio data from video files."
Thanks, I was already using the aud module for playing the audio track of a video, for some video like Big Buck Bunny, the sync is just perfect, for others no.
I think is a matter of interleaving. I dunno.
I need to do others test with others video files and more pcs before I say something about the lip sync problem.
Maybe the video file that I use is buggy
@Moguri Thanks you for all support and your time
Giulio.
Changed status from 'Open' to: 'Archived'
Running mainly on one thread only is a known limitation of the GE.
How and what will be redesigned is still to be seen.
I am closing the task (as invalid because it is not a bug), if you need any more support feel free to contact :)