The reference device should come with the DirectX 8/9 SDKs. It is a slow-but-conformant CPU renderer that app developers and driver engineers rely on to ensure their results match the spec, and flag bugs if not. IIRC, you need the SDK installed for it to work, but maybe that DLL by itself is enough.. but I doubt it.

Anyways, it's too slow to be real-time, and was never intended to be fast or public-useable. Not sure why you want to use it. Also, some games filter it out explicitly from their adapter list, but IIRC the SDK's control panel allowed you to force it.

wbahnassi wrote on 2022-09-03, 11:19:

The reference device should come with the DirectX 8/9 SDKs. It is a slow-but-conformant CPU renderer that app developers and driver engineers rely on to ensure their results match the spec, and flag bugs if not. IIRC, you need the SDK installed for it to work, but maybe that DLL by itself is enough.. but I doubt it.

Anyways, it's too slow to be real-time, and was never intended to be fast or public-useable. Not sure why you want to use it. Also, some games filter it out explicitly from their adapter list, but IIRC the SDK's control panel allowed you to force it.

Thanks. It was indeed in the SDKs, I didn't look enough. Yes the application is too slow, but I want to see if the application will run well with it. Using DxWnd, I was able to launch games but the 3D part was too slow to load and after 2 hrs of waiting I gave up. Maybe DxWnd isn't complete with the work after all, so I have to force it through the SDK's control panel. But even after doing it, the changes don't affect ANY application. By effect, I mean the Control Panel's setting change to Enumerate Reference device would still use HAL.

For the record, I chose to install the 2007 DirectX9 SDK.

That brings to my next question, when was the first release of Reference device? I found it in DirectX 7 DDK but nowhere before it.

All versions. The beta version of ddraw.dll (Version 0.9.2) checks for `DDCREATE_EMULATIONONLY`.

The game `Dark Omen` has an option for RAMP or MMX mode. The game uses Direct3D2.

aqrit wrote on 2022-09-04, 21:36:

All versions. The beta version of ddraw.dll (Version 0.9.2) checks for `DDCREATE_EMULATIONONLY`.

I am a newbie in this matter. I noticed DX7 and greater provide a separate d3dref*X*.dll file which does Ref device work.

So what file does applications with older than DirectX6 need to try the Ref device?

There's also something called HEL (Hardware Emulation Layer) and I am now wrong that's probably the predecessor to d3dref*X*.dll based Reference devices.

aqrit wrote on 2022-09-04, 21:41:

The game `Dark Omen` has an option for RAMP or MMX mode. The game uses Direct3D2.

Ok I could try the RAMP features to test RAMP compatibility on Win11. Isn't RAMP just software emulated?

>"The Direct3D API (like the rest of the DirectX API) is built on top of a hardware-abstraction layer (HAL), which insulates you from device-specific dependencies present in the hardware. A companion piece to the Direct3D HAL is the hardware-emulation layer (HEL). The Direct3D HEL provides software-based emulation of features that are not present in hardware. The combination of these hardware abstraction and emulation layers ensures that the services of the API are always available to you."

HAL and HEL are just generic terms.
My point is there has always been a software fallback for Direct3D and DirectDraw.

>"Unlike an (software-emulated) RGB device, the reference rasterizer supports every Direct3D feature."

AFAIK, the RGB device is like the reference device, but it doesn't have 100% support for all the exotic operations.
Much like the DirectDraw HEL which fails on a number of operations...

The MMX device merged with the RGB device in DirectX version 3, probably not much difference between them.
(Obviously the MMX device used MMX instructions).

RAMP vs RGB modes:
I think this is decided by the game programmers and can't be changed.
RAMP uses monochrome lighting and limited features for performance reasons.
There is a (software-emulated) RAMP device to back RAMP mode...

The old versions of DirectX don't require additional files to use the software emulation features.

aqrit wrote on 2022-09-06, 21:58:

>"The Direct3D API (like the rest of the DirectX API) is built on top of a hardware-abstraction layer (HAL), which insulates you from device-specific dependencies present in the hardware. A companion piece to the Direct3D HAL is the hardware-emulation layer (HEL). The Direct3D HEL provides software-based emulation of features that are not present in hardware. The combination of these hardware abstraction and emulation layers ensures that the services of the API are always available to you."

HAL and HEL are just generic terms.
My point is there has always been a software fallback for Direct3D and DirectDraw.

Thank you very much. I understand now that HAL and HEL both may co-exist in a particular situation too.

aqrit wrote on 2022-09-06, 21:58:

>"Unlike an (software-emulated) RGB device, the reference rasterizer supports every Direct3D feature."

AFAIK, the RGB device is like the reference device, but it doesn't have 100% support for all the exotic operations.
Much like the DirectDraw HEL which fails on a number of operations...

Is there no hardware-abstracted RGB device? Yes both of them will fail on exotic operations from devices like HAL, but if both HW and SW RGB device exist, is one better than the other or both have all features supported in them?

aqrit wrote on 2022-09-06, 21:58:

RAMP vs RGB modes: I think this is decided by the game programmers and can't be changed. RAMP uses monochrome lighting and limit […]
Show full quote

RAMP vs RGB modes:
I think this is decided by the game programmers and can't be changed.
RAMP uses monochrome lighting and limited features for performance reasons.
There is a (software-emulated) RAMP device to back RAMP mode...

Is there a way to force the software emulated RAMP device. The Windows 10/11 RAMP device (probably HW emulated too) is too buggy or feature limited, only testing will say.

aqrit wrote on 2022-09-06, 21:58:

The old versions of DirectX don't require additional files to use the software emulation features.

A confusing part, which software emulation are you talking about? Do you mean all of HAL SW (HEL), Reference device, RGB SW, Ramp SW, MMX SW depend on a same file? I see d3dim.dll (HAL and HEL), d3drampf.dll (RAMP HW and SW and MMX too?), d3drgbf.dll (RGB HW and SW). What about Reference device?

You're mixing up things big time. DirectX evolved through a lot of versions. Its fallback support evolved too. What fallback covered and what it was named and to whom it was intended for... all those changed across DX versions.

The reference device is the latest name for a fully CPU implementation of the entire D3D pipeline. It is a development-only device and won't officially work on Windows 10/11 unless you activate developer mode. IIRC this applies to D3D10 (or 9?) and above. The same dev-only functionality was named WARP on D3D versions before the Reference device appeared (probably dating back to D3D7).

HAL & HEL are very old terms that go back to DirectX 5 at least, and apply to both D3D and DDraw. Certain features that were optional for HW at the time were automatically compensated for on the CPU (HEL).. for example HW 3D Transform-&-Lighting and HW accelerated color-key blits. The developer didn't even have to ask for it. DX activated it behind the game's back, but the game definitely knew when it was the case and could simplify the scene a bit to make it run faster on the CPU.

I'm afraid I don't remeber Ramp and RGB devices. I started coding DDraw in DX3, but moved to D3D mainly around DX7 and I vaguely remeber those terms but never interacted with them first-hand. But they sound like 3D software-rasterizers to me. However they surely don't exist for DX8 and above, which dropped DDraw completely and the only CPU-side fallback path was vertex shading/processing. And it wasn't called HEL anymore for sure, and didn't have any effect on visible quality like say point-vs-trilinear filtering, which is what you usually see between a hardware and a software rasterizer. CPU-side vertex processing lived long because you typically have a small number of vertices to process compared to pixels. Anyways, CPU-side vertex processing also got dropped with D3D10 since all HW at that time supported vertex shaders.

Anyways, those fallback paths aren't something you could carry from one DX version to another. If it was an official public component, then you shouldn't need any additional DLLs for it. A developer-only fallback component doesn't ship with public DX redistributables. Proper installation of those come via Developer Mode or the DX SDK for older DX versions. And those dev-only fallback paths were usually accompanied by additional software support like the DirectX Control Panel (not DXDiag) to control them.

Your answer was spot on. You could help me on:

wbahnassi wrote on 2022-09-11, 07:49:

The same dev-only functionality was named WARP on D3D versions before the Reference device appeared (probably dating back to D3D7)

Do you mean WARP is the dev only functionality available on pre-D3D7. Are you talking about the Windows Advanced Rasterisation Program? That came in with support for D3D10 till D3D12 (FL9_1 - 12_2(?)). And it supports Windows Vista+.

Unfortunately I don't know of any other WARP that existed before D3D7.

wbahnassi wrote on 2022-09-11, 07:49:

DX activated it behind the game's back, but the game definitely knew when it was the case and could simplify the scene a bit to make it run faster on the CPU.

Games then had a Software mode. Did they always make use of HEL?

wbahnassi wrote on 2022-09-11, 07:49:

and the only CPU-side fallback path was vertex shading/processing.

Basically you meant that it is a type of HEL, original HEL which used to do "simpler" calculations on CPU, but this HEL doing the "original" calculation but only one operation - vertex processing/shading? And that is is no longer called HEL but Software Vertex Processing?

Additionally can you tell how developers tested against driver bugs if Reference device didn't exist before D3D7?

I think i've only seen ramp mode on retained mode games, and some Hasbro/Millennium games (Frogger, Beast Wars)

The 'reference rasterizer' wasn't ever used in any game. I've only ever tried it when messing about the DirectX 6.1 SDK way back in the day as it was the only way to get their bumpmap earth demo going then when no hardware supported it and that ran slower than molasses. The key word here is "reference". It's not going to be any practical for gaming purposes as you might think.

leileilol wrote on 2022-09-11, 23:19:

I think i've only seen ramp mode on retained mode games, and some Hasbro/Millennium games (Frogger, Beast Wars)

The 'reference rasterizer' wasn't ever used in any game. I've only ever tried it when messing about the DirectX 6.1 SDK way back in the day as it was the only way to get their bumpmap earth demo going then when no hardware supported it and that ran slower than molasses. The key word here is "reference". It's not going to be any practical for gaming purposes as you might think.

Yes for me as well. I saw RAMP in SOTE, Frogger 1, Agile F11X, Test Drive 6. The first one didn't need Retained mode to run.

Well I am curious, how do you enable the reference device in DirectX6.1, since the bumpmap demo crashes on my WinME instantly.