Display adapters and GPU

[volglizolic]

I cannot quite understand how a monitor "connects" to the OS and each application on Windows systems.

So far I think that is what is happening:
An application requests from the OS to display something using a function in OpenGL, DirectX<insertNumberHere> or GDI.
Then each library translates the request and calls Direct3D runtime and DirectX graphics kernel subsystem functions.
The Direct3D runtime and DirectX graphics kernel subsystem "talks" with the GPU driver in order to fulfill the request.
If the request is to display graphics to the monitor the GPU displays them directly(I think?!).

Now here are my questions:
Does the OS "know" displays exist, or is the GPU in between?
If an Applications wants something to be displayed does the OS change the request to include window size ect?
How does the OS know what is displayed? (eg when using printScreen) Does it ask the GPU?
What does sound have to do with GPU?
Do both AMD and NVIDIA implement the same Microsoft specified interface? And how come CUDA be available only for NVIDIA? Is CUDA interface a different subsystem?

I hope my questions make sense, and thank you in advance!

[StudlyCaps]

Hey, so basically the OS will generally offer a window manager service. Sometimes it will be part of the kernel (common in the past) sometimes it's an interchangeable module. The window manager is in direct command of the graphics driver, and essentially presents a sand boxed environment (called a context in OpenGL) to the user application.

So the context has the information to tell the graphics driver which areas of the screen can be used and so on, the information is supplied by the window manager. Note: when a program runs in dedicated fullscreen mode it's actually getting direct control over the graphics driver, which is why tabbing in and out can cause lots of bugs when games don't implement it properly.
When using something like print screen, the OS would ask the window manager to capture the screen and the window manager would probably ask the graphics driver to copy the current framebuffer into RAM.
Sound usually has nothing to do with the GPU, the sound card is a chip on the motherboard in most modern computers. However, a graphics card with a HDMI output can be an output device and the GPU can be used to generate sound by using shaders to perform sound mixing, but this still goes out via the sound card.
AMD and Nvidia do implement the same software interface for Windows, it's called Direct3D and it's the render component of DirectX it's a graphics API. The graphics driver receives Direct3D commands, and then interperts them and sends them to the graphics card using it's own, totally proprietry API. OpenGL is also a graphics API and on modern Windows both can run side by side.
CUDA is also an API to talk to the grqphics card but it doesn't draw to the screen, instead it has commands to use the powerful parallel shader units to do maths. Unlike graphics, Microsoft doesn't have a standard API for parallel computing so Nvidia made their own.

Hope this helps.

[Korona]

This information is inaccurate for modern graphics cards.

GPUs are more or less independent of the display pipeline. The display pipeline is quite dumb; you basically just tell it something like "the scanout buffer is located at 0x12345678" and what resolution you want to display (in practice this is more complicated due to things like clock sources that need to be configured to get the right timings).

The GPU is generally programmed from user-space. User space compiles command buffers (e.g. from GLSL to the GPU's instruction set) and calls a lightweight kernel function to pass those buffers to the GPU.

On Windows, both AMD and NVIDIA use the same interface of the Windows kernel (e.g. pfnCreateDevice()). On Linux, shader compilation (i.e. by far the largest part of the GPU driver) is done in Mesa (which is a user-space library). The kernel interface is in libdrm.

The window manager (or compositor) is not involved in 3D rendering (well, it composes the final image but that does not require special handling for 3D). Fullscreen mode is not special; programs do not get exclusive GPU access by entering fullscreen mode.

[volglizolic]

Thanx to both of you!!

And what about the monitor?
What is the monitor driver about? (https://docs.microsoft.com/en-us/window ... or-drivers)

[ggodw000]

i dont rememer details but each display pixel maps to certain area of memory. You write to that memory and dot appears on screen. How many bytes allocated per pixel is dependent on display mode (text, graphics), resolution, and amount of memory.
When GPU is a high performance i.e. gaming, with 8GB with GDDR5 and its memory is mapped to display region, performance is higher etc.
It is all done by hardware mapping. Low level software could configure the mapping region such taht it will not overlap with other device memory.

You can see what memory area being used by your GPU from Windows device manager.

[Schol-R-LEA]

I did start writing a wiki page entitled Graphics stack almost two years ago which covers this and more, in very general terms, but it needs a lot more work. It doesn't really address Windows per se, however.

Thanx to both of you!!

And what about the monitor?
What is the monitor driver about? (https://docs.microsoft.com/en-us/window ... or-drivers)

To the best of my knowledge, the monitor driver is mostly used to ensure that the signals from the GPU will sync with what the monitor can handle correctly; it is less about driving the monitor than about giving the GPU the information it needs so it can do so.

The main things the video driver needs from the monitor driver are the vertical sync (usually in Hertz, e.g., 60Hz, 144Hz, and so forth) and horizontal sync rates, horizontal blanking sweep time (on older CRT monitors, this was how long it took the mechanism to reset the electron beam from the far right to the start of the next vertical line at the far left), vertical blanking sweep time (the time for the electron beam to reset from the bottom right to the top left of the screen), the row and column capacities at each speed and mode (e.g., 1920 x 1080), and whether a given mode was interlaced or progressive (EDIT: interlaced, not interleaved, thanks for pointing that out Octocontrabass). The data packet usually also includes desiderata such as the manufacturer, model name and number, a UUID for the monitor type, and so forth.

Based on what has been said here before about it - comments and corrections welcome - on modern (after, say, 1992 or so) monitors, the monitor itself is also supposed to be able to give this information to the card in the form of an EDID which the card can use to look it up. This is what allows most monitors to work correctly even without a Windows driver for the monitor itself (using the 'generic svga monitor' driver, though the GPU will also pass the EDID information to the CPU so that it can report the specifics). However, the Windows drivers can give more details than the EDID can, at least in principle. In any case, the GPU firmware may not have EDID registration information for a monitor that is newer than the card itself, or the data may be incorrect (something Brendan spent weeks railing about once), so having the pseudo-driver for the monitor is still useful.

While Windows happens to use a driver for this, it is more a matter of what is more generally called 'device registration', that is to say, having the necessary information about the device. Indeed, not all OSes use drivers for the monitors in the sense that Windows does; in Linux, for example, the X.org definition files are generally used instead.

Again, if anyone has any corrections for this, feel free to speak up.

[Octocontrabass]

Again, if anyone has any corrections for this, feel free to speak up.

Well, since you asked...

and whether a given mode was interleaved or progressive.

"Interlaced"

In any case, the GPU firmware may not have EDID registration information for a monitor that is newer than the card itself,

What is "registration information"?

[Schol-R-LEA]

Again, if anyone has any corrections for this, feel free to speak up.

Well, since you asked...

and whether a given mode was interleaved or progressive.

"Interlaced"

OK, that's a touch embarrassing, but thanks.

In any case, the GPU firmware may not have EDID registration information for a monitor that is newer than the card itself,

What is "registration information"?

I meant the data about monitor's capabilities. I am not sure why I worded it that way. I probably was thinking of it as being in a 'registry' of monitor types in the firmware (thinking in Windows terms based on the question, I suppose), so that was probably where the odd phrasing came from. Also, I used the term 'device registration' to describe the general process (contrasting the ways it is done in Windows with the way many Unices do it when running X Window System) in what ended up as a later part of the post before going back and elaborating on that part of the topic, and had that in mind when I wrote that.

[Octocontrabass]

I meant the data about monitor's capabilities.

In that case...

the monitor itself is also supposed to be able to give this information to the card in the form of an EDID which the card can use to look it up. [...] In any case, the GPU firmware may not have EDID registration information for a monitor that is newer than the card itself,

Most displays use EDID to directly specify their preferred timing parameters, so there's not much to look up. On top of that, they're required to do it in a backwards-compatible format, so you don't have to worry about newer EDID formats being incompatible with an older implementation. (However, you might have to worry about not having EDID at all.)

[SpyderTL]

It helps to keep in mind that when you are designing hardware, unless you get to design the ENTIRE system, you have to communicate and correctly interoperate with all of the other components in the system for your design to be considered successful. For desktop PC's, and to a less extent laptops and mobile devices, you want your system to be "compatible" with as many components as possible.

But, you don't really have the option to include all of the different connection points you would need to talk to every possible device in every possible system, because each interface costs additional design time and production cost. So, to reduce these costs, you must limit your interfaces as much as possible, while maintaining the greatest level of compatibility with the greatest number of devices.

Ideally, each device would have no more than one interface, and that would allow that component to communicate with any other device, even if the other device has not been designed yet. And, in fact, this is true for most devices. (The notable exception would be "adapters" that connect to two different devices, specifically to extend compatibility between two incompatible devices.)

So, it's fairly safe to think of each component in a PC having a single "interface" to the rest of the system. This means that, for instance, the CPU can't talk directly to the monitor, or the video adapter, or even the system RAM. It can only talk to the motherboard, and it can only ask the motherboard to read or write values to an address. The motherboard is responsible for deciding which addresses are connected to which device. So, in order for the CPU to access information coming from the monitor, the CPU talks to the motherboard, which talks to the PCI bus, which talks to the video adapter, which talks to the monitor, and the information requested is either returned to the CPU one byte at a time, or it is written directly to system RAM in the case of DMA or "Bus Master" communication.

Hopefully that helps clarify things.