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?
Improve this question
$\endgroup$
6
  • 2
    $\begingroup$ The question might be a little bit broad. $\endgroup$
    – Christian Rau
    Commented Jan 21, 2018 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
    Commented Jan 21, 2018 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
    Commented Jan 21, 2018 at 15:08
  • $\begingroup$ @Andreas :( off topic? I couldn't find nice resource about this topic other Graphic Programming Black Book $\endgroup$
    – Buddhika Chaturanga
    Commented Jan 21, 2018 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
    Commented Jan 21, 2018 at 17:25

1 Answer 1

Reset to default
7
$\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.

Improve this answer
$\endgroup$
3
  • 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
    Commented Jan 21, 2018 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
    Commented Jan 22, 2018 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
    Commented Jan 22, 2018 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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