difference between vulkan context and opengl context - opengl

Question

Does Vulkan have the concept of context and is it similar to the openGL context? and what a Vulkan instance actually is?
I am trying to understand the concept of context in both the Vulkan and openGL senses. I also want to know what a Vulkan instance actually is.

Answer 1

An OpenGL context represents:
An interface for issuing a single sequence of rendering commands for a particular piece of hardware.
The current set of state that will be used for any rendering operations on that hardware.
A set of objects which are usable by rendering operations, as well as the ability to interact with them. Some of these objects may be shared with other contexts.
Vulkan doesn't have a single thing that represents all of these. There is no "Vulkan context". And indeed, a Vulkan instance doesn't represent any of the above.
See, while an OpenGL context defines an interface for a particular piece of hardware, it doesn't define how to create that context. External APIs exist for creating a context. And these external APIs are entirely platform-dependent.
Vulkan wants to both define the hardware interface and provide a framework for creating one. That framework will be platform-dependent to some degree, but only to the degree that is absolutely necessary.
Specifically, the only platform-dependent part of dealing with Vulkan is interacting with an OS-provided display system (ie: a window). Everything else is platform-neutral.
A Vulkan instance is the interface for interacting with the available hardware. You use a Vulkan interface to ask what Vulkan-capable hardware is available, what their capabilities and limitations are, and how to create a Vulkan device from that hardware (and to optionally attach it to an OS-provided display system).
Individual Vulkan implementations on your machine register themselves with the Vulkan instance system. This allows the instance implementation to talk to them and ask them those questions.
The closest thing Vulkan has to an OpenGL context is a Vulkan logical device (VkDevice). These are built from one or more "physical devices" (representing actual GPUs), and they provide the interface for interacting with the rendering system. But even that doesn't really do most of the OpenGL context stuff. It only really does #3.
Command buffers represent the current state for rendering commands, as well as the rendering commands themselves. But you can have many separate command buffers, and they are not executed immediately.
Executing command buffers is done through queues, which come from devices. A queue is a separate path of execution for command buffers.
Vulkan is not like OpenGL. You shouldn't try to map Vulkan constructs onto OpenGL constructs (except when they literally have the same name, like "texture" or "shader" or whatever). Take Vulkan for what it is, not for how it looks like OpenGL.

Answer 2

No, Vulkan uses much more mainstream paradigm: object oriented programming.
Vulkan instance is an object. It is created, destroyed, encapsulates its data, and has methods.
glEnable function is an exemplar of what context means in OpenGL. Once you set a state, it applies from that point forward forever, unless it is changed to something else (i.e. the following function calls operate in a "context" of previous function calls). This leads to endless frustration:
// ok lets draw something with State 1
glEnable( STATE1 );
glEnable( STATE2 );
glEnable( STATE3 );
glDraw();
//... lot of stuff potentially happens here
// ok lets draw something with State 2 which differs from State 1 in STATE3
glDisable( STATE3 );
// that is pretty brittle right; I can't be sure of anything that happed beforehand
// so I better just doublecheck everything:
assert( glIsEnabled(STATE1) );
assert( glIsEnabled(STATE2) );
assert( glIsDisabled(STATE4) );
//...
assert( glIsDisabled(STATE69) );
glDraw();
//... lot of stuff potentially happens here
// Ok now I want to draw things again with State 1 again:
glEnable( STATE3 );
// But I don't even remember what state any previous work did set,
// so I might as well try to set everything just to be safe:
glEnable( STATE1 );
glEnable( STATE2 );
glDisable( STATE4 );
//...
glDisable( STATE69 );
// But Extensions can always add new state, so I am pretty much screwed
// and guaranteed bugs sooner or later because someone set STATE420_EXT and didn't clear it
glDraw();
This is trivial to manage in Vulkan in modern less errorprone object oriented way:
VkGraphicsPipeline pipe1, pipe2;
VkPipelineCreateInfo pi{};
pi.state1 = enable;
pi.state2 = enable;
pi.state3 = enable;
vkCreateGraphicsPipeline( device, &pi, &pipe1 );
pi.state3 = disable;
vkCreateGraphicsPipeline( device, &pi, &pipe2 );
// ...
// draw with State 1:
vkCmdBindPipeline( cmdBuff, pipe1 );
vkCmdDraw( cmdBuff );
// draw with State 2:
vkCmdBindPipeline( cmdBuff, pipe2 );
vkCmdDraw( cmdBuff );
// draw with State 1 again:
vkCmdBindPipeline( cmdBuff, pipe1 );
vkCmdDraw( cmdBuff );
Note this is C, so the object is the first parameter, rather than before a dot like it would be in e.g. class based C++.