Previous Thread
Next Thread
Print Thread
Page 2 of 4 1 2 3 4
R. Belmont #122526 07/25/23 11:41 AM
Joined: May 2009
Posts: 2,191
Likes: 301
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,191
Likes: 301
Originally Posted by R. Belmont
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.

Joined: May 2009
Posts: 2,191
Likes: 301
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,191
Likes: 301
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.

[Linked Image from i.imgur.com]

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

7 members like this: Dullaron, Darkstar, mixmaster, B2K24, pmackinlay, R. Belmont
Joined: May 2009
Posts: 2,191
Likes: 301
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,191
Likes: 301
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. wink

[Linked Image from i.imgur.com]

4 members like this: Dullaron, R. Belmont, robcfg, B2K24
Joined: May 2009
Posts: 2,191
Likes: 301
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,191
Likes: 301
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:

[Linked Image from i.imgur.com]

7 members like this: Dullaron, B2K24, Luengo, anoid, mixmaster, R. Belmont
Joined: May 2009
Posts: 2,191
Likes: 301
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,191
Likes: 301
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:

[Linked Image from i.imgur.com]

3 members like this: Dullaron, Foxhack, R. Belmont
Joined: Jul 2007
Posts: 42
Likes: 2
Member
Offline
Member
Joined: Jul 2007
Posts: 42
Likes: 2
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.

Joined: Mar 2001
Posts: 17,146
Likes: 179
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 17,146
Likes: 179
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.

2 members like this: Dullaron, robcfg
R. Belmont #122559 08/02/23 04:02 PM
Joined: May 2009
Posts: 2,191
Likes: 301
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,191
Likes: 301
Originally Posted by R. Belmont
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.

2 members like this: Waremonger, R. Belmont
Joined: May 2009
Posts: 2,191
Likes: 301
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,191
Likes: 301
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.

3 members like this: mixmaster, R. Belmont, Dullaron
Joined: May 2009
Posts: 2,191
Likes: 301
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,191
Likes: 301
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:

[Linked Image from i.imgur.com]

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

4 members like this: u-man, anoid, robcfg, Darkstar
Page 2 of 4 1 2 3 4

Link Copied to Clipboard
Who's Online Now
2 members (Praxis, Dorando), 82 guests, and 0 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,285
Posts121,463
Members5,064
Most Online1,283
Dec 21st, 2022
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com