Ask the Experts: ARM's Cortex A53 Lead Architect, Peter Greenhalgh

158 Comments

View All Comments

• ddriver - Tuesday, December 10, 2013 - link

  Take a look at TI's KeyStone II architecture, there are already quad core A15 based chips with powerful DSP, PCIE support, multiple 10 and 1 GBit interfaces with hardware accelerated packets and security and mind-boggling on-chip interconnect capable of over 2 TBit per second.
  
  But it is a strictly server chip, considering it doesn't even have a GPU, and it is not like consumer devices need multiport 10 GBit switches embedded.

• Xebec - Tuesday, December 10, 2013 - link

  Peter, thanks for offering your time to Anandtech!
  
  I was curious if you could talk a bit about how easy/difficult A53-derived SoCs might be to integrate into solutions that are already using A7/A9 type chips? i.e. Devices like Beagleboards, Raspberry Pis, ODROIDs, etc. Is there anything that makes the A53 particularly difficult or easy to suit to these types of devices?
  
  Also, for Micro and "regular" servers, do you see A57/A53 big.LITTLE being the norm, or do you anticipate a variety of A53-only and A57-only designs? Any predictions on market split between the A5x series here?
  
  Respectfully,
  John

• Peter Greenhalgh - Wednesday, December 11, 2013 - link

  Hi Xebec,
  
  Cortex-A53 has been designed to be able to easily replace Cortex-A7. For example, Cortex-A7 supports the same bus-interface standards (and widths) as Cortex-A7 which allows a partner who has already built a Cortex-A7 platform to rapidly convert to Cortex-A53.
  
  With servers I think we will see a mix of solutions. The most popular approach will be to use Cortex-A57 due to the performance that micro-architecture is capable of providing, but I still expect some Cortex-A53 servers and big.LITTLE too!

• san_dehesa - Tuesday, December 10, 2013 - link

  I would love to know ARM position towards open source GPU drivers now that Intel is putting a big amount of money and effort into developing theirs.
  
  It seems to me that not taking the open source road for GPU drivers (as ARM is doing) is a big mistake. Furthermore when the primary OS host their hardware is running in is Android.
  
  ARM could create much better binaries for free with the work of other talented developers and get better integration with Android in the process. That will be a great selling point for any manufacturer and possible client!
  The Lima project has currently a better performance (5% more) than the close driver distributed by ARM and it is being coded in the developers free time! It would be great to see both teams working together.
  
  What are the reasons the driver is close-source?
  - Is it that they would reveal a lot of Mali's internal core?
  - Is ARM afraid of IP sues? Having close source will deter patent trolls?
  Intel doesn't seem to have those problems.
  
  PS: The question is not about whether the drivers should be open or not just because it is morally right or wrong. Obviously it would be nice for the clients and a good selling point, but I was wondering how ARM management see one of their biggest competitor embracing open source when developing GPU drivers.

• coder543 - Tuesday, December 10, 2013 - link

  Yes! This post is excellent.

• bji - Tuesday, December 10, 2013 - link

  Seconded.

• ddriver - Tuesday, December 10, 2013 - link

  Intel makes a ton of money, plenty to purchase pretty much every IP it needs, plus it holds a lot of IP itself, so it can also trade IP with other vendors. In contrast ARM makes a modest profit, even though I guess it can still trade IP, since both nvidia and amd license ARM themselves.
  
  But it is a good point, open source GPU drivers are a crucial step towards empowering Linux and ending the MS monopoly. It is hilarious that Linux powers like 99% of the supercomputers and like 1% of the personal computers. If Linux is good enough for supercomputers, it has got to be good enough for personal computers, but the lack of good and often any drivers is what cripples Linux for the regular user.

• san_dehesa - Wednesday, December 11, 2013 - link

  I have to wonder how long it will take ARM's legal department to review the driver's code and assess risks. Even if they have part of the blob which is legally binding, they can still open up a big chunk and start chipping in on the advantages of open source developing. There are already developers knowledgeable on their architecture.
  
  ARM and other chip producers know how much of a pain is to support badly integrated blob of code. When an ARM customer have a problem with the driver, they have to communicate with ARM, wait till they receive an answer, wait till the problem is solved (if it is at all), and then integrate the new blob with their software. So many steps where you can fail! It takes so much time! Mobile products have a really short time-to-market. It would be so easy for everyone if they let their customer help out with the development. Plus, it is free!!
  
  Samsung (ARM biggest customer) have been testing Intel's products for a while and I am pretty sure that by now they have some developers who know Intel's driver architecture. Don't you think one reason when deciding which platform to choose would be support and time-to-market?

• Peter Greenhalgh - Wednesday, December 11, 2013 - link

  Hi San_Dehesa,
  
  Good questions, but I'm not familiar with the ARM GPU graphics drivers. Perhaps persuade Anand for an Ask the Expert with one of the ARM graphics team? :)

• san_dehesa - Thursday, December 12, 2013 - link

  Haha, yes, you are right! Sorry for the miss-targeted question.
  I appreciate the time you are spending here answering our question. Thank you.