<p>Most vendor-specific extensions (particularly those of more recent vintage) are based on the particular nature of that vendor's hardware. And even if some other vendor's hardware could do something similar, emulating that functionality without actually being part of the <em>driver</em> would be, if not impossible, then exceedingly inefficient.</p>
<p>There may be specific cases where you might be able to implement something reasonably with a wrapper atop OpenGL, but most vendor extensions are too reliant on the specific internals of their hardware to make this viable.</p>
<p>Consider NV_texture_barrier. It was technically an NVIDIA extension, but it was widely implemented by others before being standardized into ARB_texture_barrier. But the fact that it could be implemented by other vendors didn't mean that <em>you</em>, code outside of the driver, could implement it. The core aspect of the functionality <em>requires</em> direct access to the GPU. Calling <code>glTextureBarrierNV</code> causes caches to be cleared and other synchronization operations that are specific to each piece of hardware.</p>
<p>That's not something you can do from outside of the driver.</p>

CC BY-SA 4.0
2023-12-19T16:15:22.667Z
2023-12-19T16:15:22.667Z
Nicol Bolas
<p>Extensions generally get compiler and driver support in order to take advantage of vendor specific hardware/software. The extensions can go out of &quot;style&quot; because they are replaced by something different, accepted and added to the GLSL specification and slightly change to be more general or a better fit for a wider range of hardware, some just don't get the industry traction the creators had hoped for, etc.</p>
<p>But this doesn't mean they can't be <em>emulated</em>. Often the basic behavior can be emulated using modern GLSL code and extensions. But every extension will be different and some may not be doable.</p>
<p>One other possibility is to get ahold of the open source drivers for the target hardware and edit the code to add the extension.</p>

CC BY-SA 4.0
2023-12-18T16:54:00.397Z
2023-12-18T16:54:00.397Z
pmw1234
<p>For example: I have an AMD graphics card, can I &quot;recreate&quot; Nvidia's OpenGL extensions? And vice versa?</p>
<p>By &quot;recreate&quot; I mean to write my implementation in some way. In general, how critical is the loss of features due to vendor? Or is it not worth bothering about it at all?</p>
<p>I apologize in advance if someone has already asked this question, or perhaps that it is silly and inappropriate</p>

CC BY-SA 4.0
2023-12-16T12:02:19.973Z
Do you have a specific extension in mind?
pmw1234
CC BY-SA 4.0
2023-12-17T19:43:05.217Z
@pmw1234 no, I ask in general
deaqsly
<opengl><legacy-opengl>
Can I "recreate" vendor-specific OpenGL extensions?
deaqsly
# Can I "recreate" vendor-specific OpenGL extensions?

(Asked by: username_0 on 2023-12-15)

For example: I have an AMD graphics card, can I "recreate" Nvidia's OpenGL extensions? And vice versa?

By "recreate" I mean to write my implementation in some way. In general, how critical is the loss of features due to vendor? Or is it not worth bothering about it at all?

I apologize in advance if someone has already asked this question, or perhaps that it is silly and inappropriate

**Tags:** opengl, legacy-opengl

> **Comments:**
> **username_1**: Do you have a specific extension in mind?  
> **username_0**: @username_1 no, I ask in general  

---

## 2 answers

### Answer by username_2 on 2023-12-19. Score: 1 | Accepted answer

Most vendor-specific extensions (particularly those of more recent vintage) are based on the particular nature of that vendor's hardware. And even if some other vendor's hardware could do something similar, emulating that functionality without actually being part of the *driver* would be, if not impossible, then exceedingly inefficient.

There may be specific cases where you might be able to implement something reasonably with a wrapper atop OpenGL, but most vendor extensions are too reliant on the specific internals of their hardware to make this viable.

Consider NV\_texture\_barrier. It was technically an NVIDIA extension, but it was widely implemented by others before being standardized into ARB\_texture\_barrier. But the fact that it could be implemented by other vendors didn't mean that *you*, code outside of the driver, could implement it. The core aspect of the functionality *requires* direct access to the GPU. Calling `glTextureBarrierNV` causes caches to be cleared and other synchronization operations that are specific to each piece of hardware.

That's not something you can do from outside of the driver.


---

### Answer by username_1 on 2023-12-18. Score: 0

Extensions generally get compiler and driver support in order to take advantage of vendor specific hardware/software. The extensions can go out of "style" because they are replaced by something different, accepted and added to the GLSL specification and slightly change to be more general or a better fit for a wider range of hardware, some just don't get the industry traction the creators had hoped for, etc.

But this doesn't mean they can't be *emulated*. Often the basic behavior can be emulated using modern GLSL code and extensions. But every extension will be different and some may not be doable.

One other possibility is to get ahold of the open source drivers for the target hardware and edit the code to add the extension.


---

