Do you have the most recent version of your video card drivers installed?

Quote:Original post by Tubos
EDIT:
Ok, it was my fault. I've overwritten more than the locked area.

Aha! You have discovered a cardinal sin of D3D...if you want a one-way ticket to constant reboots, just do some naughty things with buffer pointers. I'm not quite so sure why it's so bad, but it is certainly a driver-level problem when it happens.

Quote:Original post by circlesoft
Aha! You have discovered a cardinal sin of D3D...if you want a one-way ticket to constant reboots, just do some naughty things with buffer pointers. I'm not quite so sure why it's so bad, but it is certainly a driver-level problem when it happens.

My understanding is that it's not a regular pointer. Normal 32bit/Win32 pointers can address 4GB of memory - but that doesn't include the VRAM.

Thus you have a "staging area" of sorts that is addressable via the CPU and GPU (albeit, with some driver intervension). The exact mechanics are unknown to me (or anyone?), but it's not normal RAM. You're returned a pointer to a piece of memory that you can write to (from the CPU) and that the GPU (and/or driver) can upload to it's local VRAM.

It's for this reason why it seems that you can get the same pointer for multiple independent Lock() calls. Check it out via the debug sometime [wink]

As a general point, the OS will stamp on you if you write out-of-bounds, especially in the current world of security-conscious operating systems. In this case, where you're talking about "fragile" memory between kernel mode OS and drivers and user mode applications and physically seperate hardware it's a lot easier to really mess things up [oh]

hth
Jack

Quote:Original post by jollyjeffers
Thus you have a "staging area" of sorts that is addressable via the CPU and GPU (albeit, with some driver intervension). The exact mechanics are unknown to me (or anyone?), but it's not normal RAM. You're returned a pointer to a piece of memory that you can write to (from the CPU) and that the GPU (and/or driver) can upload to it's local VRAM.

Aha that makes sense...the other week, I was new'ing a locked pointer (don't ask, it wasn't very simple [grin]). Suffice it to say, it only took me a few reboots to find it [wink]

Quote:Original post by jollyjeffers
The exact mechanics are unknown to me (or anyone?), but it's not normal RAM. You're returned a pointer to a piece of memory that you can write to (from the CPU) and that the GPU (and/or driver) can upload to it's local VRAM.

Locked vertex buffers will quite often be in AGP memory. Thus today this post is sponsored by the acronym GART.

GART = Graphics Address Re-mapping Table

And here's something someone else prepared earlier [smile]: http://www.intel.com/cd/ids/developer/asmo-na/eng/20410.htm?page=1

With local video memory (on card rather than AGP or UMA), similar stuff goes on, but there's a lot more vendor specific magic such as what goes on with 3DLabs' virtual texturing.


To get more context it's probably also worth understanding a little about how virtual memory works on x86 platforms (i.e. the difference between real and protected mode and the meanings of a few key acronyms: TLB, and PAE).


Deliberate over simplification: Touching addresses of a page outside of the mapped range of addresses gives you a page fault; if that page isn't known about by the virtual memory system or any other interested parties (device drivers etc), you get a page fault exception; if the exception isn't handled by the program which caused it, and the environment is ring3/user mode, you'll get a message box from Windows and the program terminated; if the environment is ring0/kernel mode (inside a driver or the kernel) or Windows isn't playing nice that day, you'll get a blue screen/reset. Sometimes the difference between a handlable exception and a BSOD when you access outside of a locked buffer is dependent on how nicely the device driver copes with 'unexpected' things.