New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Demos/Graphics/Wiggling regressed from 17 fps to 8.3 fps between a11 and b1 #3561

Closed
gohai opened this Issue Aug 9, 2015 · 16 comments

Comments

Projects
None yet
4 participants
@gohai
Contributor

gohai commented Aug 9, 2015

Please close if this is a known.. FPS in the demo halved for me on the Raspberry Pi using the new Mesa driver. @JakubValtar?

@benfry benfry added the opengl label Aug 9, 2015

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Aug 9, 2015

Contributor

Hi @gohai,

do all faces in the Wiggling example you've been running have circular holes in them or only three of them? I'm trying to figure out if you are using the old version or the new version, because I updated this example recently.

Could you please copy and paste this version into both 3.0a11 and 3.0b1 and tell me how fast it is?

Contributor

JakubValtar commented Aug 9, 2015

Hi @gohai,

do all faces in the Wiggling example you've been running have circular holes in them or only three of them? I'm trying to figure out if you are using the old version or the new version, because I updated this example recently.

Could you please copy and paste this version into both 3.0a11 and 3.0b1 and tell me how fast it is?

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Aug 9, 2015

Contributor

Hi @JakubValtar, greetings from Vídeň!

I tried with the version you linked: it's 8 fps on 3.0b1 and 22 fps on 3.0a11. Looks similar visually.

Contributor

gohai commented Aug 9, 2015

Hi @JakubValtar, greetings from Vídeň!

I tried with the version you linked: it's 8 fps on 3.0b1 and 22 fps on 3.0a11. Looks similar visually.

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Aug 10, 2015

Contributor

Thanks @gohai :)

(Un)fortunately, both releases run the same on my machine. If you have some time, I'd like to ask you for help.

I identified some changes which could cause the framerate drop and I need you to test which one it was. Could you please build the repo at these commits and report the framerate?

Edit: (sorry, linked to wrong commits, now fixed)
71c688d
07e9403
deb29b3

It's okay if you don't have time for this, but I can't solve it without identifying the commit which caused it (and you seem to be the only one running on Pi).

Contributor

JakubValtar commented Aug 10, 2015

Thanks @gohai :)

(Un)fortunately, both releases run the same on my machine. If you have some time, I'd like to ask you for help.

I identified some changes which could cause the framerate drop and I need you to test which one it was. Could you please build the repo at these commits and report the framerate?

Edit: (sorry, linked to wrong commits, now fixed)
71c688d
07e9403
deb29b3

It's okay if you don't have time for this, but I can't solve it without identifying the commit which caused it (and you seem to be the only one running on Pi).

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Aug 10, 2015

Contributor

71c688d already has the low fps with the updated sketch you linked, skipping the other commits.

Since I had to manually make a few changes to the commit to get it to run on the Pi (updated build.xml, new JOGL, two shader hacks), I am now also trying plain a11 with the same modifications on top, to be sure.

Contributor

gohai commented Aug 10, 2015

71c688d already has the low fps with the updated sketch you linked, skipping the other commits.

Since I had to manually make a few changes to the commit to get it to run on the Pi (updated build.xml, new JOGL, two shader hacks), I am now also trying plain a11 with the same modifications on top, to be sure.

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Aug 10, 2015

Contributor

I quickly disabled SAVE_SURFACE_TO_PIXELS_HACK in 71c688d, and yes, it's that very commit (got 21+ fps).

Is there a way to establish whether this hack is needed on a particular platform? If not, could we potentially disable it on the underpowered Pi? (@codeanticode)

Thanks!

Contributor

gohai commented Aug 10, 2015

I quickly disabled SAVE_SURFACE_TO_PIXELS_HACK in 71c688d, and yes, it's that very commit (got 21+ fps).

Is there a way to establish whether this hack is needed on a particular platform? If not, could we potentially disable it on the underpowered Pi? (@codeanticode)

Thanks!

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 11, 2015

Member

From the looks of #3559 it seems like SAVE_SURFACE_TO_PIXELS_HACK may not even be working as intended. But I think @codeanticode has some ideas about how to fix this. Who's taking this one?

Member

benfry commented Aug 11, 2015

From the looks of #3559 it seems like SAVE_SURFACE_TO_PIXELS_HACK may not even be working as intended. But I think @codeanticode has some ideas about how to fix this. Who's taking this one?

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Aug 11, 2015

Contributor

We are working together with @codeanticode on it.

Contributor

JakubValtar commented Aug 11, 2015

We are working together with @codeanticode on it.

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Aug 12, 2015

Contributor

@JakubValtar @codeanticode It'd be fantastic if any new scheme would also have a path for GLES2!

Contributor

gohai commented Aug 12, 2015

@JakubValtar @codeanticode It'd be fantastic if any new scheme would also have a path for GLES2!

gohai added a commit to gohai/processing that referenced this issue Aug 13, 2015

Disable SAVE_SURFACE_TO_PIXELS_HACK for ARM
This fixes P3D on Broadcom's VC IV driver. xranby writes that SAVE_SURFACE_TO_PIXELS_HACK relies on glReadBuffer & glDrawBuffer, both of which are not present on GLES2. Enabling this hack also caused a performance regression on the new vc4 driver, see: processing#3561

@codeanticode codeanticode self-assigned this Aug 13, 2015

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Aug 13, 2015

Member

Hey guys, this commit should solve most of the problems.

@gohai could you test if things work as expected and without framerate drop?

@JakubValtar could you test static sketches on integrated intel?

Member

codeanticode commented Aug 13, 2015

Hey guys, this commit should solve most of the problems.

@gohai could you test if things work as expected and without framerate drop?

@JakubValtar could you test static sketches on integrated intel?

gohai added a commit to gohai/processing that referenced this issue Aug 13, 2015

Disable SAVE_SURFACE_TO_PIXELS_HACK for ARM
This fixes P3D on Broadcom's VC IV driver. xranby writes that SAVE_SURFACE_TO_PIXELS_HACK relies on glReadBuffer & glDrawBuffer, both of which are not present on GLES2. Enabling this hack also caused a performance regression on the new vc4 driver, see: processing#3561
@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Aug 13, 2015

Contributor

Getting 21 fps with eeb9dec. Thanks @codeanticode! I'll test tomorrow with the binary driver.

Contributor

gohai commented Aug 13, 2015

Getting 21 fps with eeb9dec. Thanks @codeanticode! I'll test tomorrow with the binary driver.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Aug 13, 2015

Member

Excellent! Do you see any unintended side effects? Can you run static sketches (no draw() function, or noLoop()) without artifacts (particularly, window turning black after the first frame)?

Member

codeanticode commented Aug 13, 2015

Excellent! Do you see any unintended side effects? Can you run static sketches (no draw() function, or noLoop()) without artifacts (particularly, window turning black after the first frame)?

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Aug 13, 2015

Contributor

Will try tomorrow!

On Thu, Aug 13, 2015 at 7:38 PM, codeanticode notifications@github.com
wrote:

Excellent! Do you see any unintended side effects? Can you run static
sketches (no draw() function, or noLoop()) without artifacts (particularly,
window turning black after the first frame)?


Reply to this email directly or view it on GitHub
#3561 (comment)
.

Contributor

gohai commented Aug 13, 2015

Will try tomorrow!

On Thu, Aug 13, 2015 at 7:38 PM, codeanticode notifications@github.com
wrote:

Excellent! Do you see any unintended side effects? Can you run static
sketches (no draw() function, or noLoop()) without artifacts (particularly,
window turning black after the first frame)?


Reply to this email directly or view it on GitHub
#3561 (comment)
.

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Aug 13, 2015

Contributor

@codeanticode does not work :(((

Just white screen

public void settings() {
  size(200, 200, P2D);
}

public void setup() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
}

public void draw() { }

Swaps the image and black

public void settings() {
  size(200, 200, P2D);
}

public void setup() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
  noLoop();
}

public void draw() { }

Displays the image, no flickering

public void settings() {
  size(200, 200, P2D);
}

public void setup() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
}

public void draw() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
}

Swaps the image and default background gray

public void settings() {
  size(200, 200, P2D);
}

public void setup() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
}

public void draw() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
  noLoop();
}
Contributor

JakubValtar commented Aug 13, 2015

@codeanticode does not work :(((

Just white screen

public void settings() {
  size(200, 200, P2D);
}

public void setup() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
}

public void draw() { }

Swaps the image and black

public void settings() {
  size(200, 200, P2D);
}

public void setup() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
  noLoop();
}

public void draw() { }

Displays the image, no flickering

public void settings() {
  size(200, 200, P2D);
}

public void setup() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
}

public void draw() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
}

Swaps the image and default background gray

public void settings() {
  size(200, 200, P2D);
}

public void setup() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
}

public void draw() {
  background(255);
  fill(255);
  rect(10, 10, 80, 80);
  noLoop();
}
@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Aug 15, 2015

Contributor

Still want me to test anything?

Contributor

gohai commented Aug 15, 2015

Still want me to test anything?

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Aug 15, 2015

Contributor

Thanks for the offer!

We don't have anything right now. I'll let you know once we solve the flickering without the hack.

Contributor

JakubValtar commented Aug 15, 2015

Thanks for the offer!

We don't have anything right now. I'll let you know once we solve the flickering without the hack.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode
Member

codeanticode commented Sep 8, 2015

fixed with 3b87681, abe7b52 and ea13eda

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment