Earlier quoted context omitted.
LV2 is invite only on Azure, eg. not generally available.
Off-topic but eg = for example, ie = in other words.
Thanks, I always mix them up.
AMD Discloses Initial Zen 2 Details
191–200 of 207 posts
Re: AMD Discloses Initial Zen 2 Details
#192Earlier quoted context omitted.
For a gamer, Nvidia's latest card offering is vastly disappointing. Technology that is not there and won't be there for maybe next 6 years (if they stick to 3 year release cycle), offering some shiny surfaces at best, at massively increased price. I really hope AMD will come with some good cheaper competition. Gamers want fast framerates, high polygon count, high textures much more than some currently-useless raytrac…
I don't get the ridiculous pricing of the current generation of nVidia chips, either. But this generation of hardware is at the same time an important step towards getting rendering algorithms that have vastly superior quality while having a much simpler structure. I know that anybody that works on high quality real time renderers and knows what they are doing wants this switch to happen.
Heck, I've only read papers about most rasterization based "realism" tricks and I want this switch to happen. Polemically speaking, current realtime rendering pipelines are based on sprite rotoscalers and the end user being too busy to notice the errors. Raytracing is based on how light works.
Re: AMD Discloses Initial Zen 2 Details
#193Anyone know why we aren't seeing Intel/AMD go the 'ultra-wide' route that we've seen in ARM processors? (Apple's in particular) e.g. we've seen Apple's A12 processor expand ALU's from 4->6 and what seems like a strong focus on cache latency and these changes seem to be rather beneficial in real code. Why aren't we seeing the same from Intel / AMD? As someone whom isn't particularly well informed on the topic my guess…
Instruction set and the number of registers visible to the programmer influence the practical limits to issue width. AMD64 (x86_64) only has 16 general purpose registers, so there are limits to how many instructions could possibly execute at one time. If I recall correctly the ARM ISA has 32 registers, so there is potential for a lot more data sitting there ready to do something on any given cycle. There are limits i…
Only somewhat true. There is register renaming which increases the size of the virtual register set. rax assigned to in line 1 can be a different virtual register from rax assigned to in line 5. AMD and Intel should both be very good at exploiting it to the limits, they had to in their superscalar 32 bit x86 designs :)
Re: AMD Discloses Initial Zen 2 Details
#194Anyone know why we aren't seeing Intel/AMD go the 'ultra-wide' route that we've seen in ARM processors? (Apple's in particular) e.g. we've seen Apple's A12 processor expand ALU's from 4->6 and what seems like a strong focus on cache latency and these changes seem to be rather beneficial in real code. Why aren't we seeing the same from Intel / AMD? As someone whom isn't particularly well informed on the topic my guess…
Instruction set and the number of registers visible to the programmer influence the practical limits to issue width. AMD64 (x86_64) only has 16 general purpose registers, so there are limits to how many instructions could possibly execute at one time. If I recall correctly the ARM ISA has 32 registers, so there is potential for a lot more data sitting there ready to do something on any given cycle. There are limits i…
I've heard from a CPU designer that the CISC nature of x86 lets it punch above it's weight in terms of what you're talking about. There's a lot of instructions that don't reference any architectural registers, but get allocated physical registers (and would have architectural registers allocated when compiled to something RISC). He claimed it was about equivalent to a 32 register RISC for that reason.
Re: AMD Discloses Initial Zen 2 Details
#195Earlier quoted context omitted.
I don't get the ridiculous pricing of the current generation of nVidia chips, either. But this generation of hardware is at the same time an important step towards getting rendering algorithms that have vastly superior quality while having a much simpler structure. I know that anybody that works on high quality real time renderers and knows what they are doing wants this switch to happen.
Heck, I've only read papers about most rasterization based "realism" tricks and I want this switch to happen. Polemically speaking, current realtime rendering pipelines are based on sprite rotoscalers and the end user being too busy to notice the errors. Raytracing is based on how light works.
The literature conveniently neglects to mention how fiddly and difficult it is to implement that stuff reliably. Debugging the rendering pipeline is not exactly easy, especially when the data is not just positions and colors, but more abstract stuff. Also, there's tons of edge cases that need hacks and workarounds, crazy driver bugs etc...
Re: AMD Discloses Initial Zen 2 Details
#196Earlier quoted context omitted.
Seperating the analog logic (IO die) from the digital logic (CPU cores). Analog shrinks really bad with smaller nodes wheras digital logic shrinks really good. New process nodes get more and more expensive - especially if the node is new (bad yields etc.) So you want to get the most out of it as possible, which AMD does with this strategy. For example Zen 1 8 core chips are 213 mm2 on 14nm. On 7nm these chipse would…
I/O module is not analog, but most of your points still stand, It is mostly for increasing yields and reducing costs. With this separation they are reducing chiplet size quite a bit, so that they will have superlinear cost reduction on 7nm process.
IO is 100% analog. Slew rates, crosstalk, reflections, routing, etc. It is literary called Black Magic in EE community.
Must read "High Speed Digital Design: A Handbook of Black Magic": https://books.google.pl/books/about/High_speed_Digital_Desig...
Re: AMD Discloses Initial Zen 2 Details
#197Earlier quoted context omitted.
That doesn't really change much in all honesty; it just disables support for things like the fTPM, secure sleep states, and some communication mailbox primitives (that allow things like offloading encryption to the PSP coprocessor, through the Linux crypto API subsystem -- this is all supported in upstream Linux.) The PSP is still essential to the boot process and many probably other things (power management, etc), a…
Sources are conflicting, but the general consensus I've seen is that the Intel ME has direct access to your networking hardware, while the AMD PSP does not, and basically just exposes interfaces to the CPU. If accurate, this is a significant functional difference as far as I'm concerned. But, what's the old saying again? "The only truly secure system is one that is powered off, cast in a block of concrete and sealed…
And PSP also taking part in the memory-training process during the boot AFAIK. So you can't disable it completely.
Re: AMD Discloses Initial Zen 2 Details
#198Earlier quoted context omitted.
I/O module is not analog, but most of your points still stand, It is mostly for increasing yields and reducing costs. With this separation they are reducing chiplet size quite a bit, so that they will have superlinear cost reduction on 7nm process.
IO is 100% analog. Slew rates, crosstalk, reflections, routing, etc. It is literary called Black Magic in EE community. Must read "High Speed Digital Design: A Handbook of Black Magic": https://books.google.pl/books/about/High_speed_Digital_Desig...
I am not sure our definition of analog are same. Are you claiming that gigantic chip shown in the zen 2 picture is an analog chip?
Re: AMD Discloses Initial Zen 2 Details
#199Earlier quoted context omitted.
The hardware raytracing support is a huge step in the right direction for real time graphics. The shaky jenga tower of hacks on top of the rasterization pipeline that is in the current generation of rendering engines is barely sustainable. Fast raytracing provides an alternative that is much closer to the actual physical model of light transport in the real world and does not require as many nasty approximations and…
For a gamer, Nvidia's latest card offering is vastly disappointing. Technology that is not there and won't be there for maybe next 6 years (if they stick to 3 year release cycle), offering some shiny surfaces at best, at massively increased price. I really hope AMD will come with some good cheaper competition. Gamers want fast framerates, high polygon count, high textures much more than some currently-useless raytrac…
Honestly, once we have a suitable HMD (aka. VR goggles), we can use a cluster of raytracers to experiment with actual photorealistic reality.
My previous best guess would have been a clustered version of Luxrender, but most recent projections of mine yielded ~20MW of current-gen CPU cluster (with a hint of GPU (about 3:1 electrical CPU:GPU) to offload ray intersection for a 2~3x speed boost) as what would be needed to feed a display that can reach the far end of uncanny valley as far as the visuals themselves go.
This would be _expensive_ and quite likely considered a useless waste of computing, but I seriously think we should try to get to the point where we can do this. And it truly requires ray tracing to handle the vast amount of detail the scene would require. Also testing scales much better down to a workstation for photorealism than for textured and shaded polygon technology.
The main reason is just that most of ray tracing is parallel, save for sequential tracing of each individual ray. The result is that much more of the behavior is scale-free which enables you to test materials much quicker/more interactively than with shaded polygons. The other part of that is how a material's behavior doesn't depend on other/nearby objects as much, so you can mock those better and have few surprises as far as their interaction is concerned.
Luxrender specifically was used years ago for such things as rendering imaged for a iirc. perfume bottle catalogue, as it was easier to specify the material properties and adapt for the colors/opacities and label prints than to get regular, symmetrical photos from a photographer in a studio. The requirement was that the realism allowed skipping a disclaimer about the images not being photographs. And that implies confidence in the mathematical models used in the "simulation".
RTX cards might allow porting Luxrender in a way that retains it's spectral treatment that actually physically simulated a dispersive prism generating a rainbow from a ray of white light, without more than specifying the dispersion of the glass. It goes without saying that such effects are inherently very noisy, but there might be ways using automatic differentiation (c.f. Julia (language)) combined with advanced numerical integration to make use of calculus to reduce the noise in individual samples.
If anyone knows about attempts to combine Metropolis light transport (MLT) with automatic differentiation or just about a more concrete idea to incorporate advanced numerical integration with MLT, or a potentially suitable MLT implementation in Julia, please let me know, i'd like to check it out and actually consider it a suitable "toy" project for learning Julia. The ease of efficient GPU use from this high level just allows so much flexibility in e.g. complex material node graphs getting handled with no extra work on the integrator then.
Re: AMD Discloses Initial Zen 2 Details
#200Earlier quoted context omitted.
For a gamer, Nvidia's latest card offering is vastly disappointing. Technology that is not there and won't be there for maybe next 6 years (if they stick to 3 year release cycle), offering some shiny surfaces at best, at massively increased price. I really hope AMD will come with some good cheaper competition. Gamers want fast framerates, high polygon count, high textures much more than some currently-useless raytrac…
Honestly, once we have a suitable HMD (aka. VR goggles), we can use a cluster of raytracers to experiment with actual photorealistic reality. My previous best guess would have been a clustered version of Luxrender, but most recent projections of mine yielded ~20MW of current-gen CPU cluster (with a hint of GPU (about 3:1 electrical CPU:GPU) to offload ray intersection for a 2~3x speed boost) as what would be needed t…
Your power estimates are off by a factor of ~10 with current technology. Current DGX workstation deliver a much higher speedup for ray scene intersection than 3x.
MLT is not used for animations because it is temporally unstable in a perceptually unfavorable way: the artifacts are more blotchy than noise while the human vision is more tolerant to noise. Recent developments around temporal MLT should mitigate that, but these require you to render multiple frames simultaneously. Thisnmakes them unsuitable for real time applications.
Also, the thing about MLT/bidirectional/unidirectional pathtracing is that there is no universally best method. All of then have weaknesses. There are examples where each method is worse than the others in an equal time comparison.
The best performance improvements that you can get with any of these Monte Carlo methods are always based on improved strategies for drawing the samples (importance sampling, QMC). Incorporating non-local information for local importance sampling will be the next big thing.
As for color noise: it is an undesirable artefact, but if you importance sample the spectral color response curves for the human eye (or your display device) correctly, then the spectral noise vanishes at least as fast as the other sources of noise in your scene.