Recent content by frogblast

OpenGL is there and works. You can use it, and there is a macro to silence the compiler’s OpenGL depreciation warnings when building.

I'd say noise reduction is required: nothing I've seen so far even on Turing suggests effective ray budgets of more than low-single-digits per pixel. DXR provides API for the BVH and allowing implementations to sort/regroup the shading tasks, but DXR does not provide anything for denoising...

Any single process uses more memory in LP64 mode, but if all 3rd party processes move to LP64, overall system memory usage should be substantially reduced. Today, if you have two active processes using different architectures, you keep the long tail of linked libraries in memory for both...

Interesting! Where do you find that in the sources?

The nvidia demo was using wired Ethernet to avoid conference wifi issues (likely through a USB/Ethernet adaptor)

AMD's market cap at $1.33 billion is now below Imagination's at US$1.8B, and far below ARM's at US$15B. That is a reversal of fortune that would have been inconceivable 5 years ago.

Nope. I think Imagination stopped doing OIT way back sometime in the dreamcast timeframe. Current Imagination devices will always blend strictly in submission order, just like every other GPU (and like OGL/D3D mandate).

Once the implementation is "really low performance", why have it at all, other than to satisfy a feature checkbox? Put another way: would you rather the mobile GPU vendors produce a "really low performance FP64 implementation", or spend that time further improving the F32 path?

I wouldn't assume that just because of the technology proposals seem so odd that this is a fake. I think it's real, but that it isn't a good prediction of the final product. To me, it feels strongly like a real slide deck that was put together by product designers/marketing, before...

Not sure, but it wouldnt be representative. I'm pretty sure the Leo demo was doing a whole lot more than tiled forward shading (it also included ptex and some form of indirect lighting as I recall), which makes it hard to tell where the performance is going.

Hardware PRT and the number of texture bindings are orthogonal. A device can have a limited number of texture binding slots, even while each texture is partially resident. A BT implementation can allow a single draw call to access any number of different textures, while each individual...

Now I have to say that I'm not following. I just don't see how BT is required to implement PRT. In PRT, the hardware texture units are programmed as before, but a page fault results in an error code returned to the shader rather than a fatal fault. In BT, the very idea of a fixed array of HW...

You can use Bindless Textures (BT) as a tool to implement megatexturing/PRT, but PRT does not let you build BT. Rather than having one massive physical page image, each physical tile could theoretically be an entirely different texture. The page table could contain the BT pointer rather than...

Oh, a TBR in single buffer mode can be supremely offensive, even compared to an IMR ;) That being said, I don't think that is what's happening here. Looking at those screenshots, I'd suspect something on the texture coordinate resolution or interpolation side. Either an insufficient choice...

All iOS devices with A4 and later have supported scaling. It is already widely used to fit within the fill constraints of iPad 1.