On Wed, 11 Mar 2020 21:35:55 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> I'll take a look. My quick thought is that we need some sort of test with a >> reasonable number of large boxes (so that >> it is fill-limited). If there isn't such a case, and the 3D rendering is >> always node-limited, then the shader >> performance doesn't really matter all that much. I suspect we should be able >> to find a case where it does, but we'll >> see. > > I did some limited testing today with a modification to the test program you > attached to create a MeshView with 200 > large quads (400 triangles) in a single node. This will eliminate the node > overhead. I can confirm that it is fill rate > limited, because when I send the exact same amount of data, but make the > triangles small, the frame rate goes up as > expected. It sill looks like it isn't shader limited, though, at least on my > Windows 10 machine, which has an Intel > UHD Graphics 630. More testing is needed on other platforms. I'll share the > mods to the test program when I have time, > but it's basically just creating a set of quads on top of each other by > reusing the same 4 points in each pair of faces. I'll attach the above modified testcase that I ran. I ran it on a relatively new Windows 10 laptop and a rather ancient MacBook Pro. I had to drastically reduce the number of quads on the Mac, but the results are similar: no significant difference between the current code and the proposed patch for point lights (without attenuation). I'd like to see results on a recent machine with a graphics accelerator (either NVIDIA or AMD/ATI) to see if the new shader hurts performance there, but I suspect it will be fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/43
