Skip to content
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

setting display_rotate in config.txt impacts performance #5

Open
WayneKeenan opened this issue Mar 1, 2017 · 4 comments
Open

setting display_rotate in config.txt impacts performance #5

WayneKeenan opened this issue Mar 1, 2017 · 4 comments

Comments

@WayneKeenan
Copy link
Owner

WayneKeenan commented Mar 1, 2017

It was reported that the HDMI rotation in config.txt has a performance impact.
Proposed solution is to instead specify the rotation at the OpenGL ES level.
Either in the Pi3D StereoCamera setup, or, if that API doesn't quite work as expected then perform the rotation 'manually' in the barrel and a copy of uv_flat GL ES shaders.

@WayneKeenan
Copy link
Owner Author

There is ~20% frame rate improvement on the Abbey demo when the display_rotate in config.txt isn't being used.

Still need to make the downstream OpenGL ES rendering changes thought.

@WayneKeenan WayneKeenan changed the title rotation in config.txt impact performance setting display_rotate in config.txt impacts performance Apr 2, 2018
@WayneKeenan
Copy link
Owner Author

this isn't needed on a Pi4 and as Pi4 is now the minimum supported hardware I'm closing this.

@WayneKeenan
Copy link
Owner Author

This isn't needed on a Pi4 for PSVR, but rotation is still needed for DK2 (see#14)

@69K-ram
Copy link

69K-ram commented Feb 9, 2021

Is it possible the rotation slowdown for 90 and 270 is because the frame buffer is stored vertically in RAM but then is read horizontally? Sorry if I didn’t explain clearly

Edit: from the Lodev raycasting page:
Raycasting works with vertical stripes, but the screen buffer in memory is laid out with horizontal scanlines. So drawing vertical stripes is bad for memory locality for caching (it is in fact a worst case scenario), and the loss of good caching may hurt the speed more than some of the 3D computations on modern machines. It may be possible to program this with better caching behavior (e.g. processing multiple stripes at once, using a cache-oblivious transpose algorithm, or having a 90 degree rotated raycaster), but for simplicity the rest of this tutorial ignores this caching issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants