D3D enumerates adapters. In kernel driver parlance - an adapter is a device that represents a video output on a card. Typically an enumeration API (like the one in D3D) will only enumerate adapters on a video card that have a display connected.
Basically:
An adapter has one display.
A GPU may have more than one adapter.
An adapter may have more than one compatible renderer. There might be a software renderer. Or the GPU that hosts the adapter may have one or more renderers.
I think the original source code has muddled things by assuming that an adapter is a driver or a video card. This has led to weird descriptions in the code like a video card having display modes instead of a monitor having display modes.
Comments like this one are suspicious:
//-----------------------------------------------------------------------------
// Name: D3DEnum_DriverInfo
// Desc: Linked-list structure to hold information about a DirectX driver. The
// info stored is the capability bits for the driver plus a list
// of valid Direct3D devices for the driver. Note: most systems will only
// have one driver. The exception are multi-monitor systems, and systems
// with non-GDI 3D video cards.
Here DriverInfo represents an adapter/display - not a GPU driver. That's why more than one "driver" appears on multi monitor systems.
My goal is to have a client be able to tell a pipeline which display is the target display. This should allow the user to move between displays and have the display modes update. To do that - I need to begin untangling the Direct3D pipeline and reviewing changes that could impact the other pipelines.
The changes I'm proposing here for clarity:
D3DEnum_DriverInfo becomes D3DEnum_DisplayInfo. D3DEnum_DriverInfo is an abstraction for an adapter - which already represents a video output, not a driver.
D3DEnum_DeviceInfo becomes D3DEnum_RendererInfo. The information D3DEnum_DeviceInfo is wrapping are the possible renderers available for a display, not the possible devices available for a display.
I'm going to admit - I don't know if this language is correct. Adapter is the most correct description of a port on a video card connected to a display. But Adapter is a DX-ism - and it has a 1:1 relationship with a display. Renderer I feel a little better about. Plasma refers to the software renderer and the hardware renderer as 'Devices' which doesn't seem like the right language.
Things I'm thinking about but not actively addressing yet (but am open to feedback):
I'm only inside of the Direct3D bubble right now. It would be best if a display could vend the different renderers available across APIs. I.E. a display should vend both its Direct3D and OpenGL renderers as options. You can get an HMONITOR back from a D3D display record so you can cross reference different kinds of renderers to the same display.
Sometimes the GPU you want to render on is not the one attached to the display - like an eGPU. Rendering on a different GPU than the one attached to the display causes performance issues. Usually you should always use the GPU paired to the display unless the user manually overrides. I'm not worrying about that scenario yet.
I'm not sure of the origins of what happened here. This goes back to the original source drop. I think this file was a port of a D3D8 iterator - and possibly D3D8 had different terminology that mapped over badly.
Hoping to have this PR dragged through the wringer before I look at any changes to higher layers of Plasma that could spill into OpenGL and Metal.
D3D enumerates adapters. In kernel driver parlance - an adapter is a device that represents a video output on a card. Typically an enumeration API (like the one in D3D) will only enumerate adapters on a video card that have a display connected.
Basically:
I think the original source code has muddled things by assuming that an adapter is a driver or a video card. This has led to weird descriptions in the code like a video card having display modes instead of a monitor having display modes.
Comments like this one are suspicious:
Here DriverInfo represents an adapter/display - not a GPU driver. That's why more than one "driver" appears on multi monitor systems.
My goal is to have a client be able to tell a pipeline which display is the target display. This should allow the user to move between displays and have the display modes update. To do that - I need to begin untangling the Direct3D pipeline and reviewing changes that could impact the other pipelines.
The changes I'm proposing here for clarity:
D3DEnum_DriverInfobecomesD3DEnum_DisplayInfo.D3DEnum_DriverInfois an abstraction for an adapter - which already represents a video output, not a driver.D3DEnum_DeviceInfobecomesD3DEnum_RendererInfo. The informationD3DEnum_DeviceInfois wrapping are the possible renderers available for a display, not the possible devices available for a display.I'm going to admit - I don't know if this language is correct.
Adapteris the most correct description of a port on a video card connected to a display. ButAdapteris a DX-ism - and it has a 1:1 relationship with a display.RendererI feel a little better about. Plasma refers to the software renderer and the hardware renderer as 'Devices' which doesn't seem like the right language.Things I'm thinking about but not actively addressing yet (but am open to feedback):
I'm not sure of the origins of what happened here. This goes back to the original source drop. I think this file was a port of a D3D8 iterator - and possibly D3D8 had different terminology that mapped over badly.
Hoping to have this PR dragged through the wringer before I look at any changes to higher layers of Plasma that could spill into OpenGL and Metal.