Posts: 5.076
Threads: 18
Joined: Oct 2010
Reputation:
154
03-20-2015, 12:53 PM
(This post was last modified: 03-20-2015, 12:54 PM by willkuer.)
Actually I am a bit stupid..
For sure the gs seems to be cpu depending... otherwise you wouldn't need different instructions sets or they wouldn't make any difference (at least in HW mode).
Still I thought that 99% GS means that the GS thread on the cpu is busy waiting ( while(waitforgpu()) {} ) for response and therefore consumes the cpu. So even if the cpu is at full performance it is still a gpu bottleneck and an artificial cpu bottleneck that would be solved in the instant the gpu would respond.
(I would guess pcsx2 uses a lot of busy waiting to remove latency)
Posts: 8.598
Threads: 105
Joined: May 2014
Reputation:
168
Location: 127.0.0.1
03-20-2015, 12:55 PM
(This post was last modified: 03-20-2015, 01:19 PM by ssakash.)
(03-20-2015, 09:52 AM)gregory Wrote: The new API allows you to send more vertex data to the GPU and to use more draw call. The PS2 have already a maximum number of draw calls and it isn't 1 million 
yeah, by the given reports the draw call rate is nine times faster but, I don't know how it will offer performance boost since, it doesn't help in the switching of the render targets. care to explain the process In-depth ?
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
The new API won't remove the way. You can do them differentely (and be more clever). In the end you still need to wait the rendering if you want to read the texture. You still need to flush current stuff if you change target/alpha/ (aka hardware stuff)
The thing is the drawing pipeline of GSdx is based on the drawing pipeline of the ps2. For example the ps2 sends textures/changes blending/.... every draw. It was efficient on ps2, it isn't on PC. Vulkan allows you to use the pipeline in a different way that it is better suited to new architecture.
Anyway don't worry, I'm sure globally it will increase the perf but maybe not a factor 2×-10×. However it will increase a lot the complexity. It will move thousands of line of codes from the drivers to GSdx.
Which in-depth process?
Posts: 8.598
Threads: 105
Joined: May 2014
Reputation:
168
Location: 127.0.0.1
03-20-2015, 01:29 PM
(This post was last modified: 03-20-2015, 01:30 PM by ssakash.)
(03-20-2015, 01:14 PM)gregory Wrote: Which in-depth process?
On how the faster draw call rate will provide to be a Increase in performance. (since, render targets are used as texture in the draw calls,I'm not sure on how it will provide to be a performance boost) so, could you provide a brief explanation on that ?
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
A draw call is 3 big steps.
1/ validate the cmd
2/ send the cmd to the gpu
3/ do the draw
First step will be removed so it will decrease cpu usage. However a debug mode of the driver would have been enough.... Note on APU, less cpu => less watt => more watt for gpu => less throttle of the gpu => fps++ (actually - instead of --)
On 2nd step, maybe it would be more efficient to send a batch of draw call instead one. Driver likely does this kind of stuff but if you want to read a texture during the transfer you're screwed. Driver doesn't know the future. The application can predict it, therefore you can group some transfers in an efficient way.
Api won't change the behavior of step3.
Posts: 8.598
Threads: 105
Joined: May 2014
Reputation:
168
Location: 127.0.0.1
03-20-2015, 01:58 PM
(This post was last modified: 03-20-2015, 02:35 PM by ssakash.)
If I understand your statement correctly then, fewer draw calls means that gpu can transform and render much faster than you can submit them. If we submit fewer Textures with each call, then the CPU will be almost full of usage and the GPU will be idle. so, The CPU won't be able to keep up with the GPU fast enough. hence, this process will put the whole toll on the CPU. what DX12 does is entirely opposite to it, isn't it ? Is this concept correct ?
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
I don't know for directx but I'm sure they use a bit of multithread (Direct 3D). I mean when you call any opengl command, it often returns very quickly. Honestly you don't need a new API to multithread a sub-layer of the driver. Beside what does this layer exactly do ? I think you can run the full driver into another thread than the rendering thread. Most of the time you don't need any sync (all write). So when the driver send the data to the GPU, the application ask the driver more work. Reality is more complex than this picture. The real gain of this new API is on mobile and APU. Desktop will gain new effect but I won't expect a 3x gain on frame rate (or in low resolution/filtering situation)...
