On Sat, 25 Apr 2020 17:07:21 GMT, Kevin Rushforth wrote:
>> @kevinrushforth
>> Member
>> kevinrushforth commented Apr 18, 2020
>>
>> I think most of those are good suggestions going forward. As for the
>> performance drop, the only place we've seen it so
>> far is on graphics accelerators that
>
> Will there also be any performance drop in case you just use the default
> parameters for the lighting?
That's what we're testing.
The default, which corresponds to the current lighting, should not need
> any additional computations
> and thus no performance drop.
But there is no way to
Am 25.04.20 um 19:09 schrieb Kevin Rushforth:
On Fri, 24 Apr 2020 05:06:56 GMT, Phil Race wrote:
Here is a slightly modified test program. It fixes a compilation error in the
previous, and also adds a system property
to set the number of quads:
It creates 200 quads by default. If you need to
On Fri, 24 Apr 2020 05:06:56 GMT, Phil Race wrote:
>> Here is a slightly modified test program. It fixes a compilation error in
>> the previous, and also adds a system property
>> to set the number of quads:
>> It creates 200 quads by default. If you need to increase this or decrease it
>> to
On Fri, 24 Apr 2020 01:50:11 GMT, Kevin Rushforth wrote:
>> I think most of those are good suggestions going forward. As for the
>> performance drop, the only place we've seen it so
>> far is on graphics accelerators that are a few years old by now. Integrated
>> graphics chipsets (such as
On Sat, 18 Apr 2020 15:45:32 GMT, Kevin Rushforth wrote:
>> I discussed this with a graphics engineer. He said that a couple of branches
>> do not have any real performance impact
>> even on modern mobile devices, and that, e.g., on iOS 7 using half floats
>> instead of floats was improving
On Fri, 17 Apr 2020 16:02:12 GMT, Nir Lisker wrote:
>> Conclusion: The new shaders that support attenuation don't seem to have much
>> of a performance impact on machines with
>> an Intel HD, but on systems with a graphics accelerator, it is a significant
>> slowdown.
>> So we are left with
On Wed, 15 Apr 2020 20:59:40 GMT, Kevin Rushforth wrote:
>> Here are the results on Phil's machine, which is a Mac Book Pro with a
>> graphics accelerator (Nvidia, I think).
>>
>> Without the patch:
>> 2000 quads average 8.805 fps
>>
>> With the patch:
>> 2000 quads average 4.719 fps
>>
>>
On Tue, 7 Apr 2020 23:03:21 GMT, Kevin Rushforth wrote:
>> @arapte Can you please test the performance changes too?
>
> I think @arapte has a similar MacBookPro model to mine.
>
> I think @prrace might be able to test it (I'll sync with him offline).
Here are the results on Phil's machine,
On Wed, 15 Apr 2020 20:59:29 GMT, Kevin Rushforth wrote:
>> I think @arapte has a similar MacBookPro model to mine.
>>
>> I think @prrace might be able to test it (I'll sync with him offline).
>
> Here are the results on Phil's machine, which is a Mac Book Pro with a
> graphics accelerator
On Thu, 2 Apr 2020 12:59:11 GMT, Nir Lisker wrote:
>> I have added few comments, but have not run tests and sample yet.
>
> @arapte Can you please test the performance changes too?
I think @arapte has a similar MacBookPro model to mine.
I think @prrace might be able to test it (I'll sync with
On Fri, 3 Jan 2020 09:26:43 GMT, Ambarish Rapte wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Attenuation and range changed internally to floats from doubles
>
> I have added few comments, but have not run tests
On Tue, 17 Mar 2020 02:50:28 GMT, Nir Lisker wrote:
>> Updated test case:
>> [attenTest2.zip](https://github.com/openjdk/jfx/files/4332937/attenTest2.zip)
>
> On Win 10 with an AMD RX 470 4GB I get the following:
>
> Without the patch:
> 200 quads average 113 fps
> 5000 quads average 11.5 fps
On Sat, 14 Mar 2020 15:31:18 GMT, Kevin Rushforth wrote:
>> 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
On Wed, 11 Mar 2020 21:35:55 GMT, Kevin Rushforth 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
On Sat, 14 Mar 2020 15:29:59 GMT, Kevin Rushforth wrote:
>> 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
On Tue, 10 Mar 2020 22:41:26 GMT, Kevin Rushforth wrote:
>> @kevinrushforth Can you have a look at the test app? I would like to get
>> this moving so we would have time to get the
>> rest of the lighting enhancements into 15.
>
> I'll take a look. My quick thought is that we need some sort of
On Tue, 10 Mar 2020 18:52:23 GMT, Nir Lisker wrote:
>> Looks like the `jcheck` bot removed the `rfr` label because the CSR isn't
>> complete. An incomplete CSR should be treated
>> the same way as an insufficient number of reviewers. I filed
>>
On Wed, 5 Feb 2020 13:48:45 GMT, Kevin Rushforth wrote:
>> We have a few performance tests in apps/performance, but I don't know how up
>> to date they are. They might give you a
>> starting point on how to measure FPS, but really the harder part is going to
>> be coming up with a workload --
On Mon, 17 Feb 2020 01:53:18 GMT, Nir Lisker wrote:
>> Looks like the `jcheck` bot removed the `rfr` label because the CSR isn't
>> complete. An incomplete CSR should be treated the same way as an
>> insufficient number of reviewers. I filed
>>
On Wed, 5 Feb 2020 13:48:45 GMT, Kevin Rushforth wrote:
>> We have a few performance tests in apps/performance, but I don't know how up
>> to date they are. They might give you a starting point on how to measure
>> FPS, but really the harder part is going to be coming up with a workload --
>>
On Fri, 10 Jan 2020 00:34:18 GMT, Kevin Rushforth wrote:
>>> This will need a fair bit of testing to ensure that there are no
>>> regressions either in functionality or (especially) performance, in
>>> addition to tests for the new functionality.
>>
>> Which tests for the new functionality
On Thu, 9 Jan 2020 18:00:19 GMT, Nir Lisker wrote:
>> The error was for the cases of 2 and 3 lights (I was testing 1) and should
>> be fixed now. My fault with copy-paste... that's why we use loops, but I
>> guess this is some optimization for the es2 pipeline. I wonder if it's
>> really
On Sat, 4 Jan 2020 18:22:29 GMT, Nir Lisker wrote:
>> Right. This needs to talk about pixels. Perhaps there is a way to make it
>> more clear that we are talking about pixels that are part of a rendered
>> Shape3D, but I don't have a good suggestion right now.
>
> Maybe
>
> A light source
On Fri, 3 Jan 2020 23:02:56 GMT, Nir Lisker wrote:
>>> I still need to test your sample app on Mac.
>>
>> I get the error with your sample app. It fails on Mac or Linux (Ubuntu
>> 16.04) with the same error as I reported above.
>
> The error was for the cases of 2 and 3 lights (I was testing
> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264
The pull request has been updated with 1 additional commit.
-
Added commits:
- 66cdab32: Attenuation and range changed internally to floats from doubles
Changes:
- all: https://git.openjdk.java.net/jfx/pull/43/files
-
26 matches
Mail list logo
