Home Page Forums MAME MAME Renderer WIP

I was making a program so that I could re-create the UI system I wrote at my day job that I worked for the past 6 years (currently between jobs, starting a new one in August) in order to more easily make animations for the videos that I create, and wasn't sure what to choose as a renderer.

I did some cursory searching on Google, and found a minimal D3D11 example that manages to create a 3D scene and render it in just 340 lines of code - including comments.

I had kept hearing how weird D3D10 and D3D11 were, and I'll admit that they are compared to D3D9, but that's just it: They're weird compared to D3D9 and OpenGL, which were dominant in the industry at the time.

What does this have to do with MAME? Well, how many of you are tired of installing the June 2010 DirectX 9 redistributable, or are tired of having to tell users on Windows 8 and up to do so?

In any case, my code currently crashes - I'm not bringing things up in the correct order, as I don't seem to be creating a swap chain early enough - but, have some initial output!


ETA: I know that BGFX is a thing now, but truth be told, I've been growing tired of dealing with it. It has random idiosyncrasies on some systems, it's not quite as good of an abstraction layer as it's held out to be, and it's tiresome having a nonexistent level of support. As I see it, the path forward leans primarily on a D3D11 renderer for Windows, a Vulkan renderer for Linux, and whatever it is that's allowed on macOS, then an OSD-side abstraction layer in front of all three.

Having modern standalone renderers for each OS opens the door to gradually shifting resources from a "core-owned, thrown over the fence to OSD" model which was growing increasingly archaic even when 0.106 rolled around, into a "core requests a handle for a hardware-backed buffer from OSD" model.

Much of MAME's rendering architecture still performs multiple copy operations between the time its core render system creates a texture, to the time the OSD is drawing it on-screen. Reworking this to directly fill screen-texture buffers, for example, eliminates these redundant copies.

Great idea! If -video hlsl could just become D3D11 that would solve the persistent annoyance of the redistributable until we get to the new renderer, assuming none of our other DirectX backends (dsound, dinput) require it.

That's what I'm thinking, yeah. And ideally, the "new renderer" would just be a MAME-owned abstraction layer on top of a D3D11 renderer for Windows, Vulkan for Linux (and mobiles, too, though the Yuzu and Ryujinx people have some things to say on that), and whatever it is that macOS uses.

From there, it makes it easier to more gradually transition the rendering system, rather than doing it in one enormous task.

Yeah. The more complicated/interesting part of the "new renderer" will be to unify video effects so that they're common on all backends that can handle it (and vulkan/d3d11/metal/gl4 are essentially the same level of capability). With a touch of glslang/spirv-cross so that they're actually only written once.

Metal on macOS was designed to facilitate D3D11 ports to an extent, but it's set up similarly to D3D12 and Vulkan.

And yeah, making the new renderer opt-in instead of global would be ideal. Start with the fallback where MAME renders in software and we're just blitting to the screen, add support for the common case of processing tilemaps and sprites on the GPU so we get half a million FPS in pacman on a 3080, and go forward from there.

I just did some light reading on the differences between D3D11 and D3D12 - yeah, seems like a pretty major change, so most of this work towards a D3D11 renderer is a bit worthless. I like the sound of D3D12, though, it being more low-level sounds more my speed.

Oh, I really expect the render-on-gpu to be fully optional. But we really need a better backend however we do the rendering, the per-osd video effects are beyond annoying, and bgfx not at all handling live shader compilation makes it a dead end.

After thinking about it, I'm not sure what GPU acceleration being optional gets you. If the intention is to preserve the existing F12 screenshot functionality that gets you the exact output of the driver with no post-processing, in order to be able to diff PNGs to find regressions, that can still be done. I can't think of a single platform at this point where taking a screenshot of a GPU-accelerated program is impossible, and it would be a win to be able to abandon the shitfest of code that is rendersw.hxx.

In other news, have a screenshot with things actually on-screen:


MAME currently crashes when quitting (not all resources are destroyed correctly), the initial info screen doesn't render for some reason, and as you can see, dynamic textures don't currently work. Still, it's progress. Last week was a non-MAME week for me since I had company over.

Beware! Keep GPU acceleration strictly optional. Not every office PC supports hardware 3D rendering or has Linux drivers those enable it on exotic (RasPi-like) hardware. My laptop e.g. has no modern 3D GPU at all.

And if MAME wants to be a "reference" implementation for rendering the most authentic graphics output, relying on the 3D SFX of the installed graphics card driver is a truly bad idea. E.g. you may get automatically interpolated sprite zoom pixels (blurred Atari Lynx games can look better, but are they authentic?) and all kind of image dishancer artefacts, those in future may go up to AI hallucinations those by default e.g. replace what looks like a pixelish tree with photos of an actual tree, similar like some soundcard drivers add reverb, loudness and equalizer to the sound. For a commercial game app player with emulation that is optimized for speed and "modern" image quality (upscaling etc.) the 3D graphics driver of the operating system may be an appropriate choice (with the same attitude like hacking the game code itself to run smoother or look more modern), but for MAME this needs to stay optional.

You're 17 years behind MAMEdev's thinking on all of those topics. Please try to keep up.

- Pis that we support have GPU drivers. In 2023 if your device doesn't have GPU drivers, it sucks.
- We're going to run renderer programs on the GPU. No "normal" drawing will take place so the drivers can't touch it.

Beyond that, Windler's bloviating is particularly fucking stupid and belies an abject sort of ignorance that can only come from not keeping up with his schizo meds. All of the potential "issues" cited aren't actually issues, because the person programming the renderer is in complete control of everything.

Got the info screens rendering again; it helps to update the constant buffer at the start of the frame, rather than when first encountering a screen texture.



Still left to do:
- Get the shader pipeline working again
- Get prescaling working again
- Figure out why some D3D11 resources are being leaked on exit

Currently working on getting the actual shader system (d3dhlsl.cpp) ported over to D3D11.

I finally have something showing up on-screen, but it doesn't seem quite right.

Shader system is ported over and running, but the actual post-processing is still pretty broken. That said, at least UI geometry and textures are routing through the shader system without issue:

Things are starting to look better. As far as I can ascertain, only the phosphor effect and bloom are broken right now. I thought scanlines were broken, but it was because I was doing all of my testing with the SGI Indy driver, which by default, outputs at 1288x1024 - a resolution that scanlines will naturally cause the equivalent of moiré if applied to:

Great progress. We are doing something similar at work, moving an ancient GDI rendering to the GPU.

Will moving the rendering to the GPU help with the current issues with interlaced video, such as the laserdisc games?

Obviously there is a cost to software render to textures for the GPU. I would expect the post processing of scan lines to be faster on the GPU, but does the rendering to textures negate the performance gain? Would you expect any performance improvements, if not using scan lines or other effects? Maybe the GPU could scale to 4K instead of changing resolutions?

Too many questions. Thanks for your hard work.

A-noid.

This work is just to port -video d3d9 to use D3D11, so that you don't have to install the Microsoft DirectX runtime on a new Windows 7/8/10/11 machine in order to run MAME.

There will be a more extensive new renderer down the line where doing things like a deinterlace shader could be a thing.

You're correct, that's all this is, but these two things are a bit intertwined.

I'm using this as a learning opportunity to write a brand new video backend from scratch, or at least while being able to use the existing D3D9 renderer as a guide - which hasn't been as helpful as one might think, given how much rendering APIs have changed in the intervening decade and a half.

The next step from here is to write a D3D12 renderer, and once that's working, start looking at writing a Vulkan renderer, and the equivalent macOS backend via MoltenVK. I'm going to need you to be available for that when I get around to it, RB.

More specifically, once all backends (Windows, Linux, macOS) are operating harmoniously, that's when the renderer rewrite becomes a viable thing.

Something I want to experiment with in a branch, prior to all of this, is adding the ability for drivers to request OSD resources more frequently than they currently do. Work units are currently something that the core benefits from which relies on handing out OS-side handles via the OSD layer, but beyond that, examples are pretty thin on the ground.

There are things as simple as bitmap allocation that currently exist 100% in software, but which would avoid a considerable amount of overhead if they could simply rely on being given a handle by the OSD layer. In the annoying and rare event that it's a purely software-rendering setup, or an anemic piece of hardware, then those handles can be managed in-situ by the relevant OSD module. If not, the OSD can hand off a handle to the relevant buffer in order to avoid a costly copy operation.

Quite a bit was broken compared to my original assumptions back on the 31st.

That said, all effects in raster mode are now working. This screenshot intentionally looks terrible, as it has all of the effects turned on and turned up in order to be distinctly visible:



To-do:
- Test vector screens and ensure those work
- Implement shader-based palette conversions and ditch the "copyline" functions (mainly porting over from the BGFX frontend)
- Massive amount of code cleanup
- Eliminate as many redundant state-set calls as possible

Hi Just Desserts,

I dont know if it helps you, but for correct vector rendering, you should refer to version 0.179 . It is the last version, that rendered vector points in vector objects. I created a report on MT some years ago.

You can test vector point rendering pretty well with HLSL .ini settings:

red_ratio (Red Output from RGB)
grn_ratio (Green Output from RGB)
blu_ratio (Blue Output from RGB)

if you use higher settings then 1.0, the points will become more and more visible. These settings are named differently in the official MAME UI. I think it is RGB power there, but not 100% sure, can’t check it right now.

MAME versions higher then 0.179 , don’t support this HLSL settings no more.

Managed to fix the bloom alignment, turns out the viewport should be rounded down to the nearest integer rather than passing in fractional viewport coordinates.



I'm ignoring the previous two posts on this page, as they're extremely premature and I'm obviously focusing on the initial bring-up, not fixing pre-existing bugs.

Those are some nice looking vectors, JD. Space Duel was a favourite game of my youth.

Wow does that look nice, JD. Pardon as I've been out of the loop on this one and may have missed something, but will this work on Linux or is that a challenge for another day?

It's Direct3D 11, so no, it obviously won't work on Linux lol.

Why is my comment removed???

You were bullying Just Desserts. His scope of work is his decision, not yours.

I dont get it, where i was bullying him? Its nonsense and in fact he is flaming me and my comments, calling them extremely premature and what not.

Your comments were premature. The code isn't in a condition to fix your bugs, so it's premature to bring them up.

Ok, i understand it now. But still, i dont want to bully him, it is not like i give him orders what to do. For me it is only important, that this thing is not forgotten. When or if this solved at any point, is of course up to him. My thoughts where "tell this better earlier, then later where people could say, why you did not mentioned it earlier.", nothing else and please just believe this.