Live data from Hacker News

Cycles X

code.blender.org

121–130 of 151 posts

Re: Cycles X

#122
post #16

Earlier quoted context omitted.

Maya was an amazing piece of software once. It is falling behind only because Autodesk seems to be content to just let it slowly rot. The funny thing is that there are litanies of complaints about many core Autodesk products that echo the same chorus: the software is poorly maintained, bugfixes are promised "for the next released" (paid upgrade, of course) and yet, they never appear. Customer feature requests are com…

For a complete opposite of Maya, see Side FX Houdini. An incredible masterpiece of software development, keeps getting better every year, the company is extremely competent, beloved by the community, they keep innovating even though they're so far ahead of any other alternative. I don't know if I have a point to make, I just wanted to gush about my favorite 3D software, and also I'm sad to see what autodesk is doing…

Every year, I keep praying that Side FX doesn't sell to Autodesk - so far it seems to be working.

Re: Cycles X

#123
post #100

Earlier quoted context omitted.

GPL may as well mean radioactive as far as legal is concerned. A friend worked at a company where they banned GIMP as they feared that editing logos and other trademarks in it could invalidate them. Even working for a tech company, I don't think I would suggest using anything GPL as it would cause a fuss.

Tons of widely used software -- Linux, for one -- is GPL.

Of course - the GPL thing is just FUD. The company I work for (Red Hat) sells tons of GPL software to small and large companies, including huge media/entertainment companies, and none of them is talking about how the GPL is "radioactive".

Re: Cycles X

#124
post #106

Earlier quoted context omitted.

Vulkan Compute is the alternative, and you should look again if you're serious.

Thanks. According to this post [ https://community.khronos.org/t/opencl-vs-vulkan-compute/713... ], Vulkan Compute seems to be mostly focused on rendering over general compute. This is probably fine for Blender's renderer, but may not be suitable for some compute loads. Unless something has changed since then, or the post is inaccurate?

That post is 4 years old. Since then, Vulkan compute has made enormous strides forward, while OpenCL has stagnated. Examples of the things Vulkan has now are subgroup size control, explicit float16 and int8, pointers (previously you had to fake them with arrays), and a memory model. The memory model alone is a pretty big advance.

What is still a mess is the tool situation. You have to write your shaders in GLSL or HLSL (the latter is still missing some subgroup operation) and compile to SPIR-V. You also have to have CPU-side code to manage all resources, including memory allocation and putting in explicit pipeline barriers and other ways to manage the asynchrony. For someone who just wants to get their code running, it's pretty painful.

My own application is 2D rendering, but a lot of the motivation for improving Vulkan Compute is machine learning workloads. One of the projects to watch is IREE (https://google.github.io/iree/).

I've got some blog posts and tutorials in the pipeline, stay tuned.

Re: Cycles X

#125

Earlier quoted context omitted.

Vulkan supports integer operations just fine, but tool support for just about everything is extremely primitive. Sizes other than 32 bits are available, but generally as an option. You can check https://vulkan.gpuinfo.org/listfeaturescore10.php to see the fraction of drivers that support the various integer sizes (and lots other optional features).

Thanks! I guess I got confused with the information out there. Most examples seem to be using GLSL shaders for the kernel, but posts seem to indicate it uses SPIR-V as input [ https://community.khronos.org/t/is-a-vulkan-compute-shader-d... ]. And then you have threads like this [ https://community.amd.com/t5/drivers-software/amd-dropped-sp... ] saying that SPIR-V isn't supported on the AMD's Windows driver (I had sim…

There's a lot here, let me try to clarify a bit.

Most of the time, when people say OpenCL, they mean that an OpenCL driver is provided by the GPU vendor. That's what's in a particularly sorry state. Many vendors ship OpenCL but have deprecated it. AMD's ROCm is based on OpenCL, but they don't support it on all cards and there are problems.

The other thing that's picking up steam lately is using a lower level API such as Vulkan as the interface to the graphics hardware, and having a layer that runs the compute workload (whether OpenCL or something else) on top of that. In my opinion, this actually has a pretty good future. On Linux, Vulkan is obviously the way to go, on Windows it's supported by all major cards, and on mac it's possible to fake it with MoltenVK. This is what clspv and clvk are about, but from the article you posted these are not in usable shape yet. I think that might say more about the level of interest around OpenCL than anything else though. It's entirely possible that running compute on Vulkan becomes mainstream through other efforts like IREE than by porting OpenCL workloads.

In a couple years or so, there's a good chance the landscape will shift again, as WebGPU might be capable of running compute workloads well, and is likely to be supported by all vendors. Note that despite "web" in the name, it doesn't require a browser or other web technology. You can run prototypes of it today, but there are still huge chunks of the ecosystem missing.

Re: Cycles X

#126

Earlier quoted context omitted.

OneAPI/SYCL also works on AMD if the card supports ROCM.

“Works” and actually works are different things. ROCm isn’t in a state that i would define actually working atm, considering just how broken their CUDA to HIP stuff is I’m not going to hold my breath.

SYCL can be targeted directly to HIP without going through Cuda first, but I agree that it's far from perfect. IMO though, it's as useable as OpenCL by now.

Re: Cycles X

#127

Earlier quoted context omitted.

Just an observation and a point of discussion regarding the big studios. Disclaimer, I am not in this space professionally, but I listen to a LOT of podcasts about VR/AR which spills into all of these topics. Do you see a push away from Maya and 3DS max for a more platform agnostic modeling environment? Blender seems to be mentioned all over the place for beginners. From what I am hearing on podcasts, Unreal Game eng…

I'm not in the field myself, though animation was my original career and I know people who work in feature animation. To answer your question, the field has been sloooowly diversifying in some ways, as you say with Unreal (particularly since Unreal's engine is fast and good for real-time previews), but I don't see a huge push for moving away from does-it-all packages like Maya or 3DS Max. The economic incentive isn't…

> It's going to take a decline in the field of animation before studios realize that they're basically stuck in 2006 in terms of how their artists are working to make their content.

I’m pretty sure there has been a huge decline in feature animation in the United States. VFX and feature production has almost collapsed here, with much of it moving to places that offer subsidies and cheaper labor for this kind of work, like Canada, Europe, and India.

Re: Cycles X

#128
post #16

Earlier quoted context omitted.

Maya was an amazing piece of software once. It is falling behind only because Autodesk seems to be content to just let it slowly rot. The funny thing is that there are litanies of complaints about many core Autodesk products that echo the same chorus: the software is poorly maintained, bugfixes are promised "for the next released" (paid upgrade, of course) and yet, they never appear. Customer feature requests are com…

For a complete opposite of Maya, see Side FX Houdini. An incredible masterpiece of software development, keeps getting better every year, the company is extremely competent, beloved by the community, they keep innovating even though they're so far ahead of any other alternative. I don't know if I have a point to make, I just wanted to gush about my favorite 3D software, and also I'm sad to see what autodesk is doing…

SideFX is the single most pleasant and hope-restoring company to deal with in this entire field. Other vendors have amazing teams, but top to bottom SideFX outclasses them all in terms of support, feedback reception, release cycles, feature/stability improvements, and licensing.

Re: Cycles X

#129
post #123
post #100

Earlier quoted context omitted.

Tons of widely used software -- Linux, for one -- is GPL.

Of course - the GPL thing is just FUD. The company I work for (Red Hat) sells tons of GPL software to small and large companies, including huge media/entertainment companies, and none of them is talking about how the GPL is "radioactive".

Because libc is licensed under LGPL and not GPL. GPL in and of itself isn't bad if you're not developing code that links it in. LGPL is also widely used in the CG industry (Qt etc...). If Blender licensed their API under different terms it would greatly open things up.

Re: Cycles X

#130
post #15

When I was working on a ray tracer, I found that interpolating the color from neighboring points instead of leaving it blank for in-progress elements was a huge improvement for quickly seeing what the scene is going to look like. In the video examples it doesn't seem like they're doing it. I'm interested to know the rationale. (See "Progressive Rendering" section for an example: https://blog.vjeux.com/2012/javascript…

There are a few reasons the speedup scheme you’re talking about doesn’t get used for GPU ray tracing. On a GPU, time to first image that fills all pixels is not typically a problem, and rendering every other pixel and interpolating is more complicated and might take long enough that it doesn’t actually help.

Rendering every other pixel on a CPU in JavaScript is a huge advantage because ray tracing on that platform is incredibly slow compared to GPU ray tracing, and rendering is done sequentially one pixel at a time. Rendering on a GPU is very different because it handles thousands of rays at a time in parallel, and the typical time to get the first complete image on-screen is a fraction of a second. Today’s high end GPUs can trace tens of billions of rays per second, so with that kind of budget it’s easy to get through all the pixels of a 1080p image with multiple rays per pixel. The images in your blog post can be ray traced on today’s high end GPUs at 60hz with tens or even hundreds of samples per pixel for antialiasing.

Another reason a pixel interpolation scheme isn’t used on GPUs is because you don’t have random access to neighboring pixels during a single launch. What this means in practice is you’d have to do a ray tracing launch followed by the interpolation launch. The launches have some overhead, and the UX would be that you first see the checkerboard pattern all at once, and then later you get the interpolated image. You don’t get to see partial progress as you go, unless you’re breaking the image into tiled launches, and that slows down rendering and adds more complication. (Many pro renderers on the market do have tiled rendering to give progressive feedback, BTW).

On the GPU, maybe one of the closest things to what you describe that is being used in games today is DLSS; render a lower resolution image, then upscale to a higher resolution. Instead of interpolating neighbor pixels per se, it’s using a neural network to improve the interpolation based on the image content https://en.wikipedia.org/wiki/Deep_learning_super_sampling

There are approaches to deferred shading on the GPU that do something similar to what you’re talking about https://graphics.geometrian.com/research/dacs_in_hw.html

There is also denoising, which has the same high level goal as what you’re doing (fill in missing data to get a high quality preview faster), but uses a much more sophisticated interpolation algorithm, and rather than skipping pixels works on Monte Carlo images with low samples per pixel. https://developer.nvidia.com/optix-denoiser

Post reply on HN