New Memory Interface for R5x0...

AFAIK:

It makes memory addressed by the GPU able to be physically located on the GPU or in system RAM (or in a swap file, I guess). Basically, it makes memory aquiring and addressing like it is for the CPU.

The advantage is not being so confined to video RAM. It allows for gigabytes of data to be in the active set for the video card, though it does not promise exceptional performance for that (again, just like the CPU). I'm guessing the driver would manage what gets into video RAM and how long it stays there.

 

So what's Kaleidoscope?

 

Is this possible with WinXP and DX9c?

Hm, could be in it for the derived value parts launching with the R600 when longhorn arrives

 

Geez, you think you're gonna get results around here with that direct method?

See http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2222

Boy Wonder speculates it is a multi-vpu technology. Of course Boy Wonder has great sources. . but doesn't always understand them when they get to talking in simile/analogy/parables as well as some others we could name.

So this topic started with new memory technology. . .and Kaleidoscope comes up, which Anand says might be multi-VPU tech.

So, since I'm only slightly behind Digi in the "village idiot" sweepstakes with absolutely no reputation to damage for looking foolish, I will speculate that Kaleidoscope is some way to share memory between multiple VPUs so that you don't have to have, say 512MB or 1GB of video memory when you do an SLI/AFR/TLA/PDQ or whatever.

 

3dlabs has this and with earlier cards permedia 3 /glint r3 they called it vitual texturing engine(theres pdf about it) and they said in d3d(d3d 6.x) developers are given a choice whether they wanna use the virtual texture engine of the card or managing textures by themself.

 

Virtual memory on a GPU can be as transparent as virtual memory on a CPU is to applications.

Currently, the graphics driver usually does several things to do some kind of "pseudo virtual memory", i.e. it does swapping in and out manually so the overall set of textures can be larger than the graphics memory.
But "real" virtual memory will bring hardware support and much smaller granularity, meaning you don't need to swap whole textures with all mipmaps, but only those parts really need for rendering.

 

So how about this for speculation:

24 pipe card using a 256bit bus.
Thing is the gpu itself is split into 2 sets of 3 quads that can act independatly or together depending on the app. Both sets will have independant access to the memory. I think that there may be some eDRAM but not as much as others think, just enough to reduce latencies from the split core.

So in effect a one card SLI setup using one core but having the capabilities using the MAXX bridge to ....

 

If I recall correctly, the P10 has it aswell but what practial use could it have (except for what's comming in Longhorn) it's already being done in the drivers.

Xmas:
Maybe but there normally is little swapping going on between the graphics card and the ram and if it happens to be the case there is little performance hit (looking at D3’s ultra setting, only unused textures get swapped).

You still need to have all the scène data in the memory (normally not the case for workstations cards like P10 hence it's use) of the graphics card for it to render efficiently a virtualisation can only reduce latency so I don’t believe Dave is pointing at something like this.

 

Thanks for the geek-speak. I was at the "All previous consumer implementations of multi-GPU, like SLI and AFR, required 'dis is mine, and dat is yours, and you donna toucha mine, and I wonna toucha yours'" level. But I think we're going to the same place.

Doesn't mean we're right tho.

 

what the drivers (can) do alone is a far way from real virtualisation.

up until now texture swapping has been quite a stone in the developer's garden, regardless of what the dx or ogl or whatever-the-api resource manager does or does not do in this regard. that's where virtualisation steps in - the whole point is to achieve higher sustained texturing rates w/o the developer's sweat for it. look at gamecube's flipper - you think texture virtualisation was put there for longhorn?

i completely missed your point in the above

to 'only reduce latency' ? what do you think latencies are - a nuisance?

 

You missed the "except for what's comming in Longhorn".

I assume that true virtual video memory will only be possible in WGF becouse MS made a different driver model for cards without hardware support for virtual video memory & cards with HW it. So it requires a big change in the OS and into the next directx.
We don't know how far DX9 (let's forget OGL for once) supports virtual video memory but I don't recall it being one of it's features so I don't expect much.

So if true virtualisation can't be done in DX9, why would ati put it in their chips so I don't think dave is pointing to something like that.

 

Virtualization is mostly an ease of development feature, not a huge performance panacea. Obviously, you're like to keep your working set of textures fully in vidram and avoid any page to superslow system memory, no matter how fine grained. All it does is lower the penalty for paging in texels, and makes texture management easier for the developer. Still, in the vast majority of cases , you'd prefer big vidram and plopping all your textures there.

 

tell that to your publisher.

 

Could Kaleidoscope be multiple cores on a single die?

 

A GPU is already heavily parallel. A CPU isn't so far, so that makes some sense. But you could say that each vertex shader and quad on a GPU is a separate core already.

 

How about separate memory busses for frame/z-buffer and for textures?

I can remember the old 3Dlabs card having separate memory for frame buffer and for textures, like 128 MB frambuffer and 256 texture memory.

I've been meaning to start a thread about this for a while now...

Why aren't we seeing this more?

Texturing should need far less bandwith than the frame/z-buffer, so why no 256 bit 600 Mhz DDR framebuffer bus (with only 128 MB of very expensive memory) and a 64 bit 300 MHz DDR texturing bus (with 512 MB of cheap memory)?

 

Well, DUH

Isn't it obvious that Kaleidoscope is just a pair of mirrors that you place on each side of your gfx card. That way it will look like a cool SLI rig through your case window.

 

"Kaleidoscope" reminds me of lots of colors. So maybe it just means 32bit per color = SM3.0 support?

 

I'm going way out on a limb here, but a Kaleidoscope is a mix of different colors swirled together, so might "Kaleidoscope" be the ability to mix and match a variety of ATI cards together? A sort of mix&match SLI with the drivers dynamically distributing the load, possibly it would even include integrated ATI graphics?