Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • mesa mesa
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2,689
    • Issues 2,689
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 903
    • Merge requests 903
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Mesa
  • mesamesa
  • Merge requests
  • !6332

nir,spirv: Add generic pointers support

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Jason Ekstrand requested to merge jekstrand/mesa:review/cl-generic-pointers into master Aug 15, 2020
  • Overview 148
  • Commits 27
  • Pipelines 77
  • Changes 66

This MR adds everything to NIR that I think should be required for semi-competent generic pointer support. It's really quite straightforward. The patches support two possible models:

  1. Unified address space model: In this model, everything is mapped into the global address space. Scratch and shared memory pointers will be computed as an offset from the scratch/shared_base_ptr system value. In this model, it's the driver's job to implement the deref_is_* intrinsics for detecting which type of pointer something is. In theory, if we had the range of the shared and scratch address space in nir_lower_io, we could possibly lower them in NIR using a range check based on ptr - scratch/shared_base_ptr. However, it's possible that, given carefully chosen address spaces, it may be possible for the back-end driver to do better.

  2. Enum+address model: In this model, a few bits of the pointer are reserved for some sort of enum and the semantics of this are baked into the nir_address_format. In this model, nir_lower_io will emit if-ladders for accesses whenever deref->modes has more than one mode. The last patch in this series adds such an address mode which is what we would need on Intel. It reserves the top two bits of the 64-bit pointer for the enum value.

The biggest sticky bit of this MR is in the early patches when we rename nir_deref_instr::mode to "modes" and make it a bitfield. It touches lots of passes and replaces lots of == or != checks with bit-banging. There are lots of subtleties in there. I think I got it right but extra eyes would be very good.

Note: This has gotten very little to no testing. I think I've done all the typing but I'm very sure lots of stuff will start blowing up when we run this in the wild.

cc: @karolherbst @jenatali

Edited Oct 29, 2020 by Jason Ekstrand
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: review/cl-generic-pointers