For example cudaMemcpy and cuMemcpy? I can see that the function definitions are different, but I mean the API in general. Why is there an api starting with cu... and one starting with cuda...? When should each API be used?
The API where the method names start with cu... is the so called Driver API. The API where the method names start with cuda... is the Runtime API.
Originally (up to CUDA 3.0) the APIs have been completely separated. A rough classification was: The Runtime API is simpler and more conventient. The Driver API is intended for more complex, "low level" programming (and maybe library development).
Since CUDA 3.0, both APIs are interoperable. That means that, for example, when you allocate memory with the Driver API using cuMemAlloc, then you can also use the same memory in Runtime API calls, like cudaMemcpy.
The major practical difference was that in the Runtime API, you could use the special kernel<<<...>>> launching syntax, whereas in the Driver API, you could load your CUDA programs as "modules" (with methods like cuModuleLoad), given in form of CUBIN files or PTX files, and launch these kernels programmatically using cuLaunchKernel.
In fact, I think that for the largest part of a CUDA program, the differences are negligible: Nearly every other functionality (except for kernel/module handling) is available in both APIs, and nearly equal in both. This refers to methods (cuMemcpy and cudaMemcpy etc., as well as to structures CU_event and cudaEvent etc.).
Further information can be found with websearches involving the keywords "CUDA Runtime Driver API", for example, at https://devtalk.nvidia.com/default/topic/522598/what-is-the-difference-between-runtime-and-driver-api-/
Related
I've been trying to write Vulkan bindings for a language and I'm a bit confused about how extensions work. On Linux I'm using libdl to load function pointers from libvulkan.so.1, and I've noticed that some extension functions (like those from VK_KHR_swapchain and VK_KHR_Wayland_Surface) can be linked through libdl, but others (like the ones in VK_EXT_debug_utils or VK_EXT_extended_dynamic_state2) can only be found through vkGetInstanceProcAddr or vkGetDeviceProcAddr.
My questions are these:
Why are some Vulkan extensions available through dynamic linking but not others?
Can I rely on these dynamically-linkable extensions always being there? (For example, can I be sure that if the VK_KHR_swapchain extension is available, vkCreateSwapchainKHR will definitly be found by libdl?)
TFM:
Vulkan Direct Exports
The loader library on Windows, Linux, Android, and macOS will export all core Vulkan entry-points and all appropriate Window System Interface (WSI) entry-points. This is done to make it simpler to get started with Vulkan development. When an application links directly to the loader library in this way, the Vulkan calls are simple trampoline functions that jump to the appropriate dispatch table entry for the object they are given.
Specifics: https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderApplicationInterface.md#wsi-extensions
First I wonder about some minor details to see if I understand some concepts properly:
Is vulkan-1.dll (or libvulkan.so.1 on Linux) what is referred to as the loader?
When I use HMODULE vulkan_module = LoadLibrary( "vulkan-1.dll" );, is this using the loader from the graphics driver (provided that the previous detail is true)?
Now to the actual question. It seems that the loader is responsible for pulling drivers together to have them seem as one "unit" of sorts, as well as collecting available extensions and validation layers. What then differs the LunarG loader (for example) from those provided by graphics drivers? Why would one want to use one over the other?
Vulkan drivers do not contain anything that would reasonably be called a "loader". They are "providers".
The purpose of a "loader" is to load what the "providers" provide. The most basic thing a loader does is find the implementations' DLLs and interact with them. This differs based on the platform. With Windows, they probably use registry settings to hunt down the implementation DLLs. On Android, their built-in support probably centralizes things. And so forth.
The only commonly used loader is LunarG's SDK loader (which does use the filename vulkan-1). Some have written their own, but LunarG's is the only one with widespread usage.
"the loader" or "official loader" or "Khronos loader" or "LunarG loader" or "VulkanRT" are AFAIK the same. It's from the project KhronosGroup/Vulkan-LoaderAndValidationLayers.
What differs (between those provided by the Khronos, LunarG SDK, and drivers) is usually only a version. (Typically LunarG SDK lags behind Khronos and driver lags behind both.)
More then you ever wanted to know of its inner workings is in the loader documentation.
Run-time dynamic linking as you propose should be possible (you would do the LoadLibrary() then GetProcAddress() the vkGetInstanceProcAddr() command and then rest from it).
(On Windows) I think most people use the convenient dll import library vulkan-1.lib from LnG SDK with whatever vulkan-1.dll is in the System32.
My question is very simple, and I want a clear answer with a simple example.
What's the main difference between API, Toolkit, Framework, and Library?
I prefer following:
An API is an abstract description of how to use an application. For example, an API may describe the function syntax (declaration) of a chat server. i.e. login, publish_message, subscribe_messages. And, it describes any protocols to use the application. i.e. must login before sending or recieving messages, or clients are dropped after 2 minutes if not sending or receiving messages.
A library is an implementation of an API, it containes the compiled code that implements the functions and protocols (maintains usage state).
A toolkit is a set of libraries (API) and services grouped together to provide the developer with a wider range of possible solutions. For example, the Globus Toolkit provides services (such as File transfering, Job Subission and Scheduling) that a devleoper can install and start on their servers. They also provide API's to build applications that may use the services deployed in an integrated fashion. For example, the developer may build a program that uses the Job Submission API to communicate with the Job Submission Service.
A Framework is a set of guidelines that prevents inappropriate use or developement. The developer must contruct their applications within the rules and boundaries of the framework. This is done by forcing the developer to extend the current framework to develope new software. by extending the framework, you force adhearence to the framework.
I'm not saying these are completely correct, but its worked ok for me so far!
This has always been my understanding, you will no doubt see differing opinions on the subject:
API (Application Programming Interface) - Allows you to use code in an already functional application in a stand-alone fasion.
Framework - Code that gives you base classes and interfaces for a certain task/application type, usually in the form of a design pattern. (Though not always)
Library - Related code that can be swapped in and out at will to accomplish tasks at a class level
Toolkit - Related code that can be used to accomplish tasks at a component level.
Those terms sometimes are misinterchanged.
Similar posts, read:
What is the major difference between a framework and a toolkit?
Framework vs. Toolkit vs. Library
I prefer to call a library as an alias of module or namespace. Toolkit and A.P.I. is usually a set of libraries for a common task. Altought, A.P.I. is more used for Procedural Programming than Object Oriented Programming.
Whenever I ask people about the difference between an API and a library, I get different opinions. Some give this kind of definition, saying that an API is a spec and a library is an implementation...
Some will tell you this type of definition, that an API is a bunch of mapped out functions, and a Library is just the distribution in compiled form.
All this makes me wonder, in a world of web code, frameworks and open-source, is there really a practical difference anymore? Could a library like jQuery or cURL crossover into the definition of an API?
Also, do frameworks cross over into this category at all? Is there part of Rails or Zend that could be more "API-like," or "libraryesque"?
Really looking forward to some enlightening thoughts :)
My view is that when I speak of an API, it means only the parts that are exposed to the programmer. If I speak of a 'library' then I also mean everything that is working "under the hood", though part of the library nevertheless.
A library contains re-usable chunks of code (a software program).
These re-usable codes of library is linked to your program through APIs
(Application Programming Interfaces). That is, this API is an interface to library through which re-usable codes are linked to your application program.
In simple term it can be said that an API is an interface between two software programs which facilitates the interaction between them.
For example, in procedural languages like C, the library math.c contains the implementations of mathematical function, such as sqrt, exp, log etc. It contains the definition of all these functions.
These function can be referenced by using the API math.h which describes and prescribes the expected behavior.
That being said, an API is a specification (math.h explains about all the functions it provides, their arguments and data they return etc.) and a library is an implementation (math.c contains all the definitions of these functions).
API is part of library that defines how it will interact with external code. Every library has API, API is sum of all public/exported stuff. Nowadays meaning of API is widened. we might call the way web site/service interact with code as API also. You can also tell that some device has API - the set of commands you can call.
Sometimes this terms can be mixed together. For example you have some server app (like TFS for example). It has API with it, and this API is implemented as a library. But this library is just a middle layer between you and not the one who executes your calls. But if library itself contains all action code then we can't say that this library is API.
I think that Library is a set of all classes and functions that can be used from our code to do our task easily. But the library can contain some of its private functions for its usage which it does not want to expose.
API is a part of library which is exposed to the user. So whatever documentation we have regarding a library, we call it an API Documentation because it contains only those classes and functions to which we have access.
we have first to define an interface ...
Interface :is the means by which 2 "things" talk to each other and exchange information. "things" could be a (1) human or (2) a running code of any sort (e.g. library ,desktop application , OS , web service ... etc).
if a human want to talks to a program he need Graphical user interface (GUI) or command line interface (CLI). both are types of interfaces that humans (but not programs) would like to use.
if however a running code (of any sort) want to talk to another running code (of any sort) it doesn't need or want a GUI or CLI ,it rather need an Application Programming Interface (API).
so to answer the original poster question : library is a type of running code and the API is the means by which this running code talk to other running codes.
In Clear and concise language
Library: Collection of all classes and methods stored for re-usability
API: Part of library classes and methods which can be used by a user in his/her code.
According to my perspective, whatever the functions are accessible to invoker , we can called as api in library file, library file having some of the functions which is private , we cannot access them ..
There are two cases when we speak or think of API
Computer program using library
Everything else (wider meaning)
I think, that in the first case, thinking in terms of API is confusing. It's because we always use a library. There are only libraries. API without library doesn't exist, while there's a tendency to think in such terms.
How about The Standard Template Library (STL) in C++? It's a software library.
You can have different libraries with the same API, meaning set of available classes, objects, methods, functions, procedures or whatever terms you like in some programming language. But it can be said, that we have different implementation of some "standard" library.
Some analogy may be that: SQL is a standard but can have different implementations. What you use is always some SQL engine which implements SQL. You may follow only standard set of features or use some extended, specific to that implementation.
And what "under the hood" in library is not your concern, except in terms of differences in efficiency by different implementations of such library.
Of course I'm aware, that this way of thinking is not what is a "generally binding standard". Just a lot of new terms have been created, that are not always clear, precise, intuitive, that brings some confusion. When Oracle speaks about Collections. It's not library, it's not API, it's a "Collections Framework".
Hello brothers and sisters.
Without using technical terms I would like to share my understanding regarding API and library.
The way I distinguish 'library' and 'API' is imagining a situation where I go to a book library. When I go there, I request a book which I need to a 'librarian' without knowing how a entire library is managed.
I make a simple relation between them like this.
Library = A book library which has a whole system and staffs to manage books.
API = A librarian who provides me a simple access to a book which I need.
OK, this is basically just about any non-default OS API running on all different OS. But for my example let´s consider platform Windows, API SDL (Simple DirectMedia Layer).
Actually this question came to my mind when I was reading about SDL. Originally, I thought that on Windows (and basically any other OS) you must use OS API to make certain actions, like writing to screen, creating window and so on, because that API knows what kernel calls and system subroutines calls it has to do. But when I read about SDL, I surprised me, because, you cannot make computer to do anything more than OS can, since you cannot access HW directly, only thru OS API, from Console allocation to DirectX.
So, my question actually is, how does this not-default-OS APIs work? Do they use (wrap) original system API (like MFC wraps win32 api)? Or, do they actually have direct access to Windows kernel? Or is there any third, way in between?
Indeed, SDL is a wrapper for OS-specific calls, although with many simplifications and convenience functions. On Windows, SDL uses DirectX.