3
$\begingroup$

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?
$\endgroup$
  • 2
    $\begingroup$ The question might be a little bit broad. $\endgroup$ – Christian Rau Jan 21 '18 at 13:52
  • $\begingroup$ @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 :) $\endgroup$ – Buddhika Chaturanga Jan 21 '18 at 13:55
  • $\begingroup$ good question, but still flagging as off-topic. I wish you best of luck finding out what you are after $\endgroup$ – Andreas Jan 21 '18 at 15:08
  • $\begingroup$ @Andreas :( off topic? I couldn't find nice resource about this topic other Graphic Programming Black Book $\endgroup$ – Buddhika Chaturanga Jan 21 '18 at 16:25
  • $\begingroup$ ...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? $\endgroup$ – Andreas Jan 21 '18 at 17:25
6
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ 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. $\endgroup$ – Buddhika Chaturanga Jan 21 '18 at 19:12
  • 2
    $\begingroup$ 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. $\endgroup$ – Dan Hulme Jan 22 '18 at 11:39
  • $\begingroup$ Got it thank you Dan,Which means whatever tech comes,we have to depend on set of standard/platform specific APIs. $\endgroup$ – Buddhika Chaturanga Jan 22 '18 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.