Will Blending Unit Accuracy ever be ported to Direct3D11?

[dabore]

It is a feature supported by all hardware, and if the hardware doesn't support it, it means it doesn't need it D3D give you a version every 5 years, OpenGL got new extensions every years. So D3D can only lag behind OpenGL.

The feature is really basic, it allow the application to flush (invalidate) the texture cache. So the following pattern is well defined
* write into frame buffer
* flush cache
* read frame buffer

why is this an issue? cause you need the framebuffer texture? and fast? how does negative alpha in the framebuffer compute in a standard blend unit?

[seoulgamer]

It's not PCSX2's responsibility to support a locked down API because driver manufacturers have unoptimized drivers.

I don't agree. Developers should make a reasonable effort to support the most common types of hardware their emulator will run on. I can understand people not wanting to support Macs, that's a huge burden, but leaving AMD users out of most improvements to the emulator is a real shame.

[jesalvein]

I don't agree. Developers should make a reasonable effort to support the most common types of hardware their emulator will run on. I can understand people not wanting to support Macs, that's a huge burden, but leaving AMD users out of most improvements to the emulator is a real shame.

depends.
if AMD doesn't want to make proper drivers, who are we to tell them to do their job correctly ?

[gregory]

why is this an issue? cause you need the framebuffer texture? and fast? how does negative alpha in the framebuffer compute in a standard blend unit?

The issue is that you don't know what/which data is read. If you don't flush the cache, you can get a value from the texture cache. The value could be an old frame buffer value. You have N fragments shader that run out-of-order that must execute in-order a blending operation such as

Code:

destination = src * alpha + destination * (1 - alpha)

In theory the work (order) is done by the blending unit. But we can't use the unit.

I don't agree. Developers should make a reasonable effort to support the most common types of hardware their emulator will run on. I can understand people not wanting to support Macs, that's a huge burden, but leaving AMD users out of most improvements to the emulator is a real shame.

Sure, of course AMD doesn't need to make any effort to provide a working driver. The free driver (partially done by AMD) is much faster... OpenGL is mandatory for Linux (obviously Dx isn't available). OpenGL works everywhere but on the AMD windows driver. We even provide multiples testcase to AMD so they can fix some major bugs, so far no success. I don't think the solution is to code a dedicated plugin for AMD GPU.

Based on polaris/vega energy inefficiency, you will get much better performance (even in D3D) with a fanless pascal GPU.

[dabore]

The issue is that you don't know what/which data is read. If you don't flush the cache, you can get a value from the texture cache. The value could be an old frame buffer value. You have N fragments shader that run out-of-order that must execute in-order a blending operation such as

Code:

destination = src * alpha + destination * (1 - alpha)

In theory the work (order) is done by the blending unit. But we can't use the unit.

yeh. i know that parallel shader problem. when you blend pixel 1 and write the framebuffer result, the pixel 2 shader executes in parallel and if using the bilinear filter it could or could not sample the pixel 1 result write as the src. the inaccuracy not knowing if you have the other per pixel result or not. i'd assume the result is not there. i got no clue tho. the ps2 got 8 pixel pipes (?). how'd that do it? how parallel is that?

tho... testing material. if computed in order you could use that. imagine you fill a polygon or unlit line with additive samples. just adding 1 every pixel, in order you'd get x0 = 0 and x256 = 256 white. funky mechanic. how does the ps2 actually deal with that? i got no clue.

[seoulgamer]

The issue is that you don't know what/which data is read. If you don't flush the cache, you can get a value from the texture cache. The value could be an old frame buffer value. You have N fragments shader that run out-of-order that must execute in-order a blending operation such as

Code:

destination = src * alpha + destination * (1 - alpha)

In theory the work (order) is done by the blending unit. But we can't use the unit.

Sure, of course AMD doesn't need to make any effort to provide a working driver. The free driver (partially done by AMD) is much faster... OpenGL is mandatory for Linux (obviously Dx isn't available). OpenGL works everywhere but on the AMD windows driver. We even provide multiples testcase to AMD so they can fix some major bugs, so far no success. I don't think the solution is to code a dedicated plugin for AMD GPU.

Based on polaris/vega energy inefficiency, you will get much better performance (even in D3D) with a fanless pascal GPU.

I use a fanless 1050 Ti in my current machine, but I still need to run the case fans or it throttles...a fanless heatsink case would be more effective, but they only support integrated Intel/AMD graphics.

Anyway, I thought that requesting development on Direct3D 11 might better than asking for Vulkan since it already has a working plugin, but if you're that stretched as things stand I suppose there's nothing to be done.

[tsunami2311]

I use a fanless 1050 Ti in my current machine, but I still need to run the case fans or it throttles...a fanless heatsink case would be more effective, but they only support integrated Intel/AMD graphics.

Anyway, I thought that requesting development on Direct3D 11 might better than asking for Vulkan since it already has a working plugin, but if you're that stretched as things stand I suppose there's nothing to be done.

if you know any D3D developers send them to pcsx2, there hasnt been D3D dev since gabest? and and i not even sure he active anymore? Everything is Opengl cause Gregory is linux and there opengl is getting the love, i still think he one hardest working dev's here? if his commits are any indication

[seoulgamer]

if you know any D3D developers send them to pcsx2, there hasnt been D3D dev since gabest? and and i not even sure he active anymore? Everything is Opengl cause Gregory is linux and there opengl is getting the love, i still think he one hardest working dev's here? if his commits are any indication

Stenzek from the Dolphin forums knows Direct3D well, he developed the backend for Dolphin. But unfortunately I think he's busy with Dolphin work as well.