[Feature Request] Remove DirectX 12 support

[niko1point0]

I have tested the emulator on Nvidia and AMD graphics cards; I have not seen any benefits from DirectX 12 in any of the games that I have tested. Many games do not work at all with DirectX 12, while fully playable in Vulkan. Can we please remove DirectX 12 from the emulator?

[AniLeo]

And what do you gain by removing D3D12 from the emulator right now?

[MSuih]

Removing it from the UI would suffice. There have been some clueless users who've selected it despite the warning.

The possible gains are avoiding the writing of dead code when modifying RSX-related functionality and that clean slate might eventually be a better starting point a horrendously out-of-date and misleading one.

[AniLeo]

GUI already says do not use, can't fix users

[dio-gh]

This can, that's the point

[MSuih]

What I mean is that is there any reason to have it visible in the first place? If someone wants to play around with a setting that's clearly never ment to be enabled then having to add it manually via config.yml woudn't be too much of a burden.

[isshininu]

DirectX 12 backend is pretty much dead. I can remember pull requests, when it was received code changes along with OpenGL and Vulkan, though. But it is gone long ago.

[Parthorisian]

Anileo commented

GUI already says do not use

Yes, of course, but removing it from the UI it seems better idea.

[jobs-git]

dont remove dx12, maybe u will not code for it but somebody will.

[AniLeo]

It will eventually be removed, I don't see the need to do it now

[kvark]

I realize that maintaining and testing DX12 backend is a huge burden that the team doesn't necessarily want. I do believe that there is a way to support DX12 without keeping the backend code.

gfx-portability aims to support DX12 as the first tier backend, and we are extremely focused on performance. It can run basic demos now at the complexity of VulkanSamples or gfx-ocean, but there is still quite a bit of work that needs to be done and issues to be resolved before it can run big applications like Dota2 or RPCS3 solidly.

Good thing is, we are working on it, and we have the Vulkan CTS to check the correctness. So I think you are safe to drop the DX12 backend, and at some point we'll start testing RPCS3 on the gfx-portability/dx12, similar to how we are testing it on Metal now in #4996. You don't need to do anything at this moment :) unless, of course, if you want to help us polishing DX12 backend.

[bitdegree67]

+1 Go vulkan! DX12 go trash

[Degerz]

And then solely put trust in the Khronos Group ? Yeah, let's not go there again since they and the rest of the architecture review board should be ashamed of themselves for their own past blunders ...

DX12 should still be the common standard for high performance graphics going into the next decade and will still stay likely supported for another decade on top of that as well. Why even drop a perfectly good standard that will get years of unquestionably excellent support from IHVs without even trying to salvage or rearchitect it ?!

I'd be far more keen on getting rid of OGL since at least one IHV is obviously attempting to sabotage the standard ...

[AniLeo]

Why support an OS specific backend when there's a better one compatible with every relevant OS?

Vulkan already replaced D3D12 in RPCS3 a long time ago, it's unmaintained, waiting for removal.

[jobs-git]

In the first place, Windows still dominates large part of consumer pc's so supporting for other platform seems not enough reason for droping existing dx12 code.

Somebody in the future could code for dx12 once vulkan and ogl programming gets saturated.

[AniLeo]

And where does Vulkan not support Windows? Furthermore, where is the advantage of using D3D12 over Vulkan on RPCS3?

You want to maintain a single OS API that brings no advantage at all over Vulkan for no reason whatsoever?

[JohnHolmesII]

@Degerz What in the world are you on about? You really think dx12 will last 20 years? You think there's some conspiracy against Vulkan?

@jobs-git

Somebody in the future could code for dx12 once vulkan and ogl programming gets saturated.

"Saturated"? And even if those code paths were "saturated" (does this mean done?), why would anyone work on dx12? dx12 isn't "better" than vulkan, and it is so far behind at this point its ridiculous.

[Degerz]

Why place BLIND trust in the Khronos Group along with the IHVs after all the horrors that they've pushed through with OpenGL and OpenGL ES ? What makes you think Vulkan won't go down a similar path or do you think that the current functionality is good enough as it is to progress a long term project like this ?

Nobody is advocating using DX12 primarily over Vulkan but there is a good reason to maintain a single OS API in a case such as DX12 when the developer and the IHV support with the preceding standards behind it have a very good track record of actually giving a damn about driver bugs ...

Just saying, keeping DX12 after coming this far with the backend should be obvious to anyone that wants some real "insurance" if something goes wrong with the Khronos Group. It's pretty clear that some members who have previously designed past open industry standards are obviously in it for themselves such Apple (Metal), AMD (ROCm) in these instances and ironically enough the one member who arguably holds it's own proprietary secrets the hardest to it's chest being Nvidia which has the best support for Khronos standards. If Microsoft ditched the Khronos Group years ago with the above offenders having a conflict of interest too then it should obviously serve as a hint to reconsider placing their faith in Khronos and it's members ...

I'm not convinced that Vulkan is anymore than just a tool to serve working functionality as a hostage to developers which is disguised as more work to them for having to refactor code after getting burned with the last "portable" industry wide standard ...

So what if DX12 is currently only a single OS API when it's inevitable that the vast majority of the market share of high performance console emulation will be on Windows 10+ regardless in the future ? The reason of driver stability along with being free of conflicting interests from vendors alone should be enough to keep further developing the DX12 backend or at least try holding on to it as much as possible ...

@JohnHolmesII Yes, why else would anyone think otherwise when Microsoft and the supporting IHVs keep actively participating in it's development ? DX12 is very clearly designed for the long haul since Microsoft and the IHVs have interest in adding and exposing more hardware features through it but with such complexity but they don't constantly short change the developers with a bunch of inferior conformance testing methodology or a bunch of driver issues that don't ever get fixed for years either like you see with Khronos members with their standards that they had their very own hands in designing. Do you honestly think Microsoft would supplant DX12 with a totally new standard so soon with their potential successor to the Windows 10 ?

[JohnHolmesII]

@Degerz I have to say, you seemed a little off in your first post, but now this is just getting out of hand. You keep talking about some horrific, unspeakably evil commited by the khronos group, but you fail to mention it. There is no such travesty. The only criticism of opengl is usually missing features, but that only happened because microsoft pulled away with dx12. This is no longer the case.

keeping DX12 after coming this far with the backend

Uhh, as I said, it hasn't come "far" at all. Do you have any fathom of how outdated the dx12 code in here is? It's very dead. Over a year of full time work has gone into opengl and vulkan since dx12 was even touched.

members who have previously designed past open industry standards are obviously in it for themselves such Apple (Metal)

Metal isnt an open industry standard, and this is more nonsense. There is no logic or reason to what you are saying. Sure, some comapnies have different hopes, notably microsoft and nvidia would prefer that dx remain the standard, whereas literally everyone else is pulling for vulkan.

DX12 is very clearly designed for the long haul since Microsoft and the IHVs have interest in adding...

I'll let you think about why there might be reason to believe dx12 wont last 20 years. Think along the lines of precedent. Special hint: why is the number 12? Could it be because there are 11 previous versions? Directx first came out in 1995, and dx12 came out with windows in 2015. All of directx lasted 20 years, but you think a single api is gonna last 20 years? It's flat out insane to think this.

[kvark]

Why place BLIND trust in the Khronos Group along with the IHVs after all the horrors that they've pushed through with OpenGL and OpenGL ES ?

OpenGL may not be the most elegant standard out there, and neither it is the most performant. But it has the longest lifetime: it survived through a series of D3D versions, 3Dfx GLIDE, S3 Metal, GCN, and more; and it's still pretty strong in the form of WebGL. Isn't API longevity precisely what you need with RPCS3? No matter whether you like Vulkan or not, it's here to stay, given how big is the momentum from IHVs to support it. It is an API where the IHVs have the strongest voice, and thus it will be supported by the most (contrary to, say, Metal, where Apple can choose the HW to ship on).

As for the D3D12 backend, and Metal, since we are at it - go for it! Implement, optimize, maintain it, if you can afford that - you'll likely get better performance and control if you go this path. That's the path Unreal Engine and Unity are going, as well as in-house AAA game engines, and it makes total sense. But it comes with a huge maintenance cost... And it seems to me that the project leadership (you know, people actually doing work) decided that it's not worth it. What I was saying earlier in this thread is that technically you don't have to maintain that backend if you want to cover D3D12, since you can use the portability layer for free.

[Degerz]

@JohnHolmesII I didn't say Khronos Group was evil, they're just incompetent and no that's not the only criticism of OpenGL. Just because Microsoft backed out doesn't mean that OpenGL's development stopped since the very same 3 desktop graphics IHVs that we see today still participated in further development of the standard but look how that turned out to be inexplicably trash in the end. Who on earth thought it was a good idea to have 'compatibility profiles" or each IHVs creating their own "separate GLSL compilers" ?

Uhh, as I said, it hasn't come "far" at all. Do you have any fathom of how outdated the dx12 code in here is? It's very dead. Over a year of full time work has gone into opengl and vulkan since dx12 was even touched.

Yes, it's outdated but that doesn't mean it needs to be instantly thrown away with couple thousand lines of code that's already invested into it. It just needs updating to achieve the same feature set as Vulkan and nobody is demanding that get's rewritten from scratch or that we adopt a new backend altogether ...

Metal isnt an open industry standard, and this is more nonsense. There is no logic or reason to what you are saying. Sure, some comapnies have different hopes, notably microsoft and nvidia would prefer that dx remain the standard, whereas literally everyone else is pulling for vulkan.

I didn't say Metal was an open standard. I only stated that some members of Khronos Group who formerly designed their previous standards only served themselves in the end as an example. "literally everyone else is pulling for vulkan" Everyone you say, eh ? It doesn't look like that to me since many AAA game developers would rather just maintain 2 backends like DX11/DX12 rather than bite the bullet with Vulkan. Are noticeable portions of mobile developers somehow supposed to be realistic targets when they likely don't want to deal with such a verbose API like Vulkan for a long time and that they'll target GLES 3 drivers ? It's not just Microsoft or Nvidia that wants to push their own proprietary standards over Khronos, the same applies with AMD as well by trying to ditch OpenCL for ROCm ...

I'll let you think about why there might be reason to believe dx12 wont last 20 years. Think along the lines of precedent. Special hint: why is the number 12? Could it be because there are 11 previous versions? Directx first came out in 1995, and dx12 came out with windows in 2015. All of directx lasted 20 years, but you think a single api is gonna last 20 years? It's flat out insane to think this.

Times have changed. This isn't the wild west of graphics standards anymore where we had a bunch of different rendering backends such as software, glide, OpenGL along with DirectX in old games and it shows since IHVs are still shipping DX9 in drivers today after 16+ years of it's release while newer OGL versions kept removing functionality. Microsoft has very clearly dominated the standards of high end graphics. It's more likely that one of the graphics vendors will either keep blocking Khronos from updating the spec or just create another translation layer so that they can stop shipping GL drivers. Hardware development is obviously slowing down since Moore's Law is dead so there's not much reason to constantly create a new standard like vendors did in the past ...

@kvark API longevity is absolutely what RPCS3 needs but I'm not even sure if that is guaranteed anymore since it already has an IHV who's drivers are in a pitiable state despite being classified as "conformant" according to Khronos. OpenGL has failed to deliver it's promise as a portable graphics API when we have defectors or IHVs who don't care enough in practice but then Khronos just makes more different standards based on it such GLES and WebGL so platform fragmentation abound regardless! I don't specifically dislike Vulkan but it's that distrust/skepticism should be exercised towards the Khronos Group who has a history of lacking foresight and some of it's members who don't have noble intentions that would either seek to block development or adoption of their new APIs ...

No offense to the work you're doing but encouraging developers to use a translation layer like gfx-rs is just adding more technical debt to a project, especially applying it to a leading edge graphics API (DX12) which is the least likely out of the bunch to have IHVs dropping driver support given some of the Khronos members haphazard history of being counterproductive. I just don't agree with the direction of dropping native DX12 support in favour giving all leverage to a part of a group who is ruthless in terms of not supporting already dubious "portable" standards which resulted in using multiple APIs anyways. (we'll see if Vulkan in the future ended up being any better than their last attempts) DX12 should serve as the complementary standard rather than defaulting to OGL of which at least one vendor is very clearly struggling at to get working (no future to be had with OGL since more issues just keep persisting) but I won't force the issue on the RPCS3 team if they don't want to maintain DX12 and I won't put it past them either for dropping it but I find it to be a shame being at the absolute mercy of a consortium with players who doesn't give a crap ...

[JohnHolmesII]

It'd be a far bigger shame to be left at the mercy of Microsoft and Windows. I don't know why you're paranoid about Vulkan just up and vanishing, but it isn't going to happen. Vulkan has ridiculous momentum compared to what OpenGL ever had. DX12 for an emulator is a joke. It should never have been implemented. Hell, the only reason OpenGL is used at all is for maturity's sake, and because the ps3 api is more closely related to it than anything, so there's an accuracy boost. But even since Vulkan has been implemented, the Vulkan backend has improved leaps and bounds, mostly due to driver support from those allegedly jaded IHVs you love bringing up.

I'm still not sure why you're so against Khronos. It's an open source consortium that was attacked by Microsoft in the aughts... a real original story there, huh? You seem to think that it was some kind of malicious incompetence over at Khronos that led to OpenGL not taking over, but that's very akin to attacking Linus Torvalds for linux not dominating the world. Vulkan IS the better option. If you don't want to believe it, I can't help you. But just look at the efforts like dxvk bringing games to linux. Look at what steam is investing in bringing games to linux. Look at the effort AMD puts into vulkan drivers for linux. Are any of those efforts perfect? No. But they are promising, and it shows, as I said, broad industry wide consensus that Vulkan is the future, not DX12. The momentum has been leaving windows and dx for years, and unless MS brings in some killer feature (ray tracing could be it, but I wouldnt hold my breath), it's going to keep on chugging away.

[bitdegree67]

DX12 CAN'T be a standard.. it's closed source and propriatery. It's a bad thing in every way.

• Vulkan have all DX12 features + other better and faster than dx12 (and cross platform)

[Degerz]

@JohnHolmesII While the idea of being at the whims of an OS vendor may not be appealing you have to be intellectually honest to admit that the architects behind it's graphics system has been far more sane in it's design decisions for over a decade that they too deserve as much of a native implementation of their technology like their competitors. DX12 has a higher minimum feature set and driver quality standards compared to Vulkan but most importantly all of that is thanks to the concessions that comes with having the feared walled garden that the community unjustly despises when it's already quickly being supplanted as the new industry wide standard compared to it's predecessor. DX12 was developed in mind before Vulkan was but I do not believe it was any less wise of a decision to adopt it during that time since it had a large userbase that also continues to grow to this day and there is still a valid reason to keep the backend such as making a performant API available for Haswell/Broadwell IGPs on Windows as well as Fermi GPUs which are still arguably a crucial segments noteworthy of attention ...

Placing all efforts into a sole consortium with a sour past is not wise when their previous tools has went rotten like OGL. I do not think that it is beneficial to ignore a performant/modern graphics API in favour of a one that full of design flaws/idiosyncrasies and not to mention it's potentially buggy implementations. Do you believe it's not enough that Khronos only has Vulkan and that it should somehow merit them more support than they already have ? Microsoft is nearly of no fault to what Khronos's predecessor inflicted upon itself. Microsoft was just one of the many former members of the OGL board who was only a single voice that dictated the spec out of the others at the time. If it wasn't indeed Khronos's malicious incompetence then how do you explain why Apple also eventually turned against them and looked elsewhere for a desperate attempt at a solution despite having invested a lot in it's technology at their early days of macOS ? Why can't we all owe up to the fact that Khronos's interests pose a sharp divide with some it's own members breaking off ? Do we always have to assume that Khronos is always somehow in the good just because they are delivering an open standard in comparison to their competitors proprietary some of which are their own participating members as well ?! (Apple, AMD, Nvidia, Microsoft)

broad industry wide consensus that Vulkan is the future, not DX12. The momentum has been leaving windows and dx for years

These statements do not match the commercial reality, DX12 is at the cusp of a floodgate of new software releases while Vulkan has yet to take off in any meaningful fashion. If you aren't trolling then I'm almost certain that the other possibility is just denial ...

[JohnHolmesII]

DX12 has a higher minimum feature set and driver quality standards

This is absurdly false

Placing all efforts into a sole consortium with a sour past is not wise

Microsoft. You just described Microsoft.

has went rotten like OGL OpenGL is not rotten, it is still widely used. Did you not notice the emulator runs OpenGL? And very well at that?

ignore a performant/modern graphics API in favour of a one that full of design flaws/idiosyncrasies

Point out these imaginary flaws for us. Vulkan is on par with DX12 in all categories.

why Apple also eventually turned against them

Because Apple tries to make everything proprietary.

Why can't we all owe up to the fact that Khronos's interests pose a sharp divide with some it's own members breaking off ?

This is incoherent

DX12 is at the cusp of a floodgate of new software releases

Such as...?

Vulkan has yet to take off in any meaningful fashion

I literally listed plenty of "meaningful fashions" in my last post. Don't ignore what hurts you.

Overall, you once again keep talking about some kind of boogeyman event. What is it? Why is khronos so evil?

[jobs-git]

While some attempt are being made for Metal in Apple, Others de-attempt what was made for Dx12 in Windows, while in fact Windows is still the most dominant consumer pc in the world.

So the reasoning that vulkan is more cross platform for a tiny number of users is not a valid reason to undo works that was done in dx12,

if u attempt to use dx12 for emulation gaming and blame it to rpcs3 for not working is the user's fault, cause it is clearly indicated that it is in experimental stage.

[JohnHolmesII]

@jobs-git its not "cross platform for a tiny number of users" its cross platform for everyone

[Triang3l]

Rewriting Xenia's rendering layer in Direct3D 12 now — not due to any religious reasons, but just because I'm doing a complete redesign of approaches to GPU emulation and you can implement ideas in Direct3D 12 really quickly.

I can say it does have some advantages over Vulkan — debugging is very nice, you always get a descriptive message if you do something wrong, even if the whole application crashes afterwards, also memory allocation is a lot more simple (you don't have that mess with memory type bits, you only need to choose between D3D12_HEAP_TYPE_DEFAULT and D3D12_HEAP_TYPE_UPLOAD, and everything (with some exceptions for MSAA surfaces) can be placed in any heap you want), and if you want to copy something or to run a compute shader — and we do that a lot, whenever we change framebuffers or untile textures — you don't need to close and reopen render passes.

The only major flaw is the lack of any official support for manual DXBC/DXIL generation, and HLSL compilation times are horrible (even without optimization, and it seems like there's no easy way to enforce vertex position invariance with HLSL/D3DCompile since they don't let you disable refactoringAllowed). Also no triangle fans or custom primitive restart index, but converting some index buffers on the CPU shouldn't be very slow.

If supporting one more API is a heavy burden that takes a significant portion of time, it would possibly be good to drop support for it (but personally I'd rather drop OpenGL in this case), but asking to remove D3D12 just because it's D3D sounds simply childish IMO.

[ruipin]

Is anyone really just asking to remove D3D12 because it's D3D though? It seems to me people are shouting at walls and completely forgetting the underlying issue(s):

Fact is, the RPCS3 D3D12 backend hasn't been updated in over an year. Fact is, it has a lot of broken/dead code and barely works. Fact is, bringing it up to speed right now would require starting almost from scratch. Fact is, there is nobody willing to maintain it. Fact is, it gives no compatibility advantages since anyone who can use D3D12 can also use Vulkan. Fact is, it takes up valuable build time. Fact is, even if it were removed, if anyone who wanted to maintain it showed up, they could just check out the D3D12 code again from the git commit history - it's not like the deletion would be permanent.

With all the facts above, it really does not matter if you trust Microsoft or mistrust Khronos, or how many users run Windows - all that matters is that the D3D12 backend doesn't work and there's nobody willing to maintain it. There is barely any reason not to remove it from builds by default, and the only reason it hasn't yet is historical (it's been there since forever) and also there's also no major reason to (other than slightly shorter build times).

If someone feels strongly that D3D12 shouldn't be removed ever and it is really important to have it work well, then how about they step up and maintain it, or find someone who wants to? Otherwise, they shouldn't be surprised if things that classify as dead/unmaintained code get removed at some point.

Personally, I think the fact that it's dead code and takes up a small but noticeable portion of build time is reason enough to remove it, but I don't really care since I already disable it on all my local builds anyway.

[JohnHolmesII]

No one is saying drop it because its D3D, or even because it's hard. There is, however, someone saying to drop Vulkan because it's khronos. DX12 is certainly a great api. It's just dead code right now. It would require a lot of work just to get it up to the level of the other 2, and then there are 3 api's to maintain. OpenGL is there because it is the most accurate, and it's what the emu started with. Even a year ago, vulkan was weak in terms of drivers and support. It is possible that opengl will be deprecated at some point, but that may be a while.

The reality is kd has stated several times he has no interest in fixing the dx12 backend. What I personally don't understand is why it should be left in the code base just in case 'godot' """"might"""" show up one day and fix it. Literally no one ever has. I don't think anyone will. And by the time they would, a full rewrite would probably be just as well.

[Triang3l]

Of course, I think nobody disagrees that the less desynchronized/duplicate code there is, the better. It would probably be the best to keep all RSX research with all the little but important details in just one place — in a form that is the most comfortable for active developers. Just maybe let's not do useless political debates here, D3D is awesome in its own ways, Vulkan is in its own.

[ruipin]

Yes, exactly my point. I don't think anyone has any issue with someone taking over the D3D12 back-end and bringing it up to speed with the rest of them. It wouldn't be a simple task, but the more back-ends the better. It's just nobody has, and who knows if anybody ever will.

Meanwhile, there's dead code being included into every build, using up precious build time (a few seconds, sure, but it accumulates when you're doing many builds during development).

The political/ideological debates have no place in this discussion.

[Degerz]

This is absurdly false

Please elaborate ? D3D has tighter conformance standards while every WDDM 2.0+ compliant GPU automatically comes with features such as dual source blending, geometry shaders, tessellation shaders, atomic operations in pixel shaders, dynamic indexing, ExecuteIndirect and logic ops as well. No Vulkan drivers are required to implement those features for comparison. D3D12 straight up has a higher minimum bar to cross whether you like it or not ...

Microsoft. You just described Microsoft.

Pretty sure it's Khronos considering 2 or so of their APIs will end up dead in the grave ...

OpenGL is not rotten, it is still widely used. Did you not notice the emulator runs OpenGL? And very well at that?

Why be deceptive about this ? I'm pretty sure Intel's proprietary GLSL compiler would say otherwise despite being a conformant implementation ... (some of the drivers are damn slow as well too)

Point out these imaginary flaws for us. Vulkan is on par with DX12 in all categories.

Pretty sure I wasn't talking about Vulkan in that instance ...

Because Apple tries to make everything proprietary.

No they really don't, I'm pretty sure Apple open sources far more often than Microsoft does cause they have low market share in every platform segment they compete in. People give too little credit for how difficult of a decision it was for Apple to break off with Khronos. Many app developers didn't want the complexity that came with Vulkan or the driver bugs that came with OGL so Apple came up with a more powerful D3D11 clone and it was universally praised by all app developers that experienced it first hand ...

This is incoherent

It isn't just Apple or Microsoft who have competing standards against Khronos. AMD and Nvidia do as well so that's a total of 4 members who's clearly frustrated with Khronos ... (Khronos has been incompetent for much of their life)

Such as...?

The list is very extensive so I'm just going to cut it down to the next 10 or so according to the order of releases by developer or publisher. Rebellion, Square Enix, EA, Microsoft, EA, IO Interactive, Capcom, EA, 4A Games and Ubisoft ... (there are other like Creative Assembly and Remedy who will keep releasing apps with a DX12 backend)

I literally listed plenty of "meaningful fashions" in my last post. Don't ignore what hurts you.

Overall, you once again keep talking about some kind of boogeyman event. What is it? Why is khronos so evil?

Yeah ...

I'm almost certain that you're just trolling at this point. Anybody can see that Metal is clearly miles ahead of everything else in the competition with DX12 being a distant second since it still serves the niche of having higher standards along with more functionality that the devs want and Vulkan is last place since it's main use case is for Android but the problem is nobody wants complexity with garbage drivers even if it's Vulkan we're talking about ...

[Zangetsu38]

Not forget also, few model gpu is only compatible DX12 and ogl, Nvidia GTX 4X0 and maybe few other also if i good remember, and for me, Dx12 is very better Vulkan

[JohnHolmesII]

ompeting standards against Khronos. AMD

Let me stop you right there. You know AMD literally gifted Khronos the basis for their API right?

Anybody can see that Metal is clearly miles ahead of everything else in the competition with DX12 being a distant second

That's the end of this discussion. There's no way to continue from here.

[ruipin]

Why are we (well, mostly a single person) still discussing whether DX12 is a better API than Vulkan or not, when that has absolutely no bearing on the actual issue, which is that the current D3D12 back-end code is broken and unmaintained, fixing it would require a complete rewrite, and nobody is willing to work on it?

Even if DX12 were the best API ever and twice as fast as all other APIs, that wouldn't change anything as far as RPCS3 is concerned.

[Zangetsu38]

Yes, i said just so, not remove dx12 render, that all ^^

[tanpro260196]

Such useless conversation. The code is already scheduled to be remove in the distant future unless someone willing to work on it before then. If you don't want it to be removed, then get your ass up and works on it. The main dev basically decided to stop giving any **** to D12 anymore. Get over it.

[Degerz]

Let me stop you right there. You know AMD literally gifted Khronos the basis for their API right?

They're also the ones who ditched OpenCL for ROCm too if you don't remember ... (AMD is much like Apple except this time it's in the compute API space after going through the realization that Khronos have clear interests against them)

That's the end of this discussion. There's no way to continue from here.

It's true but bias get's in the way when everyone just wants to ignore iOS apps of which Metal is gaining vast momentum ...

[Zangetsu38]

not sur, it is just @vlj have leaved rpcs3 project :(