Posts: 3.526
Threads: 6
Joined: Dec 2013
(08-28-2017, 05:56 PM)gregory Wrote: 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?
Sponsored links
Posts: 16
Threads: 1
Joined: Aug 2017
Reputation:
0
(08-28-2017, 08:10 PM)JMC47 Wrote: 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.
Posts: 30.365
Threads: 16
Joined: Dec 2008
Reputation:
638
Location: 127.0.0.1
(08-28-2017, 09:45 PM)seoulgamer Wrote: 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 ?
CPU : AMD Ryzen 7 3800X
Mobo : Asus PRIME B450-PLUS
GPU : NVIDIA GeForce RTX 3070
RAM : 16 Go
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
08-29-2017, 10:03 AM
(This post was last modified: 08-29-2017, 10:04 AM by gregory.)
(08-28-2017, 08:54 PM)dabore Wrote: 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.
Quote: 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.
Posts: 3.526
Threads: 6
Joined: Dec 2013
08-29-2017, 05:15 PM
(This post was last modified: 08-29-2017, 05:15 PM by dabore.)
(08-29-2017, 10:03 AM)gregory Wrote: 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.
Posts: 16
Threads: 1
Joined: Aug 2017
Reputation:
0
(08-29-2017, 10:03 AM)gregory Wrote: 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.
Posts: 1.977
Threads: 25
Joined: Sep 2009
Reputation:
31
(08-29-2017, 09:23 PM)seoulgamer Wrote: 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
Posts: 16
Threads: 1
Joined: Aug 2017
Reputation:
0
(08-29-2017, 10:04 PM)tsunami2311 Wrote: 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.
|