I'll let HdkR reply more in details to these questions (as he is the author of GLExtensions), but from my understanding:
1) GLExtensions is a way to do the GL functions lookup at runtime instead of compile time. The main point of it is to be able to generate a binary that works on both GL and GL ES. This means we do not link to libGL directly at compile time, but instead we lookup the symbols from libGL at runtime.
2) As explained, no GL linking at compile time.
3) If I remember correctly, GLEW has no support for ES, and even less support for ES and normal GL in the same binary.
4) I think we also use ES for desktop versions running on ARM (Chromebook, for example), but that's a very marginal scenario. We almost only use core GL on desktop, but we want to have support for ES as well.
Now, for the more general questions:
5) We accumulate vertices/primitives as long as we can. Then, when a change is made to the emulated GPU pipeline that requires changes to the host GPU pipeline (GL settings, shader, etc.) we flush all the vertices/primitives we currently have accumulated to the GPU with the current pipeline state, and we perform the pipeline state change. So it is not predictable how many vertices/triangles are going to be sent per batch.
6) The most important shaders are the one generated by VertexShaderGen.cpp and PixelShaderGen.cpp. These files contain functions that generate shaders based on the current emulated GPU pipeline state. These shaders are generated at runtime and switched depending on pipeline state changes.
If you have further questions, you can also join us on #dolphin-dev @ freenode, it might make things quicker.
1) GLExtensions is a way to do the GL functions lookup at runtime instead of compile time. The main point of it is to be able to generate a binary that works on both GL and GL ES. This means we do not link to libGL directly at compile time, but instead we lookup the symbols from libGL at runtime.
2) As explained, no GL linking at compile time.
3) If I remember correctly, GLEW has no support for ES, and even less support for ES and normal GL in the same binary.
4) I think we also use ES for desktop versions running on ARM (Chromebook, for example), but that's a very marginal scenario. We almost only use core GL on desktop, but we want to have support for ES as well.
Now, for the more general questions:
5) We accumulate vertices/primitives as long as we can. Then, when a change is made to the emulated GPU pipeline that requires changes to the host GPU pipeline (GL settings, shader, etc.) we flush all the vertices/primitives we currently have accumulated to the GPU with the current pipeline state, and we perform the pipeline state change. So it is not predictable how many vertices/triangles are going to be sent per batch.
6) The most important shaders are the one generated by VertexShaderGen.cpp and PixelShaderGen.cpp. These files contain functions that generate shaders based on the current emulated GPU pipeline state. These shaders are generated at runtime and switched depending on pipeline state changes.
If you have further questions, you can also join us on #dolphin-dev @ freenode, it might make things quicker.