[LoSboccacc]

when you do a release on a texture object, when the context is destroyed, when the glDeleteTextures is called.. you just have to enumerate it all, but eventually all functions are passed to the graphic drivers to be translated into gpu operations.

[pandaman]

It's as same as saying that a HDD driver can zero deleted files and delete temporary files when a process is killed because it translates API calls into HDD controller commands.

[LoSboccacc]

The comparison is apt because it would be exactly like the TRIM operation, retrofitted into the protocol for supporting drivers.

[pandaman]

So, in your opinion the driver issues TRIM, not the OS? Then it would be possible to get it on, say, Vista with a driver update, would not it?

[LoSboccacc]

Yes, the idea is that the manufacturer is in the position of knowing the most efficient way to talk to it's gpu and the driver knows everything it's happening memory wise. It'd be interesting to have a prototype done in some open source linux driver. Tbh, I'm probably not good enough for that.

[pandaman]

So why there is no TRIM support in Vista, or in Win7 for NVMe? Vista and Win7 use the same drivers, JFYI.

[LoSboccacc]

sorry missed 'So, in your opinion the driver issues TRIM, not the OS' from the previous reply. I never said that and that was not my point

my point was that an optional post delete cleanup feature was added to the protocol ready to be used, which is a perfect example on how to evolve long term features. then I said the post cleanup feature for the GPU should sit on the driver, since the GPU driver is the one knowing how to talk to the hardware, as there is not a shared protocol between boards (except vga modes etc but those contexts are memory mapped and os managed) and knows when a clear is performed, since all operations go trough it.