Maybe, maybe not, hopefully not. However I was just thinking about how long it generally takes to take screen shots (or read the complete framebuffer even when not writing to disk). It creates a noticeable 'hitch' in the framerate. Depending how much space GDI elements are taking up in video memory, and how efficent the system is, reading back over AGP might be very expensive (and reading back over PCIe would just be a little bit less expensive)
Vista and SLI
- Thread starter Kombatant
- Start date
Hyp-X said:
Some research on the subject of code sizes (and more) was made back when they
started porting GCC o AMD64:
"...The code section of 64-bit binaries is, on the average, 5% smaller than code section
of 32-bit binary.
Most noticeable problem is the growth of data structures caused by 64-bit pointers. This problem is noticeable as regression in mcf, parser and gap SPEC2000 benchmarks as well as about 25% increase in memory overhead of usual desktop applications and 10% increase of executable file sizes."
Source: http://gcc.fyxm.net/summit/2003/Porting gcc to the amd64.pdf
Rather interesting. I do wonder, then, why my executables (and memory footprints) are so close to twice the size when compiled to x86_64. It may have to do with the exact instructions used, SSE optimizations, or the fact that I'm using a version 4 GCC compiler (that pdf was written against the version 3.3 compiler, close to the first version to implement the instruction set). I do know that it can't be pointers, because I don't have nearly enough of them.
Dave B(TotalVR)
Regular
Uttar said:
umm, Uttar, since WHEN has M$ been concerned about using your RAM inefficiently?
You're talking about DirectX Graphics design issues, not about hardware, driver model, or even OS restrictions.Colourless said:
OpenGL drivers on the PC have done exactly what you described for many years already, well without Vista. There is no technical reason why they couldn't.
Besides, a 128MB video card obviously has at most 128MB of resources to push back when it's "full", while I really can't imagine just how in the world a desktop UI could ever hope to fill 128MB by itself. We're not talking about massive amounts of data ever so shifting around. Even the "bad" AGP cards can read back roughly 100MB/s (see this). Make that a one second "hitch", tops, once, under absoulte worst case conditions. This may not be brilliant, but it will probably be acceptable when you hammer your system hard.
I concur that PCIe is better than AGP. But this is creative marketing IMO.
Hyp-X said:
AFAIK allocations by default on 64bit os are aligned to 64-bit boundaries. Which means that on 64bit system: struct foo { BYTE one; void *two; BYTE three; void *four; }; consumes twice as much memory as on 32bit system (32bytes vs 16bytes) when structure is aligned. And also small allocations such as HeapAlloc(GetProcessHeap(), 1) include extra 7byte overhead, because in order to maximize performance, heap alloc aligns memory to 32/64bit boundary (not to mention, that it makes volatiles much easier to use) So it's not just of pointers...
snowwhite, optimal alignment depends on the data structure used, the granularity of the memory interface and the cache lines, but not on pointer size. Your struct takes more space because both pointers are double the size now, but the HeapAlloc example will not have more overhead on a system with 64bit pointers, as long as the rest (memory interface granularity, etc.) stays the same.
Not using pointers explicitly in your code does not necessarily mean that the compiled program uses few pointers.Chalnoth said:
zeckensack said:
Are you sure OpenGL does that? Last thing I knew, OpenGL ICDs didn't have a 'just in time' system to download textures when you were about to lose context focus and in effect ran using a system very similar to the D3D Managed Pool.
Oh, definitely. There's going to be lots of added pointers from a number of the operations that I do, but I just don't see how they can add up to 90% or so of the code.Xmas said:
But, regardless, the point is that real-world applications will typically not require much larger executable size or memory footprint.
I'm pretty sure about NVIDIA and ATI drivers. In the olden days of "MiniGL" drivers it may have been considered good practice to assume that all resources are lost during mode switches, but the point was that it's not a technical necessity.Colourless said:
Think about it this way: all events that could ever cause resources to be "lost" (mode switches, new large allocations) require graphics driver involvement. You can't switch modes without asking the driver. You can't allocate a surface or vertex buffer without asking the driver. Consequently, a driver that handles any of these events can make sure that there is no loss of other resources in the process. They can simply be pulled down to system memory before any disruptive action is taken.
I don't want to dwell too much on the OpenGL vs DXG issue here, but OpenGL allows you to a)detach rendering contexts, which encompass all resources sans the framebuffer itself, tuck them away somewhere for some time and then attach them to another DC (much) later, and b)have multiple windowed applications peacefully coexist. That just works, nowadays, and the only way that it can work is because the driver teams make sure that resources are never lost.
DXG <=9 runtimes OTOH assume that resources can be lost, unless managed by the runtime, so even if the driver teams did go ahead and prevented that from happening in their own domain it would have been for naught under that model.
This really isn't all that interesting to discuss I'm afraid. It just bothered me a little that this was touted as some kind of new magic technology that only Vista can possibly have.
And as an officially recognized OpenGL proponent/fanb**, it also bothers me that this capability was never accepted as an OpenGL advantage for as long as DXG couldn't do it, but now that Microsoft goes there, people start thinking it's oh so great and they want it.
chavvdarrr
Veteran
You forget Intel 9.xzeckensack said:
Similar threads
