It is nothing more than a wrapper of Direct3D.
I think it's a little bit more than just a wrapper, but definately higher level than Direct3D, maybe with some backdoors down to the driver or maybe not.
However if this would help Simutrans at all is entirely another question as from what I can tell Simutran's graphics were designed for software rendering (graphic code mixed with state code). I would imagine the lighter weight drivers and faster resource API would speed up the sort of graphics Simutrans uses.
The intermingling of state and presentation is at the core of what makes porting Simutrans to Direct3D and OpenGL difficult. In order to make use of GPUs, Simutrans needs to maintain most of the instuctions for drawing the world in VRAM from frame to frame, and only update it with visible deltas between frames. Simutrans lacks a way for getting notified that the world has changed, it happens from all over the place more or less directly into the low level data. The renderer just loops over everything, figuring what to draw from scratch every frame. Only which part of the resulting image has changed is tracked, and used to send only the parts of the screen that has changed from RAM to VRAM.
If a Direct3D/OpenGL based renderer is to simply send instructions to the GPU equalling the function calls in Simutrans renderer interface, that becomes pretty much the same amount of data to send over the bus (even more when zooming out, less when zooming in), than with the current software renderer. The other problem is that the way Simutrans draws the world, means that one has to constantly switch which image to draw. Pre-Direct3D 12 at least, such switching requires flushing the instruction stream, setting the new texture out-of-band, and then sending new instructions. This is exactly what one wants to do to get poor performance. If Direct3D 12 can do texture switches in the middle of an instruction stream, that might be a benefit, unless this still causes GPU stalls. Gathering individual images in mega-textures could reduce texture switches, but you have to find a way to make sure images drawn after each other is in the same mega-texture, which might not even be possible. As long as the 64k image limit was in place, pak64 had a hope of fitting in a single mega-texture on modern hardware. With that limit gone, the hope of avoiding texture switches was busted. At this point, it became too much for me.
