Paul MaudDib posted:

Based on data mining from the NVIDIA data leak,

steckles posted:

Regarding path tracing,

repiv posted:

unless we move towards "frameless" architectures where the GPU can churn on batches out of phase with the framerate, which sounds like a nightmare

SCheeseman posted:

I remember a Carmack tweet talking about a theoretical framerate-less VR OLED display that displays each ray just as it's calculated, relying on human perceptual image persistence to fill the gaps.

Subjunctive posted:

the partners could branch out, like my motherboard vendor trying to sell me cloud storage (what?)

Shipon posted:

the founders edition cards also actually look nice compared to the gaming plastic garbage the partners always put out

Paul MaudDib posted:

The partners grumble a lot but the reality is they can make and sell even triple-fan cards at MSRP, they just don't like to. Especially once the boat-freight shipments come in - all the early shipments are air-freighted and that's an additional cost. That's part of the justification for why partners get to overcharge you at launch - air-freighted rush-production cards, high demand, limited supply, whatever. But as much as they grumble about it, they actually really ought to be hitting MSRP after a couple months and they really hate that NVIDIA is twisting their arms and making them do it. A big cooler (the 600w vs the 450w) costs like $10 more in bulk according to Igor. The partners just like that because they can charge you $150 more for it.

There's this weird tension where people want more margin for partners but they also don't want to pay higher prices, but, the reality is a lot of the higher prices come from the partners gouging you. They can sell at MSRP and make a profit, even on a fancy card - they're doing it right now on 4090s. Everything above that is gravy.

Truga posted:

if it's not gigabyte offering you a gigabyte of free space i'm gonna be disappointed

steckles posted:

Anyway, a true path tracing first engine would need to be something like this: Rasterize a depth/normal buffer. Using that, spawn millions or billions of ray queries. Batch those rays based on their origin and direction. Once your batches are large enough, clip them against the acceleration structure. Where a ray enters a leaf node, add it to another batch that's queued for geometry intersection. Once a batch of leaf node ray queries gets large enough, load the actual triangles associated with the BLAS node, clip the rays against them, and batch the hit position and surface normals. Once the batches of intersection data get large enough, load the relevant textures and run your surface shaders. Spawn more ray queries as needed and put them into new TLAS/BLAS batches. After running the shaders, add the computed colour attenuation to a list that's kept per-pixel and then every frame, collapse the list to generate a final color.

Basically to do one thing at a time, keep as much in L2/L3 as possible, and make sure that every request to glacially slow video memory is as contiguous as possible and can serve as many operations as possible. This is already best practice for current rasterization workloads, it's just being taken to a ridiculous extreme. It's not the kind of thing you could easily bolt onto an existing engine, nor is it the kind of thing hardware and driver level shenanigans are going to do for you. Some developer will need to be brave enough write it from scratch. Hopefully the APIs and architectures will evolve to support such a thing, because RT as it currently exists is gonna be hard to scale otherwise.

Paul MaudDib posted:

Paul MaudDib posted:

Obviously this is tremendously expensive in transistor terms: it's not shocking at all that Intel is using the transistors of a 3070 to compete with a 3050 or whatever it is! It's an absolute ton of additional SM complexity/scheduler overhead/etc. But cache isn't going to shrink much between 6nm and 3nm, but logic is. And so all that SM complexity is going to get a lot cheaper, while cache isn't going to get much better in the meantime. That's my pet theory at least, Arc looks like a design aimed a couple nodes ahead of where it is. And it wouldn't be surprising if NVIDIA recognized the problem too - 4090 benefits from much higher clocks but 3090 had fairly poor SM scaling, and 2080 Ti wasn't really that great either. AMD had the same problem with wave64 with GCN, Fiji and Vega just didn't scale to 64CU very well, and they switched to wave32. I think at some point everyone is going to have to shrink wave size again.

To some extent the things you're talking about are orthogonal: even if you had that, it would be desirable to increase the percentage of lanes doing effective work, and increase the number of lanes doing aligned access. And an async facility is really kind of what you need for that "massively increase the number of requests in-flight" too. If you are just tossing tasks into a queue (and especially if you don't ever wait on the result!) then the scheduler can just batch up a bunch of them, slice them in some efficient ways, and run them. Iterating over the raster image and tossing off async tasks is exactly what you wanted, right? It just doesn't work without some kind of realignment facility.

Arivia posted:

Give me a gpu designed by Jony Ive. Only one display output and it’s usb-c.

Arivia posted:

Give me a gpu designed by Jony Ive. Only one display output and it’s usb-c.

Dogen posted:

Pininfarina is out of cars and into GPUs!

repiv posted:

intel are doing cool things with their architecture but unfortunately i think they're going to struggle to get mileage out of it in the real world, coming from a minority market share. it even comes up in that presentation:



they want developers to use the original DXR 1.0 model, as it gives the driver/hardware full control over scheduling, but RDNA doesn't do anything clever with DXR 1.0 so devs are encouraged to use the simpler DXR 1.1 model and handle sorting/binning manually

everyone is doing something different with their raytracing architectures, and it's bleeding into the programming model, so to extract the most performance from all hardware engines will need multiple codepaths. in practice they'll usually just do what's fastest on AMD.

steckles posted:

I think Intel's solution is a very logical way to handle the current way of doing raytracing, as an add-on to a traditional workload. Lots of tools to help ensure you've got something to work on while waiting for your ray queries to return and making sure that a stalled instruction doesn't lock up too much of the GPU. That's a smart way to do things as you'll typically have non-RT shaders to run, post processing, rasterizing new shadow maps, sampling textures, rasterizing new micropolys for Nanite, denoising, and all kinds of other things in a typical engine. When the memory required by the raytracing step gets too large though, as it would with true path tracing, all the other work you could be scheduling gets stalled because what it needs isn't in cache any more. The short term solution to that is obviously more cache, but I doubt you could ever add enough that any sort of hardware level scheduling could hope to remain tenable.

steckles posted:

Ultimately, ray tracing as it exists now on GPUs is basically rays starting in random places going in random directions needing random geometry and random textures from random places in video memory. That's just an insanely hard thing to schedule for and we're gonna get more out of reducing the randomness to start with.

steckles posted:

We really haven't even scratched the surface though and there are so many different ways we could be using visibility queries that haven't been experimented with yet. Nobody had really come up with a good LOD method for raytracing either. Intel showed a method of stochastically picking a LOD on a per-pixel basis which looked great, but would be hard or impossible to implement with the current APIs. While I'm at it, one dumb idea I had was to treat a nanite mesh as the input for an old skool finite element radiosity solver. Basically have all the patches iteratively swap radiance with each other and store it in like some Gaussian Mixture Model or Spherical Harmonic nonsense as part of the surface properties. I'm sure there would be a billion corner cases, but it'd be an interesting experiment.

Paul MaudDib posted:

100%, I said this when Ampere came out, those are fuckin sharp looking cards. That's Apple-level design language right there, you can tell exactly who their customer is: mature adults who don't want GAMERZZZ design language, just give me something that says "fast and futuristic" without being tacky. I totally bet they outsourced that to an actual industrial design house, I know BMW did some cases for Asrock etc and I bet NVIDIA went out to someone who specializes in that and had a concept done.

20 series were ok but 30-series knocked it out of the park. Personally don't care for the chrome highlights on the 4070 though. The brown on 4090 is... whatever. It's fine. 30-series were great though.

I am actually not that much of a fan of the coolers themselves though. It's hard to make a direct comparison since they're also by far the smallest cards in every generation, apart from actual single-fan mITX cards. But really the noise-normalized performance is not all that great, and they have a pretty distinct whine especially if you spin them up.

I think part of the problem is the semi-blower design. It's still a blower, it still has to spin at relatively high speed to generate a lot of static pressure. Just not quite as much as if it was pushing through the whole card.

The flow-through design is very nice. I liked it with Fury and Vega cards and I still like it now, blow-through is an aerodynamic/thermodynamic improvement over axial designs. It is unfortunate that it came just as sandwich cases took off, because it blows right into the motherboard, and it (again) happens to be an otherwise desirable card due to being a high-production-values card with great VRMs/etc on the smaller side of things. Buildzoid always has great things to say - with apologies to Scrubs it's "yeah they grab a handful of premium 70A smart power stages and throw them at the board and whatever sticks that's the dosage".

Maybe a half-axial half-blowthrough would be better than half-blower half-blowthrough. Would fix the whine problem. And it is obvious that they know it's a problem, the later FE designs tend to have "bulged" fans where it's going right into the silver highlighting because they pushed the fan size a bit. Especially with fans there simply is no replacement for displacement, bigger fans have better acoustic profiles even for a given noise level it's a lower noise.

A quad-slot partner card does better than the 2.5-slot NVIDIA card. But that's kind of obviously a given too. There's no replacement for displacement in heatsink size either.

Paul MaudDib posted:

:yea: Obviously a lot better to avoid randomness than to handle it better. But I mean, how is that really possible with raytracing given the positions and angles are essentially random?

Paul MaudDib posted:

is there a technical reason the async scheduling and reordering needs to happen on the GPU at all? If the state-per-ray is relatively minimal (position, vector, luminosity/whatever) then can't you just immediately spill to CPU, schedule/reorder, and dump over batches? Or spill certain parts of the rayspace, like spill unless it's some area or some vector-direction that is being modeled right then? I realize of course that may not be much of a useful coherence/alignment in itself since ray behavior is so random but the point is just to define some region that you're currently working on and to spill everything else until later.

Paul MaudDib posted:

On the other hand for a purely path-traced game this means that you can just partition your scene across multiple GPUs and get good scaling. And if the collective amount of VRAM is sufficient, that's fine, you don't need every GPU to hold the full queue (holding the full BVH tree would be really nice of course). Like if total VRAM can hold it all, you can totally do a multi-GCD/MCM design with path-tracing. (I think that's been remarked before, it's the reason why it works for big pixar movies and stuff too, right?)

Paul MaudDib posted:

I wonder if spilling favors L1/L2 or L3 - NVIDIA chose the former and AMD chose the latter. I’m guessing nvidia probably needed some extra for Shader Execution Reordering to work, perhaps a reason they went with that over an L3.

Paul MaudDib posted:

I wonder if AMD's thing about memory was because they modeled path-tracing (or even it's just self-evident that there's too little VRAM headroom to spill much) and they think path-tracing is going to do ironically poorly on NVIDIA's GPUs due to VRAM limitations.

Paul MaudDib posted:

That's really the money question around your objections in a practical sense I think - are we talking gigs of ray-state, tens of gigs of ray-state, or hundreds of gigs of ray-state for useful path-tracing? Obviously not too helpful if path-tracing requires people to have 128GB or 256GB of system memory even if it's feasible at a GPU level.

Paul MaudDib posted:

:yea: Obviously a lot better to avoid randomness than to handle it better. But I mean, how is that really possible with raytracing given the positions and angles are essentially random?

Paul MaudDib posted:

What would be the point of having patches swap luminosity with each other, I guess you're fuzzing... something? And that produces a statistically useful property in the rays/bounces somehow?

repiv posted:

that naturally scales up to where N neatly fills one frame interval (with enough slack for denoising, postprocessing, etc) but how to scale up to larger N without tanking the framerate or causing visual issues is an open problem

repiv posted:

you fire off N million rays and don't get anything back until they're all done, and you want N to be as large as possible for the best hardware utilization

repiv posted:

as steckles says though, for optimal hardware utilization you want a breadth-first/wavefront architecture.

8-bit Miniboss posted:

The big thing for me is the cross frame design and its PCI bracket anchoring into it that makes it one of the most structurally sound video cards to date. The 3080 FE I had was solid as is the 4080 FE that replaced it.

steckles posted:

We really haven't even scratched the surface though and there are so many different ways we could be using visibility queries that haven't been experimented with yet. Nobody has really come up with a good LOD method for raytracing either. Intel showed a method of stochastically picking a LOD on a per-pixel basis which looked great, but would be hard or impossible to implement with the current APIs. While I'm at it, one dumb idea I had was to treat a nanite mesh as the input for an old skool finite element radiosity solver. Basically have all the patches iteratively swap radiance with each other and store it in like some Gaussian Mixture Model or Spherical Harmonic nonsense as part of the surface properties. I'm sure there would be a billion corner cases, but it'd be an interesting experiment.

Paul MaudDib posted:

GPUs by BALENCIAGA

pyrotek posted:

Sure, but then the time of day and lighting in general has to be static, and reflections won't look the same no matter what. Outside of reflections that is why Final Fantasy 7 Remake looked so good and probably explains why it is taking so long to get to the next one because it is probably more open and might be weird for it not to have real-time lighting.

The 7900 XTX is a pretty good card, but stick away from the reference model if you find any still out there, and the ASRock Phantom Gaming frequently has similar issues. The full die is enabled on the XTX so there really isn't room for enhanced versions like with the inevitable Ti cards for Nvidia. I wouldn't count on a 7950 XTX for that reason. Also, the more you spend on a XTX, the closer you get in price to a 4080, and the PNY 4080 is excellent at MSRP.

Actually, looking at Micro Center, there are a few 4080s now from $50 to $100 off, and the Gigabyte Eagle is $1150 at at Best Buy. I'm glad things are finally starting to go in the right direction.

DoctorRobert posted:

You can't do night/day lighting with raster? Could swear there's games all over the place with that.

R.e. the xtx, thought AMD hosed it up the first time so it doesn't hit the right clocks and their cheaper cards later this year ought to be able to, so they could release a refresh of xtx at the same time with better clocks

R.e. the 1080ti, it was $400 maybe 5 years back, and there's no point spending 4x that for a card that still won't hold up the same way 5 years from now, given how everything-hungry the tracing trend is. Games don't look all that different with it at present, and there are hilariously few using it, from the perspective of justifying the expense

SwissArmyDruid posted:

BALENCIAGA: The Way It's Meant To Be Worn

DoctorRobert posted:

You can't do night/day lighting with raster? Could swear there's games all over the place with that.