Page History

...

Minute takers according to this page 

August 24

Apologies:

July 12, 2021

Participants:

• Stephen (Renesas)
• Adam (Kernkonzept)
• Matti (Opensynergy)
• Gunnar (GENIVI)
• Oleksandr (EPAM)
• Kai (EB)

Minutes

• Gunnar: I met with Arm (Bernhard) and Francois Ozog (active in Linaro).  We discussed virtual platform specification, if there are additional automotive-specific hardware that need VIRTIO support (e.g. do we have a proposal for FM tuner? (No, not currently))

Discussion on the usage of virtual platforms as a hardware-portability solution:

• Gunnar: We see this trend.  I'd like to analyze this idea further, compared to for example just making stable user-space APIs and creating new kernel drivers for new hardware. 
  • => Is this not just shifting portability work "somewhere else". 
  • Let's analyze how "virtual platform API is stable" is different from "user-space API is stable" (i.e. just port drivers to new hardware..)
• Adam: BSPs that add a lot of patches to Linux get stuck on older versions.  Not using mainline.  Updating to new kernel drivers difficult (N.B. officially no APIs are stable inside Linux kernel)
• Matti: Linux kernel in particular, is an operating system kernel and a hardware-abstraction at the same time, which is challenging.
  
  • Future challenges: Value-add for SoCs could be difficult if the [hardware abstraction] API is limiting.

• The virtual platform / VIRTIO / Trout and others.  It seems the "new" distinction is a clear focus on a hardware-abstraction layer?
  • (partly agreed, discussed the existence of firmware as one abstraction already used, and on PC side the hardware it self was standardized, etc.   Overall, a complex reality)

• Summary:
  • Kernel updates are driven by fast development, security issues, etc. 
  • Fast changes, no internal API stability guarantee etc. = updating drivers is a major issue.
  • It seems this situation can't be avoided, and the industry is looking for a solution to the challenge.  
  • The theory seems to be that keeping API stable and efficiently port to new hardware, could be more feasible to do in the virtual platform.

• Discussion turned to evaluating the effort (that the industry is also considering) to create new kernel(s) instead, as a Linux alternative (for safety, and development concerns as shown above). 
  E.g. if they have a POSIX API, is that "enough".  => No... could still be a large effort to port existing functionality.
  • Gunnar: As an example, consider systemd which early on used Linux-only APIs.  And then a lot of functionality built on systemd.  Such examples makes porting software a challenge.
• Also discussed how large part of Linux' functionality is actually used in practice in the industry?
• Matti:  (Explicit example that shows the current situation)

  • io_uring recently added to Linux.  It accelerates applications a lot.  A hardware vendor that is able to use these latest features could have an advantage (hardware itself not faster, but the software runs faster).  

  • => With a virtual platform abstraction, updating to a new kernel with the new features should be feasible.

June 2021

• Regular meetings held every week.  No specific meeting minutes written.  Results in AVPS and topic planning (link below)
• AVPS v2.0 release.
• Working on deep-dive topic planning

December 14 2020 → May 2021

• Regular meetings held every week and results tracked in AVPS document and JIRA tickets.

December 7

• Participants: Stephen, Gunnar, Dmitry, Adam, Peter

• GPIO - clarified misunderstanding that referenced SCMI even though SCMI does not cover GPIO.   Closed open issues and finalized requirements.  Chapter will be done, after final polishing.
• Initial discussion on the structure of final GPU chapter (bringing together all input from previous hardware studies)
  • We might need a plausible product design scenario to support the inclusion of VIRTIO-GPU / VirGL based requirements.  Also consider how to handle a non-Linux OS, if that is included in the scenario.
    Most other requirements will lean on hardware virtualization support, but the group did not want to lose the idea of support simpler hardware too.
• Dmitry has done some updates on Camera/Media – postpone discussion to next time.

November 30

     FOCUS : GPU virtualization – Features of the PowerVR/Imagination GPUs (used in Renesas R-Car SoCs).
      - Presentation from Thomas Bruss, Renesas.

    - Discussing the opportunity for a common "model" of modern GPUs that can be the basis for shared requirements in the virtual platform standard.

November 16 - 23

Discussions captured in JIRA tickets and in the document.

November 9

Minutes pending

...

Participation planning:

• October 19 - GPU focus?  Discussion of new Mali features?
  •  Bernhard + Arm colleagues, wants to present Mali GPU
  • Adam 
  •  Dmitry still vacation            
  •  Oleksandr - vacation?
  • Daniel Stone?  Emailed last week.  Send calendar invite also.       
  • Eugen - Emailed
  •  Stephen likely interested
  •  Ozgur - Emailed              
  •  Peter
     
• October 26 No meeting (AMM week)
• November 2  
  • Adam
  •  Oleksandr
  • Dmitry
  • Peter ...
• November 9   Adam   Oleksandr  Dmitry Peter ...
• November 16 Adam   Oleksandr  Dmitry Peter ...
• November 23 Adam   Oleksandr  Dmitry Peter ...

October 12

• Dmitry vacation,  Adam has a conflict this week only
•  Oleksandr
•  Stephen join if possible (ad-hoc)
•  Peter

October 5

Participants:
Adam Stephen Dmitry busy  Peter busy  Oleksandr busy Bernhard tried joining (missed by Gunnar)

...

August 31 - September 28

• Another 1-2 discussions on Graphics
• Continued discussion and work on the specification – results are in working document and in JIRA.

Participants:

• Primarily Adam, Dmitry, Oleksander and Kai.  Occasionally Bernhard. For graphics also Eugen.  Peter had vacation.

August 24

Participants:

• Peter (BMW)
• Daniel Stone (Collabora)
• Adam (Kernkonzept)
• Gunnar (GENIVI)
• Dmitry (OpenSynergy)

Apologies:

• Adam noted he has a conflicting meeting this week
• Oleksandr / EPAM colleagues – there is a public holiday

Minutes

• Producing the generic model of future GPUs.  Adam started writing inside the AVPS as a place to hold the information for now.
  Daniel can view and contribute.
• Gunnar: That's fine for now.  We should work on cleaning up the AVPS for release in the months to come.
• Bernhard:  Next generation is fairly fixed but a wish list is useful.
• Peter: It is very valuable to know how Arm engineers think about this.  We can discuss common parts of future designs 
  Gunnar: ... even if Silicon Vendors have their own unique details and/or use some other GPU cores.

Switching to discuss AVPS planning and open JIRA tickets.   

Gunnar: A least the "Evaluate Status" column is getting fairly empty.  This is good.  There are some big ones there still, e.g. DSP/TSP.

• We discussed DSPs primarily.   - see notes in JIRA ticket.  

  Jira
  server JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key HV-17

• Gunnar: There is a lot to sort out here
  • 1. Technical organization (like defining the potential software/hardware stack, similar to the GPU discussion) 
  • 2. ...and as far as the technology is still unclear - understand current project organization (how are projects solving this today, what conversations need to be had between product owner (e.g. OEM), Hypervisor implementor, and the silicon vendor?) 
    The idea like for any hardware chapter in AVPS, is at mininimum,  to try to have a few of those conversations proactively, so that there is a better basis to start from when going into a production project, and as far as possible, create some generic solutions/standards that remove obstacles.
  Adam noted he has a conflicting meeting this week

August 17

Apologies:

• Dmitry

...

• Lots of topics (5 presentations), lots of discussion
• Little time for Q&A on each - basically every topic needs deeper investigation and discussions
• See presentations

May 14 - cancelled due to AMM

...