citra-canary/externals/glad/Readme.md

These files were generated by the [glad](https://github.com/Dav1dde/glad) OpenGL loader generator and have been checked in as-is. You can re-generate them using glad with the following command:

```
python -m glad --profile core --out-path glad/ --api "gl=4.3,gles2=3.2" --generator=c
```

You can also generate the source using [this site](https://glad.dav1d.de/):
1. Select '4.3' for GL, '3.2' for GLES2, and 'Core' for Profile.
2. Input the currently supported extensions from [here](https://github.com/citra-emu/citra/blob/master/externals/glad/include/glad/glad.h#L9), plus any new required extensions.
3. Click Generate and download the generated source zip.
4. Unzip the new source over the current glad source files.
Replace the previous OpenGL loader with a glad-generated 3.3 one The main advantage of switching to glad from glLoadGen is that, apart from being actively maintained, it supports a customizable entrypoint loader function, which makes it possible to also support OpenGL ES. 2015-08-30 06:37:42 +00:00			`These files were generated by the [glad](https://github.com/Dav1dde/glad) OpenGL loader generator and have been checked in as-is. You can re-generate them using glad with the following command:`

			```
Frontend PR fixes (#6378) * citra_qt: Check if renderer is null * core: Fix dynarmic use-after-free error * bootmanager: Add current context check in DoneCurrent * Loading a save state would destroy the frame dumper class, which contains a shared context. That context would call DoneCurrent without checking if it was actually bound or not, resulting in crashes when calling opengl functions * externals: Correct glad readme * common: Log renderer debug setting * citra: Make lambda lower case * Consistency with review comments on the PR * video_core: Kill more global state * GetResolutionScaleFactor would be called somewhere in the renderer constructor chain but it relies on the yet unitialized g_renderer, resulting in crashes when the resolution scale is set to auto. Rather than adding a workaround, let's kill this global state to fix this for good 2023-03-30 11:24:49 +00:00			`python -m glad --profile core --out-path glad/ --api "gl=4.3,gles2=3.2" --generator=c`
Replace the previous OpenGL loader with a glad-generated 3.3 one The main advantage of switching to glad from glLoadGen is that, apart from being actively maintained, it supports a customizable entrypoint loader function, which makes it possible to also support OpenGL ES. 2015-08-30 06:37:42 +00:00			```
video_core: Fix fragment shader interlock usage on OpenGL. (#7144) 2023-11-10 21:14:52 +00:00
			`You can also generate the source using [this site](https://glad.dav1d.de/):`
			`1. Select '4.3' for GL, '3.2' for GLES2, and 'Core' for Profile.`
			`2. Input the currently supported extensions from [here](https://github.com/citra-emu/citra/blob/master/externals/glad/include/glad/glad.h#L9), plus any new required extensions.`
			`3. Click Generate and download the generated source zip.`
			`4. Unzip the new source over the current glad source files.`