Initial Gallium3D VC5 Driver Merged Into Mesa

[phoronix]

Phoronix: Initial Gallium3D VC5 Driver Merged Into Mesa

The initial "VC5" Gallium3D driver for next-generation Broadcom graphics hardware has been merged into mainline Mesa...

http://www.phoronix.com/scan.php?page=news_item&px=VC5-Gallium3D-In-Mesa

[Marc Driftmeyer]

What? No reference to the 103 patches for DRM by AMD tonight?

[sykobee]

I hear that the chip that VC5 is included within isn't really suitable for the next RPi, so hopefully that means a new SoC is coming out at some point that is more suitable - hopefully sooner rather than later.

[darkbasic]

Congratulations, can't wait for VC5 hardware

[willmore]

FWIW, there seems to finally be a page for this SoC: https://www.broadcom.com/products/br...op-box/bcm7251

There isn't enough info to say wether it's suitable for a Rpi4 type of application. I seems to have a lot of dedicated interfaces to STB relevant chips, but it's entirely possible that those could also be disabled and used as GPIO. The chips used in the existing Rpi boards were STB chips as well.

This chip offers interfaces to 802.11ac wireless, PCI 3.0, GigE, DDR3/4. It also has two of their Brahma15 cores, FWIW. From what I can tell that core is a Coretex-A15 variant with improvements to its power efficiency. On this process (28nm) it can run up to 1.5GHz.

If this chip is to be used in an Rpi4, then it's going to be interesting how the foundation spins things to explain why going from a quad core to a dual core is 'progress'. Admittedly, two of these cores are probably just as fast as the four A53 cores for most tasks (some NEON tasks may have been faster on A53 in 64 bit mode that was never supported by the foundation). But, it is likely to come at the cost of power efficiency.

There doesn't seem to be a standard time of year for the release of new Rpi boards, but, with the pace of development, it seems that if a new board is to come it will be soon.

[starshipeleven]

If this chip is to be used in an Rpi4, then it's going to be interesting how the foundation spins things to explain why going from a quad core to a dual core is 'progress'.

With true Gigabit eth (not gigaeth on usb 2.0 which is basically fast ethernet) and true USB 3.0 (where even a single port behind a hub is enough for most SBC usage), a significantly better GPU, dual display support, and possibly a PCIe slot?

Yeah, I have a hard time thinking about what they might use to explain it is progress too.

/sarcasm

[willmore]

With true Gigabit eth (not gigaeth on usb 2.0 which is basically fast ethernet) and true USB 3.0 (where even a single port behind a hub is enough for most SBC usage), a significantly better GPU, dual display support, and possibly a PCIe slot?

Yeah, I have a hard time thinking about what they might use to explain it is progress too.

/sarcasm

I was specifically talking about the CPU. Nice 'take it out of context and make fun of it' strawman.

[juergbi]

If this chip is to be used in an Rpi4, then it's going to be interesting how the foundation spins things to explain why going from a quad core to a dual core is 'progress'. Admittedly, two of these cores are probably just as fast as the four A53 cores for most tasks (some NEON tasks may have been faster on A53 in 64 bit mode that was never supported by the foundation).

Going from slow quad core to faster dual core can make sense. However, going back from 64-bit ARMv8 to a ARMv7 chip would be odd, in my opinion.

[willmore]

Going from slow quad core to faster dual core can make sense. However, going back from 64-bit ARMv8 to a ARMv7 chip would be odd, in my opinion.

Yeah, that's the aspect of it that I found confusing. Overall, common apps will greatly benefit from the faster cores. That said, I don't know how much benefit they will get from old ARMv6-hf compiled code vs more modern ARMv7-neon optimizations. Since they never used 64-bit mode on the Rpi3, normal users aren't really missing anything.

[starshipeleven]

I was specifically talking about the CPU. Nice 'take it out of context and make fun of it' strawman.

I was just pointing out that raspi's main issue so far is much more about connectivity than raw CPU power, making your theoretical issue much less important than it may seem from your post.
Nice 'not understanding my point and acting like a victim, with bonus points by calling my point a strawman, because any whine is better if you mention logical fallacies' whine.