Kicking the Render Engines Into Hyperdrive
I have developed under assembly language for Windows almost exclusively since 1995. I began programming in 1976 at the tender age of 14. I've done my share of DirectX work and I've worked as an SDET III at Microsoft (contract position).
At first glance, the idea of providing an optional (at least in the beginning) all-ASM render engine(s) for Blender seems ludicrous. This is because conventional wisdom tells us it can't be feasibly done. I know better. It is doable, and you don't need a team to do it. This would be for the PC platform only. Again, at least in the beginning. I contend that this would speed up the render time by a factor of 6 at the very least; 10x faster is more likely, and still higher would not come as any surprise.
Blender users, arguably, struggle with NOTHING as much as they struggle with render times.
If there is any interest in this - if you can get past your deep conditioning by the development community that pounds into your heads that this is impossible - I will be more than happy to prove the concept. Give me something to show, not tell, what I'm talking about. Obviously nothing too big because this is going to be done on my own time, at no charge (the challenge part). Let me show you. Give me a task where, if it impresses you, it will mean that creating the entire render engine in ASM is doable and should be discussed further. It costs you nothing to issue the challenge. I will meet it. I'm not talking about rewriting Blender. Just the render engine(s). There is just no need for the outrageous (many, many times worse than you would believe) slowdown that Python is causing in render times. If you let me show you, you will be blown away. You'll be shouting from the mountain tops that you had absolutely no idea how bad things really were with the current engines. They work, they're as well done as they could be using Python. But they are like using a skateboard when you could be using an F-35. Literally. Let me show you.
Email contact is best if there is any interest. If not ... it's really hard to break through a lifetime of conditioning by the entire industry that says something can't be done even though it can be quite easily.
27 Comments
This isn't a proposal. And anyways, if you write in assembly, how do you handle different hardware configurations? What about GPUs?
That's what this website is for. This is the place to show mockups.
And yet they do need a team to produce the engine that "conventional wisdom" tells us is an order of magnitude easier to use? The cycles project has taken 6+ years with dozens of contributors. Just supporting all the different hardware configurations is more than enough work for one developer.
Also, the render engines don't use Python. Cycles is C++ and EEVEE is C. Python is used for some of the data transfer, but Cycles actually accesses most of it directly by pointers. The Python problem mostly affects external renderers. At any rate, transferring the data has never been a bottleneck for me -- building the bvh and sampling has been.
But more than anything, I don't like this because there's no reason to swim upstream like this. Blender has always been a C project- even the code that isn't C is in a C-family language. The parts fit together because they follow the same rules and conventions. It makes onboarding, contributing, and continued development easier. Open Source development is dependent on community involvement. Using such an uncommon language for a core feature would drastically slow down development because there would be less community involvement. It would make it harder to contribute to all areas of blender, not just the render, because users would have difficulty building the assembly code that is made part of Blender. I have enough trouble getting CUDA to build.
* @Josephbburg * I wholeheartedly agree. The guy could also try to be more respectful to one of the most successful and professional open source projects instead of basically calling them a bunch of ninnies stuck in their way. Also most of his post is fluff and bold claims. S c a m ?
* @Josephbburg * The guy thinks that Blender's renderers are written in python and is talking about rewriting a GPU raster engine and a CUDA-based path tracer in ASM. He's delusional.
I hope you succeed as I don't know enough of the subject to say something relevant I would at least say that people that are saying you are a liar or a snake oil salesman, are failing on one point, you are not selling anything and have no reason to lie....
* @André Ferreira * he immediately jumped to "I'm going to start a Patron". He's also claiming he's the one of the only people alive "working by doing" in programming. He's also proposing things that are literally impossible to generalize, like asm on the GPU. He's either a troll, a scammer, or he's wayyyyy off the deep end.
Two issues with this. 1. The renderer is in C++ not python. I believe once the scene data is handed off to the renderer, there is no more interaction with python. 2. The pool of ASM developers is orders of magnitude smaller than C++ developers. That combined with the fact that quality ASM devs make a lot more money than average means that if you go and change the full render engine to assembly and then die, or loose interest, it will be very difficult to find your replacement and any innovations would have to be made by you.
* @dpdpforlife * To my knowledge there are no ASM devs.
Sounds promising... I hope we get some more information on it because I love seeing innovation
* @Seby Studios * You can see how absolutely unique and unusual your response is. Very realistic and very refreshing. Everybody else is threatened and getting pretty nasty when all I did was suggest an innovation. The only way people could get so emotionally negative and intense against an innovation is if they were threatened by it.
When I make this work, and I do it alone, how does that make the entire industry look? What then becomes the standard for them to meet? Theirs is the universal response (with an occasional exception, like your response was): don't better yourself, don't encourage innovation, just beat up the guy who's trying to run ahead of the pack. Destroy improvement, punish achievement, don't improve yourself. This is the crop of devs we have today, for the most part, and this is exactly why this project is needed. In April, 2017 I put an article on CodeProject covering how I rewrote the almighty perfect compiler-generated C++ code for matrix multiplication and sped it up by something like 6 times. That's just one tiny sample of my snake oil. As the project becomes bigger, it pulls farther and farther ahead of the mainstream.
Can't be done. Snake oil. Funny. I'm already doing it.
As for your comment, thank you for the one vote of support. It's nice to see that at least a few people have an ounce of sanity left.
* @malcheski * I will be convinced as soon as i see a cube and an HDRI rendered.
* @Seby Studios * So will a lot of people. It won't be done tomorrow but it will be done.
GPU's are being handled via Linux drivers (as references) and even reverse engineering CUDA if I have to. Hardware manufacturers, across the board, are outright hostile toward any development that moves away from HLL's and their attendant performance degradation. Too bad for them. I thrive on direct hardware interaction. It's what I do best. In the 90's I was commissioned to write a QIC tape driver set which went through the floppy controller. There's a reason why there were only two drivers sets in existence at the time. I had it effectively done in 2 months, alone, and that was more than 20 years ago. I've gotten a little more efficient since then.
* @Seby Studios * You will see them both.
I'm thinking that I'm going to modify this approach. I will attempt to do it on my own with Patreon support. This way the dev team doesn't need to bother with it. The engine will seamlessly replace the current cycles engine, then EEVEE. Initially it will only be available for Windows on the PC. This will expand as time and demand dictate. The only difference users will see is that renders move at a pace they never thought they would see in this lifetime. I will be starting this soon. Not today, not yet; other things need to be completed first to clear the table for exclusive focus on this project.
In keeping with the Blender tradition, when this project completes it will be 100% free for all users, all the time, for all time to come.
I'll go ahead and say it: anyone who claims in 2019 that they're going to hand-jam more efficient machine code than a modern compiler, especially for something as complicated as a production renderer, is selling snake oil.
* @matt.heimlich * Exactly the opposite. Anybody who claims compiler-generated code, which is incapable of human judgment, is superior in any way, especially when they have never created a large-scale project in ASM, will do well to remain in the mainstream where they cannot hurt anybody with their delusional view of the situation. Every single person telling me it can't be done effectively is one more person who has never created a large-scale app in ASM. When I'm waiting 8 hours for a render, I don't care if the code runs on a Mac or not; I don't care how it was managed, I don't care if one guy developed the render engine or 5,000 guys did it. I don't care if it took 1 day or 1 century. It's much like everybody who is not wealthy telling somebody everything they need to know about what will and will not make money. Show me, don't tell me. Anyway it's my project. Nobody has to download it. If they don't want it, don't download it. I can't be anymore accommodating than that.
It's only snake oil when you lack experience.
* @matt.heimlich * Are you truly that naive? The less somebody knows, the more they think they know.
codeproject.com/Articles/1182724/Blowing-the-Doors-Off-D-Math-Part-I-Matrix-Multipl
* @malcheski * That article has nothing to do with ASM being superior to standard compiled C/C++/D/Whatever, it's about how staying out of memory and using SIMD intrinsics can enhance the speed of a commonly-used matrix multiplication library. Not exactly a shocker. You just chose to do it in assembly because... you think it's more obvious? Debatable (if you can't read SIMD markup I'm not sure you belong in the field), but okay. But the takeaway from the article is "rolling your own libraries can be faster", not "asm will magically make your program faster". It's disingenuous to create a post claiming magical speed improvements without any proof. If you're going to sit there and claim to be wiser than the teams of published PhDs backed by billions of dollars of capital in the sci-viz and entertainment industries, you'd better have something to show for it, or the people who do this for a living are going to give you a hard time about it. This is my job. Every few years an undergrad student comes along and says "surely if we did it in assembly/used FPGAs/boiled some toads and uttered a chant we could make render times a thing of the past!", and reality always wins out. Now, go prove me wrong and collect your billions.
* @matt.heimlich * No compiler is going to generate what I generated by hand, which in my tests ran 657% faster than what the compiler spit out. That is reality.
* @malcheski *
So...where do we download it?
Its always nice to see speed improvements, while I dont know enough of assembler and the latest intel instruction sets, nvidea and amd and intel work with blender, and there certainly be hacks (like bone studio version of blender).
Perhaps instead of doing this, maybe helpout the NPR team. Or extend cycles with new features if you know a lot of that, or add extra engines beyond eevee cycles. Or make Blender be able to use cpython.
If blender parts becomes assembler, then the problem might be maintaining it.
* @peter.boos * Since it will take (normally) one guy to maintain it, that one guy will probably surface out of a planet of 7.5 billion people.
* @peter.boos * Actually there are benefits to this that are not immediately obvious. I am no expert in rendering engines. I am using the existing code and simply shifting the actual implementation over to something far more efficient: oversight by the human mind and its attendant creativity. Compilers lack the ability to condense. They lack judgment. They will move A to B then in the next instruction move B to A again because they can't see how stupid that is. What I'm doing is demonstrating in a tangible way that cannot be denied how bad these compilers really are. I'm keeping the current render engine function-by-function. I'm just improving the implementation. The people that actually designed that engine are so far ahead of me on the evolutionary scale, it's barely comprehensible. Little tweaks can be made here and there but by and large the current engines are producing final product that works. The people who designed it know what they are doing. I know implementation. Everybody thinks implementation is incidental. I know better. I am one of the very few people alive who knows better because I work by doing, not based on what my college professor filled my head with. I don't sit in a classroom then walk around thinking I have it all down.
* @malcheski * As a developer C#, and c++ and many other languages i'm aware that sometimes doing a little bit of assembler can speed up things, though compilations tend to be large, then thats a lot of work to redo it all. And while it can work, will it be maintainable ? Be clear in your comments what you do wherever you use inline asm code
I dont see anything wrong learning to code without a professor or official study. (neither did I ever), actually i think a lot of coders learn by doing and testing code for speed. Some parts can speedup a lot with it, i think you should contact BoneStudio's as that (as they as far as i know) have the fastest blender implementation yet. its better to make the fastest faster, then the official one who (sadly) hasnt this goal.
you seam dedicated so i wish you good luck with it!
* @peter.boos * I just red yout article on codeprojects, interesting. I was aware of some large memory move actions worked faster in asm. I hope you succeed with Blender.
* @peter.boos * The big difference is using ML64.exe standalone, no interaction with Visual Studio, and creating a full-scale app, not just bits and pieces. This is much of the problem as I see it: most people will do bits and pieces in ASM, a few times in their lives, and from that, they presume they know enough to judge the feasibility of reworking the rendering engine. There are so many nuances involved in a full scale ASM app, which the bits-and-pieces crowd will always be oblivious to, that I could spend half a lifetime documenting it all. The leap forward that I'm bringing to the table has, until now, been absolutely blocked by people who presume themselves to be experts only because they have no idea how much they don't know. I was able to bypass a vulgar amount of absolutely wasteful WDF startup code that wasted time and memory executing before the actual driver ever executed the first instruction. This is not about glory for me because there isn't going to be any. The more successful I am, the more I will become public enemy #1 in the development community. I have been me for my entire life. I know that NOBODY celebrates the visionary. They crucify him to protect their image. They don't do it consciously which is what makes it that much more intense. This is about opening up new horizons in graphic arts. It's safe to say that currently I am the only person anybody is aware of who believes things can be made much, much faster than they are. So who else is going to do it, if it can actually be done? Or do we stagnate where we are for the rest of eternity, requiring entire render farms and multiple graphics cards to render photo realism that doesn't even have any nature in it? If you don't reach higher, you will stagnate, as the dev community has done for decades. Stagnation is death.
Big promises there. ;)
For an easier discussion I would recommend starting a Devtalk thread. devtalk.blender.org/
* @rbx775 * Nobody would participate.