5 ms·
What if you want to modify the color on vertex 473? What position in the file do you seek to? A dumb file interface would force the client to simulate the inter
by fjsolwmv 8y ago
What if you want to modify the color on vertex 473? What position in the file do you seek to? A dumb file interface would force the client to simulate the internal state of the GPU engine so it could reverse engineer the necessary commands to modify the state.
- hawski 8y agoGP suggested a command queue. So the answer is that then you send another message to modify the vertex or however else you would prefer. I would imagine that VBOs could be represented as additional files and then they could be mmapped. A file is a byte stream with some metadata - i.e. permissions. With such an API you can really do anything.
- tom_ 8y agoYes, I suppose maybe you'd probably have a file per VBO or whatever. Create a dynamic one: it's like a pipe, write- and append-only. Create a static one: it's like a file, and you can mmap it (like glMapBufferData), or fseek+fwrite to it (like glBufferData), and maybe fseek+fread from it too (because why not). The command queue would be a write- and append-only pipe, containing of state setup commands and rendering, in some format that could be efficiently transformed by the driver into the actual commands that would get sent to the GPU, since this hypothetical queue would probably be GPU-agnostic. (I think this was how D3D9 worked internally, and that may still be true for more modern versions...) (You wouldn't have commands for modifying buffers. That would be just something you do yourself by accessing the buffers. As the creator of the buffers, you know where the data is inside them, so you'd just replace the data in question with new stuff.) Anyway, even if in practice this wouldn't be optimal, it could probably be made to work well enough. A file-based approach is at least not ridiculous to imagine.