<p>It's very different between the Khronos standards (including Vulkan) and DirectX.</p>

<p>In DirectX, Microsoft implements the API, but they publish to GPU vendors a HAL API. There's actually two HALs: one that runs in kernel-mode, to communicate with the card directly; and one that runs in user-space, to do other tasks (like manage memory, set up data structures, and compile shaders).</p>

<p>In Vulkan, Khronos only publishes the specification and a test suite. It's up to each GPU vendor to ship an implementation of the library. The application's interface to the driver is a normal C API, like any other library. You'll get confused if you try to think of an "API part" communicating with a "graphics card driver": the driver <em>is</em> the API implementation.</p>

<p>This is why it's very hard for third-parties to make open-source OpenGL (or Vulkan) implementations: you need to know all the details of the GPU hardware to do it. These graphics APIs are defined by industry groups consisting of the same people who design the hardware (at a high level), and deep understanding of the GPU architecture is what you need to design an efficient graphics API.</p>

CC BY-SA 3.0
2018-01-21T19:12:45.933Z
Thank you for answer Dan... :)
So,Learning to implement our own Graphic API is not worthy right ? We cannot optimized our system since we don't have an agreement or understanding with GPU vendors or their GPU Internals.
Buddhika Chaturanga
CC BY-SA 3.0
2018-01-22T11:39:29.043Z
Unless you're going to reverse-engineer the register and data structure interface of a GPU, you can't implement a GPU acceleration API without getting that information from a GPU vendor.
Dan Hulme
CC BY-SA 3.0
2018-01-22T12:52:04.277Z
Got it thank you Dan,Which means whatever tech comes,we have to depend on set of standard/platform specific APIs.
Buddhika Chaturanga
CC BY-SA 3.0
2018-01-21T17:34:00.967Z
2018-01-21T17:34:00.967Z
Dan Hulme
<p>I am trying and learning to develop a low level graphics API.</p>

<ul>
<li>I want to know, how do modern graphics APIs manage to communicate with graphic card drivers (to tackle GPU) so efficiently and in an optimized manner? </li>
<li>Which technologies should I understand other than C/C++ and Assembly?</li>
</ul>

CC BY-SA 3.0
2018-01-21T13:52:29.547Z
The question might be a little bit broad.
Christian Rau
CC BY-SA 3.0
2018-01-21T13:55:44.810Z
@ChristianRau Can you give slight ideas at least.basic theoretical aspects ffor quick learn stuff,it would be really helpful.Thank for the editing to.. I had spelled some words wrongly my bad :)
Buddhika Chaturanga
CC BY-SA 3.0
2018-01-21T15:08:09.327Z
good question, but still flagging as off-topic. I wish you best of luck finding out what you are after
Andreas
CC BY-SA 3.0
2018-01-21T16:25:41.753Z
@Andreas :( off topic? I couldn't find nice resource about this topic other Graphic Programming Black Book
Buddhika Chaturanga
CC BY-SA 3.0
2018-01-21T17:25:10.370Z
...because I think you will find better answers in forums about general driver implementation. No offense meant. Really trying to help :) Maybe you should ask yourself: what is a 'low level' graphics API? how is efficiency measured? what is optimized, or optimal?
Andreas
CC BY-SA 3.0
2018-01-22T06:12:05.280Z
@Andreas I was getting deviated that's why,Lost between HDL and HAL
Buddhika Chaturanga
<opengl><gpu><directx12><vulkan><driver>
What mechanisms are being used by Directx12 and Vulkan APIs in order to communicate with graphic card drivers internally?
Buddhika Chaturanga
# What mechanisms are being used by Directx12 and Vulkan APIs in order to communicate with graphic card drivers internally?

(Asked by: username_0 on 2018-01-21)

I am trying and learning to develop a low level graphics API.

* I want to know, how do modern graphics APIs manage to communicate with graphic card drivers (to tackle GPU) so efficiently and in an optimized manner?
* Which technologies should I understand other than C/C++ and Assembly?

**Tags:** opengl, gpu, directx12, vulkan, driver

> **Comments:**
> **username_1**: The question might be a little bit broad.  
> **username_0**: @username_1 Can you give slight ideas at least.basic theoretical aspects ffor quick learn stuff,it would be really helpful.Thank for the editing to.. I had spelled some words wrongly my bad :)  
> **username_2**: good question, but still flagging as off-topic. I wish you best of luck finding out what you are after  
> **username_0**: @username_2 :( off topic? I couldn't find nice resource about this topic other Graphic Programming Black Book  
> **username_2**: ...because I think you will find better answers in forums about general driver implementation. No offense meant. Really trying to help :) Maybe you should ask yourself: what is a 'low level' graphics API? how is efficiency measured? what is optimized, or optimal?  
> **username_0**: @username_2 I was getting deviated that's why,Lost between HDL and HAL  

---

## 1 answers

### Answer by username_3 on 2018-01-21. Score: 7 | Accepted answer

It's very different between the Khronos standards (including Vulkan) and DirectX.

In DirectX, Microsoft implements the API, but they publish to GPU vendors a HAL API. There's actually two HALs: one that runs in kernel-mode, to communicate with the card directly; and one that runs in user-space, to do other tasks (like manage memory, set up data structures, and compile shaders).

In Vulkan, Khronos only publishes the specification and a test suite. It's up to each GPU vendor to ship an implementation of the library. The application's interface to the driver is a normal C API, like any other library. You'll get confused if you try to think of an "API part" communicating with a "graphics card driver": the driver *is* the API implementation.

This is why it's very hard for third-parties to make open-source OpenGL (or Vulkan) implementations: you need to know all the details of the GPU hardware to do it. These graphics APIs are defined by industry groups consisting of the same people who design the hardware (at a high level), and deep understanding of the GPU architecture is what you need to design an efficient graphics API.

> **Comments:**
> **username_0**: Thank you for answer Dan... :) So,Learning to implement our own Graphic API is not worthy right ? We cannot optimized our system since we don't have an agreement or understanding with GPU vendors or their GPU Internals.  
> **username_3**: Unless you're going to reverse-engineer the register and data structure interface of a GPU, you can't implement a GPU acceleration API without getting that information from a GPU vendor.  
> **username_0**: Got it thank you Dan,Which means whatever tech comes,we have to depend on set of standard/platform specific APIs.  

---

