Attendees

Agenda

  • Action items from last meeting.
  • Retrospectives.

    Blueprint

    Assignee

    glcompbench

    alf

    glmark2

    marcoil

    linaro-mm-sig

    JesseBarker

    GLEW

    shariqHa

Action Items

  • [ACTION] Shariq to send an update to Jesse related to his planned work for 1109 for Memory Management. GLEW - will push to upstream asap.
  • [ACTION] ALL - provide headlines and acceptance criteria for the 1109 blueprints.
  • [ACTION] ALL - revise the names of the blueprints for 1109 to be something better than "Component xyz, ongoing work for 1109".
  • [ACTION] Ilias - to send an example of a "good" headline/acceptance with a given blueprint. - DONE

Action Items from Previous Meeting

  • To be added.

Minutes

  • Short status update:
    • Travis: after the Unity sync up has been preparing with the DX team so that we get the unity-gles into Oneiric. NUX completed, compiz almost done. Unity also expected to be completed by 08Sept2011. No issues
    • Alexandros: just back from vac. Managed to work on his branches and started working on the plans for 1109. Alexandros plans to attend the Android IRC meeting to get feedback and make sure glmark2 for Android gets integrated
    • Shariq: still discussing with Chunsang and Marek on the UMM tasks. [ACTION] Shariq to send an update to Jesse related to his planned work for 1109 for Memory Management. GLEW - will push to upstream asap.
    • Marc: working to add glproxy support to glcompbench. Different backends are working now using glproxy. The main problem - glproxy virtualizes GLX but not EGL. Will need some help to package glproxy for the 1109 build - Alexandros will help.
    • Chunsang: apart from the discussion with Shariq and Marek to confirm how to contribute with UMM (DMA-mapping). Also tried the patch by Marek - had a lot of conflicts. Performance events for GPU: tries to implement more complex 3d demos for the Origen board, to check whether there is performance dropping when using state tracking on the Mali driver. Needs to implement glmark2 for Origen - Alexandros helping now
  • Retrospective for 1108
    • Perhaps we should have an extra "freeze" before the RC freeze, in order to avoid waiting till the last day for any testing. On a rough estimate there is at least 1 week of development, 1 week for testing and depending the complexity of the merging of the project code to upstream/downstream up to 1 week for rebasing. So doing a soft freeze of the code up to 1 week before the RC is generated would help to run some extra testing
    • Related to Headlines and Acceptance - need to strike a balance between giving a lot of technical detail and being extremely concise. A headline should be good to just copy paste into the "release highlights" we send out with release announcement and acceptance should describe how the deliverable can be tested/validated to be delivered. The headline and acceptance lines should be available during the beginning of the monthly cycle to give a chance for review as well as to check if there are any missing parts (eg especially from testing)
      • The idea would be trying to explain the work to someone not knowledgeable in the area
    • There are blueprints where the work items are really concise combining a lot of work in 1 sentence. Work items could be more descriptive - split to identify some detail of the work involved.
  • Updates in Launchpad - projects have a backlog milestone. From now on we should try to write blueprints which are roughly 1 month of work effort. Blueprints not targeted yet to a specific monthly milestone can be put under the backlog milestone of the corresponding project. Then right after the monthly milestone of a running month is completed each engineer should look into the backlog of the project(s) in their area and replan blueprints to be delivered on the next monthly milestone - mainly the choice will be based on the priority base (take the next blueprint with the highest priority and aim it at the next monthly milestone).
    • Question: Can we have multiple blueprints for 1 month for the same project? Yes, this would help also with avoiding having generic names. The only constraint given is that a blueprint should be up to roughly 1 month of work. There is a choice however for the engineer - you can choose to handle up to 1 month of work effort through at least 1 or more (if preferred) blueprints.
    • Using better names for the blueprints will help anyone understand what is the work involved, in a summary, when looking into a milestone page (monthly or backlog).
  • Reminder: quarterly evaluations - book a time with Jesse.

Team Work - Summary

Current Weekly Report

Complete History

Team Work - Detailed

Alexandros Frantzis (alf)

  • On vacation.
  • Caught up with email.
  • Reviewed and merged various pending glmark2 branches.
  • Started working on new glmark2 benchmark (desktop like effects).
  • In contact with Android team about glmark2 android status.

Chunsang Jeong (chunsang)

  • DMA-mapping API
    • Reviewing new patch sets from Marek.
    • Trying to merge Marek's patch (dma-mapping-v3) to git.linaro.org;
      • Had a lot of conflicts not related to dma-mapping now.
  • Perf events for GPU
    • Implementing complex 3D demo i.e. glmark2 to Origen board to compare performance with/without STATE_TRACKING.
    • Trying to resolve configuration errors; Mali doesn't have pkg-config and uses specified x11, based on UMP.

Shariq Hasnain (shariqHa)

Travis Watkins (Amaranth)

  • Monday: Labor Day holiday
  • Updated nux merge request based on changes requested during sync up call
  • Preparing compiz patch for use in oneiric package

Sumit Semwal (sumits)

Marc Ordinas i Llopis (marcoil)

  • On vacation.
  • Looked at different EGL/OpenGL ES2 support/emulation libraries for desktop.
  • Added glproxy support to glcompbench-egl-es2.

WorkingGroups/Middleware/Graphics/Notes/2011-09-07 (last modified 2011-09-12 20:43:26)