Intel ARC GPUs, Xe Architecture for dGPUs

It probably was, I've wanted a Vega since Siggraph 2019 when I attended the Capsacin event thingy.

"Collecting" reasons? Mebbe we could work a trade, I have an R300 signed by Terry Makedon and a Gemini that doesn't work.

(Nah, I can't give up things like that either. I DO get the collecting thing. )

 

Gamers Nexus hands on with the Intel Xe DG1:
We Got an Intel GPU: Intel Iris Xe DG1 Video Card Review, Benchmarks, & Architecture - YouTube

 

It’s really quiet here, what happened?

 

Not a lot of leaks

 

I know almost 3 months ago the DG2 was right around the corner.

It must be a really long corner..

 

Regarding Sampler Feedback:
https://software.intel.com/content/...back-texture-space-shading-direct-storage.pdf



More from GDC21:
https://software.intel.com/content/www/us/en/develop/events/gdc.html?linkId=100000054980663

 

Some principles remind me of VRS ?

 

Their driver team has still years of up bringing to do ...

No developer ever tests their games on Intel HW and people just plainly expect their games to work there. A developer one time intentionally released a broken application that crashes on Intel HW and their excuse was that they don't support Intel graphics. In the recent past it was all too common for them to introduce hack and workarounds in their drivers just for some games to be able to boot up. Out of all the graphics vendors, it is intel who faces the most amount of injustices by far compared to the others ...

As a relief they won't have to focus so much on legacy hardware anymore prior to Xe and concentrate making hacks/workarounds on their current driver stack for their upcoming hardware ...

 

DG2 being Q1'22 and meh and PVC being shit and H2'22 have something to do with it.

 

Yeah it's like VRS on steroids. VRS is a spatial optimization that uses shading results from nearby pixels in the same frame. Texture space shading reuses shading results from the current or previous prior frame. What I dont get is how does TSS decide that it's safe/accurate to reuse an old shading result if the view or lighting changes.

 

Very interesting, so the texture space shading part of Sampler Feedback can be emulated in software, but hardware is 3.1x faster. Texture Space Shading 3DMark test is coming soon (my hope was it was about the streaming part, but I guess without DirectStorage that doesn't make much sense right now)

Their results with Sampler Feedback Streaming are pretty interesting as well. 350 GB assets fit within 230 MB of physical memory? That's bonkers! This technique truly is a game changer.

 

With texture space shading or object space lighting, our goal is to apply shading before rasterization. What is common in both deferred and forward renderers is that shading occurs during or after rasterization ...

The most naive solution would be is that you shade every texel in object space (texture) but hopefully not. A better solution could involve using feedback maps (sampler feedback) to record what texels are being requested and we can limit our expensive computations to the requested texels. Other solutions calculate the estimated the projected area of the objects and break their texture down to 8x8 tiles each of which can be individually requested for shading ...

 

Texture space shading was used in pure s/w in Ashes of the Singularity (and another couple of games on that engine) and was promoted as a h/w feature of Turing at its launch.
SFS is an extention on this idea I believe which was added to DX eventually.

 

What do you mean with 'SFS'?

Do we already know anything about Intel support regarding raytracing and mesh shaders? I think neither is confirmed yet?

 

https://microsoft.github.io/DirectX-Specs/d3d/SamplerFeedback.html

 

From here: https://software.intel.com/content/...-intel-graphics-today-and-into-the-future.pdf

 

It look like they will also support 4X4 degredation with VRS Tier 2 based on the later slide there much like Turing and Ampere. Some nice little hints here!

 

Interesting that they recommend using TraceRay over inline invocations, I wonder why.
AFAIR AMD recommends the opposite? And Nv is basically do whatever here.

 

From Microsoft: "The basic assumption is that scenarios with many complex shaders will run better with dynamic-shader-based raytracing. As opposed to using massive inline raytracing uber-shaders. And scenarios that would use a very minimal shading complexity and/or very few shaders might run better with inline raytracing. Where to draw the line between the two isn’t obvious in the face of varying implementations. Furthermore, this basic framing of extremes doesn’t capture all factors that may be important, such as the impact of ray coherence. Developers need to test real content to find the right balance among tools, of which inline raytracing is simply one."

If AMD has a different recommendation and their hardware always prefers inline then it could mean that they handle uber shaders better or their dynamic scheduling just isn't up to the task.

Was this meant to answer the question on when cached texels from prior frames are used/discarded? I don't think it does.

 

The concept behind TSS/OSL is that texels that don't get requested for shading can all be used to cache the results ...

If we take dynamic lights as an example then it's projected area in object space will be used to generate shading requests on those specific texels therefore prior results on the same area get implicitly rejected ...