3902628e35
There is some logic in here for 2.0 as well, just as a "as long as I was looking at the specs", but only 1.0 is really supported. This seems to resolve the bug where some GPUs weren't advertising correctly that they had vertex array object support, by checking for both extension names (with and without "GL_" prefix) Of note, this saves about 18 Kb (5.5 Kb gzipped) of code size by compiling out the unneeded GLES checks/functionality. Bug: skia:8378 Change-Id: I773bf4dbf231b991051d2a9f640b8047a9010e7d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/203461 Commit-Queue: Kevin Lubick <kjlubick@google.com> Reviewed-by: Brian Salomon <bsalomon@google.com> |
||
|---|---|---|
| .. | ||
| gen_interface.go | ||
| interface.json5 | ||
| Makefile | ||
| README.md | ||
| templates.go | ||
GrGlInterface Autogeneration
Background
At a high level, the first three steps of making a GrGLInterface (a generic way to interact with a GL-like GPU) are:
- Assemble: Copy a set of function pointers into the struct
- Validate: Make sure the function pointers advertised actually exist.
- Capabilities: Compute what fast/slow paths are enabled based on the functions in the struct (GrGLCaps, for short)
Autogeneration
The first two steps have been automated with a table-based generation script located in this folder. The table is in JSON5 format (like JSON, but with comments). O
Once edited, the Assemble/Validate code can be re-generated by running
make generate in this folder.