[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL perf regression tests moved to GitHub; design still in flux






On Mon, Oct 1, 2012 at 5:35 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Tue, Oct 2, 2012 at 2:27 AM, Gregg Tavares (社用) <gman@google.com> wrote:
I'm not sure I follow what you're trying to explain. If I have 1 core I get this

1:[S][LONG][S][LONG][S][LONG][S][LONG][S][LONG][S][LONG]

On 2 cores I get this

1:[S][S][S][S][S][S]
2:[LONG][LONG][LONG][LONG][LONG][LONG]

In the example above I'm doing 6 short [S] and 6 long [LONG] operations where I made their size represent the time they take to execute. 

With 2 processes I can execute 4 more operations, 10 total in the same amount of time 1 core took to process 6 opretations.

1:[S][S][S][S][S][S][S][S][S][S]
2:[LONG][LONG][LONG][LONG][LONG][LONG][LONG][LONG][LONG]

That assumes I'm not GPU bound but if I'm GPU bound the only thing that matters is the GPU.

If you're not CPU bound on the rendering, and you avoid blocking calls, then it'll look a bit like this: 
JS: [s][s][s][s] (like 0.1ms)
GPU process: [s][s][s][s] [...........................................................................................................................................................swap]
Driver: [stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff]

So it really doesn't matter for the GPU bound performance measurement if you call gl.finish() because that'll just make it look like this:
JS: [s][s][s][s][...........................................................................................................................................................................finish]
GPU process: [s][s][s][s] [................................................................................................................................................. finish][swap]
Driver: [stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff][stuff]

That's not what I observe at all. The driver may do some of its operations in a separate thread/process but not all of them. I still get vastly more calls WebGL calls on multi-process than single process.

The whole point of the harness I linked to is to see how many draw calls you can make so in other words it's attempting to be CPU bound.