berkut

curl is shipped (by Apple) as a command line tool and libs to link against on stock MacOS (unless Xcode installs it these days, but I don't think so?).

Without knowing specifics, it's difficult to say... could be different compilers (clang on MacOS, maybe gcc on Linux?), linkers, file system caches could be warm on one, etc. There could be different code being generated (#ifdefs, etc) per platform and architecture.

Having said that though, as someone who got an M1 MBP (10-core) a few months ago, I also found that CPU-wise (ignoring memory/cache bandwidth, which is much faster on the Mac), it wasn't really any faster than a 2012-era dual-socket 4 core Xeon at 3.3 Ghz for compiling and raytracing (the latter doing lots of FP calculations which I'd expect the M1 to compute OOO really well with how wide it is) when the code was CPU-bound. The power usage is very different though obviously. Hyperthreading also helped the Xeon quite a bit.

Battery life is very impressive though, and haven't really heard the fans yet.

Because the 'efficiency' cores are actually optimised for silicon area efficiency (and not just low power usage, like is generally the case with things like ARM big.LITTLE setups), and AVX-512 native takes up a lot of silicon space on the chips Intel has implemented it for.

And because it's not clear how OS schedulers could nicely switch on-the-fly between cores with different instruction set capabilities, it's essentially not use-able.

Ah, I must have clicked away to the main pricing page then thinking it was the same one...

What are the practicalities of the '680 GB Minimum Order'? I would have expected you pay by how much you use (hence the price per GB), but the minimal order (the submission form however won't let you submit less than 100GB, so it's a bit confusing there's a mis-match?) seems slightly at odds with that.

(The FAQ doesn't seem to answer that)

It's small, fast, and doesn't have a GIL lock, so concurrent executions are trivial.

Moving to higher bit depths than 8-bit will also help a bit - it's not helped by agressive compression, but even with lossless compression (PNG) 8-bit gradients like skies still suffer from the problem...

ICC support works fairly well, and anyway, each DCC (Katana, Nuke, Houdini, RV, etc) has custom (normally via OCIO) colour profile support itself, so even if the OS' support isn't perfect, it doesn't really matter (as long as the graphics drivers can push the correct result out).

Most of the high-end VFX/CG industry uses Linux for both workstations and render farm nodes. Some studios like Pixar allow a bit more flexibility to some artists in certain roles (generally those that don't work in the pipeline that much - i.e. concept artists) to use other software / OSs, but otherwise it's mostly Linux.

Smaller studios use Windows/Mac a bit more (boutiques use Macs the most), but the removal of the Xserve and the lack of competitiveness in the MacPro for several years have shifted some away from Mac.

That info won't be coming out for a while...

I can say though, that Manuka's a CPU renderer only (it used to be a GPU renderer as well, but that functionality was removed years ago).

The article is worded pretty badly, and is clearly written by someone who's had some things explained to them, and then have got a bit confused.

"Raytracing" is a bit of an overloaded term, but conventionally "Raytracing" for graphics meant a serious of "raycasting" events, and "Whitted" style was a technique which could approximate reflective and refractive materials fairly accurately (as long as you modelled the fresnel effect and absorption) in a recursive style. Modifications on top of this are also to do limited indirect rays for global illumination and this was used a bit (in film/CG VFX in hybrid renderers like PRMan pre 19), but doing global illumination this way was pretty slow and didn't scale well (an exponential branching factor at each bounce). So technically, the article is sort of correct on this point, as Pathtracing is more smart about how it handles the full rendering equation of "all" light transport simulation, and is faster than Raytracing for high fidelity (i.e. global illumination, area lights), due to its stochastic nature of sampling multiple dimensions of lights, surfaces, volumes, etc across many samples per pixel.

Pathtracing does take reflection and refraction into account, but generally (there's a technique called 'splitting', which sort of branches the paths to make it more like 'Whitted' raytracing, but ignore that for now) it relies on "importance sampling" to make smarter decisions, based off the material response (diffuse, glossy, reflective, refractive), which guides the direction of the next ray off the previous surface. This generally means that due to the "random" nature of pathtracing sampling (it uses monte carlo random sampling), predominant lighting is generally more efficient, although things like caustics, SSS and indirect illumination can still be very noisy as they're hard to sample and can take thousands of samples to resolve to "clean".

There are other techniques like Russian Roulette to kill particular paths which don't have much throughput and/or light contributions, which can speed up renders as well, and I think is what the "dumping most or all of the secondary ones doesn't affect things as much as one might think." part is referring to.

Is it me reading it wrong, or does the second paragraph of the "Impact" section not match the numbers from the diagram below it? It seems they're offset for the generations?

I'd personally argue ROCm is much more of a mess than CUDA: in many situations, CUDA code can be compiled once, and then run on multiple generations of cards (including future ones once drivers exist) and you have the option of shipping PTX code which can (normally) do the same.

ROCm builds are effectively hardware-specific (and officially Linux-only).

What are you talking about?

Why is a decade needed? The forum.dev domain name in question was registered a year ago on 2021-12-06...

The "more" is surely whether they're premium or not, which is what Op was responding to.

I own several non-premium .dev domains with namecheap, and with namecheap they're $16.98 per year to add new years.

I have some .dev with namecheap, and it's showing me $16.98 to add a new year for all of the ones I have, and I can go up to 9 years (only 8 for one of them interestingly), so I don't think this is all .dev domains, likely just premium ones.

Fairly well, Intel's Embree raytracing kernels have support for Xeon Phi, although going more than 8-wide with incoherent rays (i.e. pathtracing) starts to require more and more sorting to batch things up for decent utilisation...

JPEG's technically limited to 64x64k dimensions per the spec (65500 pixels with libjpeg and libturbojpeg), so if you want arbitrary software to be able to open images in that format, you'd be limited to that...

OpenEXR (designed for, and used by the VFX industry) supports dimensions up to int32 = 2 billion, but is a float16/float32 pixel format only (It can do int32 for IDs, so technically you could multiplex/combine/bitshift 8-bit values into one int32 if you really wanted).

Yeah, I haven't used ICC for 7 years now, but at the time it was much better than clang/gcc at keeping SSE/AVX intrinsic types in registers through function calls (i.e. clang/gcc used to spill out onto the stack and re-load), and things like this in the article.

Sure, but that (we do it) happens currently with C/C++ and signal handler traps which gather the callstack and collate them: the issue isn't usually that we don't know the crashes aren't happening or having the call stacks - the issue is hacky code that was written for one purpose is now being used for other things it wasn't designed for (because it is useful to artists, despite its limitations), and there isn't the time to go back and write it properly for the new expanded use-case. That's my point: a new safer language isn't going to improve much in this area without more development time provided to write better code, given the time constraints are going to be the same as they are currently.

That's security of the generic infrastructure the code's running under though is it not? It's not security of say CUDA kernel code being executed on a GPU?

I'm talking about the actual HPC algorithm code heavily priortising performance (or in some cases memory efficiency), at the expense of pretty much everything else (other than correctness, obviously).

At least in VFX, at the high-end Maya's only really used for modelling/UVing/layout now, other apps have taken over the rendering/lighting side of things...

But anyway, in my experience a lot of the crashes are often due to quickly hacked together plugins for the various DCCs written for artists, that don't have good error checking or testing, and it's not completely clear to me how that situation's going to improve that much with something like Rust, if the same programmer time constraints are going to exist in writing them: i.e. I think it's very likely people will just unwrap() their way to getting things to compile instead of correctly handling errors, so it will be the same situation from the artists' perspective: technically it may be a panic rather than a segfault, but from the artists' perspective, it will likely be identical and take the DCC down.

In the HPC / offline graphics / simulation world, there's lots of things like sparse arrays / grids, where you index into compacted grids and iterators wouldn't be that practical in that scenario (i.e. one single item, although for things like filtering with surrounding cells they can still be useful sometimes), and bounds checks do make a bit of a difference there (it's definitely measureable above the noise threshold), and due to the random nature of the data, the branch predictors don't help avoid the overhead.

Sure, but then there's things like HPC / offline graphics / simulation (VFX/CG), where performance is the end-all concern (or memory efficiency sometimes at the expense of CPU time), and security isn't a concern at all there, with lots of things like random index lookups into sparse arrays / grids, etc. I know for a fact that bound checks do make a bit of a difference there, as the data's random, so the branch predictors are close to useless in that situation...

Seriously!?

I'd argue it could be termed "what-aboutism", but I personally fail to see how that matches my definition of "lashing out"...

Why's it "unjustified"? Surely "trust" is the key issue here, so clearing up what may or may not have been written and what happened with correspondence and views would be key I would have thought.

Where are you seeing her "lash" out? I can't see anything I'd describe that way in the (original) thread...

Note: That analysis (ELA) only really looks at gradient/diff of compression artefacts in pratice, so if you losslessly edited the original from the RAW source at full float32 (say in Nuke or something which supports full precision workflows) and then exported to another file, that wouldn't show anything.

In other words, it's mostly only good for detecting if a JPEG (with compression artefacts) was edited and saved to another JPEG, although even then you can work around it to some degree by saving at similar chroma and compression qualities if you know what you're doing.