Virtual Memory on P10 and the future

[alexsok]

After reading tons of info about "Virtual Memory" employed in P10's architecture in various places, including here:
http://www.beyond3d.com/articles/p10tech/index.php?page=page4.inc

I realize the importance of this and why John Carmack & Tim Sweeney have requested this in hardware for a long time and how important this is for Longhorn, but what possible cons & prons does it have?

As far as I know, R300 isn't capable of that and we don't know enough about NV30 to make a conclusion, but how important is this to the future progress and do u think there is a chance NV30 might be capable of that as well?

I know that P10's architecture is unique and differs from the rest, but since this seems to be such an important feature for two of the best programmers, I thought it was worth bringing this up.

Any info and opinions are highly appreciated!

 

[KimB]

It appears that the main thing that sets the P10 apart is that it has virutal memory for all buffers. To me, this means that the P10 should be capable of infinite-length shader programs, as well as, say, writing to a pbuffer in system memory.

Today, modern video cards have a similar thing for textures, but it's probably not nearly as efficient. I believe the Kyro series does have fully virtual memory for textures, however (the benefit being it doesn't need to transfer an entire texture if only a piece is needed).

 

[oNe22]

(the benefit being it doesn't need to transfer an entire texture if only a piece is needed).

AFAICR r300 is capable of it, too.

 

[KimB]

But we know that the R300 doesn't have virtualized program memory. Presumably, the currently-executing fragment/vertex program always fits entirely within on-chip caches.

 

[alexsok]

But we know that the R300 doesn't have virtualized program memory. Presumably, the currently-executing fragment/vertex program always fits entirely within on-chip caches.

That leaves us with possibility that NV30 might have virtualized program memory, especially since the good words Carmack had spoken of NV30.

It's a rather great feature of virtualized program memory that the texture could be fit in there even if it's size is bigger than the size of the local memory!

 

[KimB]

I don't believe that the NV30 will have virtualized program memory either.

However, yes, for large 3D texture for offline memory, I would think that virtual memory for at least textures would be a necessity. I do wonder if any of these next-gen cards will be able to take off for offline rendering? Could be interesting...

 

[Snyder]

That leaves us with possibility that NV30 might have virtualized program memory, especially since the good words Carmack had spoken of NV30.

I doubt that. If the NV30 had it, you would have found at least some remark (and a flashy trademark ) in the CineFX papers.

 

[KimB]

I doubt that. If the NV30 had it, you would have found at least some remark (and a flashy trademark ) in the CineFX papers.

Virtualized memory needn't neccesarily be visible to the developer, however. Did nVidia release the aniso/FSAA specs on the NV30, after all? Why would they release specs on memory management, then?

Regardless, I think the program length limitations speak for themselves. If there are limits, there's not virtualized program memory.

Update: It might not be a good idea to make pixel program memory virtualized, but it seems necessary to make vertex program memory virtualized. After all, it is probably actually more efficient to do multipass while keeping the entire program within on-chip caches for the fragment programs than it is to just have incredibly-long fragment programs that spill over into video memory.

If anybody finds a way to "multipass" the vertex programs, then that too will probably be better than just large programs that spill over into main memory, but I don't see it happening (would require massive on-chip caches).

Additionally, why are huge programs that spill into main video memory potentially bad? The main reason is that since the instruction lengths are at least 64-bit, it would just cost a whole heck of a lot of memory bandwidth to keep loading the vertex/fragment programs from video memory.

Then again, it may be beneficial to have the option for virtualized program memory, for the purpose of allowing the compiler to optimize speed (For example, it might be better to, say, use video memory for a fragment shader that overflows by, oh, 24 instructions, instead of doing a second pass, possibly resulting in redundant processing, more video memory usage, etc.)