It's still relevant. Think of UV coords for example. You might not want to waste space and store it as a float2, so you store it as 2 uint8 instead as an optimization and set the normalize flag so that you will get [0, 1] range instead of [0, 256] in the program.

It might also be good to remember that OBJ is not a very good format for certain things. It supports indices per stream, where most graphics API:s indexes all steams by the same index. This can complicate reading code a lot, especially if you want to us as little memory as possibe.

Well, of course it is triangles. The question is how big they are and if they will look sane in a curvelinear mapping. your triangles will have to be something like 3-5 px big in the rendered reflection map to not look distorted. On single pass environment map: Microsoft has a sample in the DirectX SDK on how to do it with D3D10/11. For GL you can use multilayered framebuffer attachments and then set gl_Layer in your geometry program to output geometry to different cube sides.

This is probably an error inside the Q3VM, which is a byte code interpreter/JIT. Can you rebuild the game code as DLL:s instead of Q3VM and run that? vm_cgame 0, vm_game 0 and vm_ui 0 in your config to use native DLL:s instead of byte code.

You don't have any position information in your vertices? Sorry if this is not applicable since I don't know XNA.

Correction, not one drawcall. But you don't have to render each face separately.

It depends a bit on your geometry complexity. Your whole scene needs to be made of very small triangles, since that is what the graphics card will operate on. Your projection matrix will only transform vertices, which means that lines will be preserved as lines, not as curves. You might be able to do this using a geometry shader or similar. Or render to cubemap as possible with GL4/DX11, where you can render your scene in one drawcall.

While mesa might be a good read to learn how the rendering pipeline can be implemented, it might not be the best way to learn about how the hardware actually works. A good 3D pipeline primer like "Computer Graphics with OpenGL (Hearn&Baker)" will probably give you the same with better explanation.

@Green Code A lot of times the driver is optimized for a special case, where you only have one accelerated app running. The might be some internal scheduling problem you are hitting, or the driver might just go into panic mode and do everything "safe" for one of your apps (seen that happen before when using multiple context in one app). GL drivers (and 3D drivers in general) are quite fragile and you have to be careful in hitting just the good/fast paths. I would suggest using only a single context if you are not really carefull about buffer management. And render to back buffer from one only.

Seems sane. I don't know XNA so my answer only contains platform agnostic info.