Small Direct3D query

[BEENNath58]

The DirectX7 Caps Viewer identifies Hardware Emulation Layer and Primary Display Driver, both of them to support HAL, TnL HAL, RGB.

To my knowledge, RGB has always been software accelerated (to be put in HEL), and HAL, TnL HAL being HW accelerated (i.e. to be put in Disp. Driver). This was the case till DX6 Caps Viewer: all devices - Ramp, RGB, MMX, HAL was put inside Disp. Driver category and there was no D3D HEL. BUT

On DX7 caps viewer, putting HAL inside both HEL and Disp. Driver makes me wonder; if RGB emulation back then was always DD driver accelerated and DX7 allows software acceleration for it. Alternatively, HAL having software acceleration as well.

Interestingly, both Prim Disp Driver and HEL devices; all of them have SAME CAPABILITIES. I never heard of method to call this HEL based method as well as the new RGB emulation coming under HEL.

Can you shed some light on it?

[narzoul]

I'm pretty sure HAL and HEL can't be mixed in Direct3D 7 or earlier. You either create a HAL device and the rendering will be entirely up to the adapter's driver, or you create a HEL device and rendering will be entirely done by the Direct3D runtime's software rendering pipelines. Only blitting allows an automatic fallback to HEL for features that are not supported by HAL (e.g. mirroring or color keying), but blitting is a part of DirectDraw, not Direct3D.

AFAIK the source code of the Caps Viewer is not available, but I did some digging through DDrawCompat's debug logs. The app enumerates adapters through DirectDrawEnumerateExA, which returns the Primary Display Driver and whatever adapters are attached to your desktop (NVIDIA in your case). The Hardware Emulation Layer is not something that is enumerated, so I have no idea why it's there.

The app then creates a DirectDraw object for each enumerated adapter by passing their respective GUIDs to DirectDrawCreateEx. The Primary Display Driver's GUID is null, the rest of the adapters have unique GUIDs. After that it does one more DirectDrawCreateEx with a null GUID, presumably for the HEL section. For each DirectDraw object created, it also creates a Direct3D object and then uses the EnumDevices method on that to find the listed HAL/HEL devices. Since the null GUID uses the primary adapter (the NVIDIA one in your case), the Primary Display Driver and Hardware Emulation Layer unsurprisingly return the same devices as that one.

In a system with multiple different adapters connected to the desktop, there would be multiple adapters listed, and the Primary Display Device would only match one of them. I do have such a system, and here both the Primary Display Device and Hardware Emulation Layer matches the primary adapter's capabilities, and only the second adapter's capabilities are different.

So, I guess there is not much purpose to the HEL section, since it always seems to be filled the same way as the Primary Display Device, Maybe it's there just to mirror the structure of the DirectDraw devices section, but there at least the HEL section really only shows HEL capabilities.

[BEENNath58]

The app enumerates adapters through DirectDrawEnumerateExA, which returns the Primary Display Driver and whatever adapters are attached to your desktop (NVIDIA in your case). The Hardware Emulation Layer is not something that is enumerated, so I have no idea why it's there.

I guess you are saying this about the DirectDraw devices, that HEL is not enumerated as an unique device but it's caps and features are enumerated?

Since the null GUID uses the primary adapter (the NVIDIA one in your case), the Primary Display Driver and Hardware Emulation Layer unsurprisingly return the same devices as that one.

Basically it means that every D3D device generated is just information from every DD device enumerated, regardless of them being unique or not?

but there at least the HEL section really only shows HEL capabilities.

Yes, but only for the DD part. The D3D part is a carbon-copy of the Prim. Display Driver.

Only blitting allows an automatic fallback to HEL for features that are not supported by HAL (e.g. mirroring or color keying), but blitting is a part of DirectDraw, not Direct3D.

This goes out of scope of the thread, but can't color keys that are bugged in drivers be fixed with a HEL fallback, and if there's a way to do it manually?

[narzoul]

I guess you are saying this about the DirectDraw devices, that HEL is not enumerated as an unique device but it's caps and features are enumerated?

Yes, DirectDraw's GetCaps method returns both HAL and HEL capabilities in separate structures.

Basically it means that every D3D device generated is just information from every DD device enumerated, regardless of them being unique or not?

Yes.

Yes, but only for the DD part. The D3D part is a carbon-copy of the Prim. Display Driver.

Yes.

Only blitting allows an automatic fallback to HEL for features that are not supported by HAL (e.g. mirroring or color keying), but blitting is a part of DirectDraw, not Direct3D.

DirectDraw checks the caps returned by the display driver. If the colorkey caps are disabled there, then the runtime will automatically use HEL for color keyed blits. I used to do something similar for mirroring, but this requires WDDM hooks. I'm not sure how it works with XPDM, as I never bothered with it, but I assume there are similar caps reported through that too.

[BEENNath58]

Okay that's most of what I need. Just as on the topic, before closing the topic, can you suggest any test application, for testing the color keying bugs under DDraw or the COLORKEYENABLE?

[narzoul]

I assume you mean texture color keying since you mentioned the COLORKEYENABLE render state. Mig Alley is a potential test candidate, see here: https://github.com/narzoul/DDrawCompat/issues/116

[elishacloud]

Star Trek Armada 1 uses the COLORKEYENABLE render state.