Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Chameleon Chameleon
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 15
    • Issues 15
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 10
    • Merge requests 10
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar

Si vous êtes un personnel Inria et que vous souhaitez participer aux tests de notre future plateforme Gitlab basée sur la version ultimate avec gitlab LFS activé merci de contacter Didier Chassignol.

  • solverstack
  • ChameleonChameleon
  • Merge requests
  • !108

Add OpenMP runtime for codelets

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Philippe Virouleau requested to merge viroulea/chameleon:feature-openmp into master Aug 10, 2018
  • Overview 18
  • Commits 15
  • Changes 83

This is a placeholder for my ongoing work attempting to bring OpenMP as a backend runtime for Chameleon.

The current implementation for codelets uses dependent task, the plan is also to add some target version and see how it behaves wrt existing runtimes.

I've "openmp-ified" all codelets, though they have definitely not been extensively tested (or tested at all, for some).

OpenMP doesn't have a "runtime init" or "runtime finalize" as the other runtimes, so we need to put a #pragma omp parallel/#pragma omp master somewhere to create a team of threads that will execute our tasks. The semantic around the parallel region has some constraints (such as no return or jump outside the region from within the region), and I didn't find a great place so far for them yet, so currently it lies directly in the timing files (see timing/time_zpotrf_tile.c for an example).

I'll focus on doing the first experiments on a small subsets of kernels, meanwhile feel free to give me feedback on this!

Edited Oct 11, 2018 by Philippe Virouleau
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: feature-openmp