The net worth calculation didn't show any major change since July. The stonk market moved sideways & yields turned negative. The lost decade from 1999-2009 could be setting up again, with the tail wind of quantitative easing gone, a large overhang of government debt, & no growth in productivity.
The lion kingdom was about 50% cash, 40% stonk, 10% bonds. Bonds have tended to follow stonks though. Paychecks made up roughly 25% of the gains in 2024, not factoring in health insurance or deferred taxes. The day job did pay for rent, electricity & food. It was almost not worth having a job, but that particular year had a once per generation stonk rally & interest rate in the 1st half.
Lions are still conservatively invested enough for paychecks to be a necessary ingredient in the long term.
Rent & electricity aren't much of a win, considering they're only necessary because of the job. The hope is years like that become more common as principal increases.
--------------------------------------------------------------------------------------------------------------------------
Pondering the GPU to CPU case yielded a solution whereby if the read command gets use_opengl=1, it's unchanged. If the plugin read command gets use_opengl=0, it sets it to 1 & then performs an VDeviceX11::copy_from to put the output in RAM. The question remaned whether or not to do it. In the modern age, GPU to CPU bandwidth is fast enough for it to probably be faster than performing all earlier stages in the CPU. Lens before histogram or blur are the key cases & probably faster with the transfer.
A quick test of this doubled the framerate when feeding sharpen from some opengl stages.
The frame rate was still slower when using the GPU effects than when using just sharpen, showing the read from GPU to CPU was impacting it.
There are still other cases besides a plugin read command
which go to RAM & would have to be overridden. File::read_frame
still downgrades to RAM when requested. That only does colorspace
conversion in the GPU. Colorspace conversion is done in the GPU to reduce the amount of data ingested over PCI. It's useless if the output goes back over PCI.
Nested EDLs still downgraded to RAM when requested. Nested EDLs are a complicated case involving many diversions back to CPU inside VModule::import_frame. If they feed a transition that uses the GPU, the result could be a wasted GPU -> CPU -> GPU operation. They really need extra knowledge to not go to GPU if feeding a transition or smarter transitions.
Screencapped a few tests with a nested EDL to show it forced GPU when not going to a transition & didn't force GPU when going to a transition. In the transition case, the nested EDL eventually went to the GPU when it hit the lens effect. Projector, mask are not supporting forced GPU.
VirtualVNode::render_as_module performs fade, mask, projector. It would need prior knowledge of their usage to know when to perform a GPU override. These are normally fast operations in the CPU, nowadays. The mask is always partly done in the CPU. The projector could be slow.
The complicated camera, projector process was never used as
much as lions hoped in 1998. Other programs use discrete transformation plugins with special keyframes to simulate bezier curves. Avoiding bezier curves continues to be their goal, just as it originally was for lions. It was really going to yield non stop
music videos & synthetic characters were going to abound for
compositing into synthetic scenes.
VModule::render downgrades to RAM. It handles transitions. Transitions may support opengl for their output but must always read from RAM because they use a push model.
File reads & transitions on the CPU aren't terribly impacting. The only transitions supporting opengl are dissolve, flash, zoom. They're manely impacted by reading 2 files simultaneously. If you're using render plugins or nested EDLs to feed a transition, it's going to be using the CPU. The best optimization would be a redesign of transitions to call read_frame, but they're just not used.
Forced GPU is always going to be only partially supported, just like opengl in the plugins. What steps support forced GPU mode depend on the value & the difficulty.
The rendering process has grown quite complicated with both GPU support, GPU support when rendering & now GPU override. It's unlikely to work in all cases like rendering effects, rendering to a file, batch rendering, proxy creation, & renderfarm.
------------------------------------------------------------------------------------------------------------
Memory of warmer days. Hard to believe the quality of video lions got in 2016 was still better than what most influencers get today, despite years of stabilization, sensor, & resolution improvements.
Comments
Post a Comment