Just in time for the Pi 5.
You've been around here long enough to know that release dates are never announced in advance.
False: https://www.raspberrypi.org/forums/view ... p?t=245947
That soon? I'd expect more around the time of the Pi6 or Pi7.
Like the Pi 4B, a 64-bit version of Raspbian may happen sooner than people think.
W. H. Heydt wrote: ↑Sat Aug 24, 2019 5:45 pmThat soon? I'd expect more around the time of the Pi6 or Pi7.
The first 90% of effort on a software project takes the first 90% of the time. The remaining 10% of the effort takes the remaining 90% of the time.Paul Hutch wrote: ↑Mon Aug 26, 2019 1:20 pm
From 20 days ago at the beginning of this thread:
The problem with the last 10% taking a disproportionate amount of energy was solved recently by what is called agile methodology: Simply put the code in production when the project 90% finished.
Some people, especially those with a hardware background, would query what is recent about software development doing that. Here's looking at you MS. Obligatory disclaimer: Other software producers are available.
I was rather surprised when Raspbian Buster was released ahead of Debian officially releasing Buster. Of course that was more than 90% complete at the time.
Gentoo64 is A72 optimised, for a ?% improvement over A53.Here is a list of reasons people have mentioned that favour 64-bit:
General speed improvements resulting from twice the registers.
Specific speed improvements resulting from the availability of fast 64-bit integer arithmetic.
Memory management techniques based on having a virtual address space much larger than physical space that benefit the kernel, databases, parallel processing and garbage collectors.
Additional security resulting from 64-bit address space layout randomization.
More 32-bit regressions are introduced in open source software as a result of development targeting 64-bit architectures.
Some software is 64-bit only.
Did I miss anything?
We did find some odd results with window compositing prior to Pi4 release, cannot remember if we ever determined the bottleneck.pica200 wrote: ↑Tue Aug 27, 2019 5:57 amHas this been observed anywhere else yet? Enabling window compositing seems to slow graphics down by a lot. Especially noticeable through high rendering lag. I think Raspian suffers from the same problem but since lxde takes basically nothing it's not so noticeable. But on xfce on a full 64 bit OS it's very noticeable (yes, GPU driver is working and loaded as Xorg.0.log reveals (glamoregl with V3D)). Driver bug?
I do keep an eye on changes to the Linux fork.
So it is a driver bug i guess. Another thing i found is high audio latency through HDMI fixed by tsched=0. After i saw that i did some research and found on the Arch Wiki it's a known problem with a few drivers. Something new i found is enabling non-power of 2 textures in snes9x-gtk and going into fullscreen heavily corrupts graphics creating flickering artifacts all over the place. This may or may not be a driver bug aswell not sure (some GPUs want this alignment as far as i know).
Here are two that became apparent in this thread, despite not arising in the earlier 64-bit mega-topics:
Mesa v3d exposes GL_ARB_texture_non_power_of_two and GL_OES_texture_npot. If the hardware doesn't inherently support npot it should fall back to software for compliance, running slowly but not with artifacts. However, this doesn't rule out a bug in snes9x-gtk, or Xorg etc.pica200 wrote: ↑Tue Aug 27, 2019 1:43 pmSomething new i found is enabling non-power of 2 textures in snes9x-gtk and going into fullscreen heavily corrupts graphics creating flickering artifacts all over the place. This may or may not be a driver bug aswell not sure (some GPUs want this alignment as far as i know).
Yeah, only happening with 16 bit textures. Changing to 32 bit textures fixes it but makes flickering effekts appear as solid color.
It uses the exact same kernel Raspian and Gentoo use from the RPi fork on GitHub. The only difference really is in the userland software which is pretty bleeding edge but not as much as Arch. GPU support is not even official yet you can enable it renaming the 99-fbturbo.conf and to fix the compositing slowdown you have to disable that in the window tweaks settings. After that it's working fine for the most part. When i tried higan and switched it to the OpenGL renderer it gives errors on program start about being unable to init OpenGL. But on the other hand stuff like browsers seem to be happy with OpenGL.
Just tested and I see the same issue on Raspbian 32-bit. Persists with LIBGL_SOFTWARE_ALWAYS=1 so I suspect it's more likely a higan bug than a driver problem.
I mean does this not happen with a 32-bit kernel + Mesa (e.g Raspbian)? Due to the title and context of this thread you implied that the npot bug is 64-bit-specific.
Good to hear. Would have been strange if that distro behaved much differently than the others. I have not tried Dolphin yet and not sure if it's worth it considering the poor performance right now. I still would like to see a real VC6 driver with Vulkan support. That would make a real difference imho.
Yeah, did not say it's a driver bug. Everything else is happy with it as said. Probably should report this to byuu.
Misunderstood. I have not tried this on Raspian but may do that later (need to search for another unused microSD). It's very likely not 64 bits specific.
Pi4 can technically address 16GB, and I would think a decent 64bit Raspbian will eventually become available for it. No need to wait for the Pi5.CypherOz wrote: ↑Fri Aug 30, 2019 12:39 amBesides the obvious address space, 64bit chips also (usually) have the following benefits:
RPi5C+ (wishing) will have at least 16GB support and 64bit Raspian
- Wider data paths and bigger better caches
- More registers thus faster running programs
- Better special instructions (SSE MMX etc.)