[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"doc-detail-85042-en":3,"doc-seo-85042-105":30,"detail-sidebar-cat-0-en-105":91},{"code":4,"msg":5,"data":6},0,"success",{"doc_id":7,"user_id":8,"nickname":9,"user_avatar":10,"doc_module":4,"category_id":11,"category_name":12,"doc_title":13,"doc_description":14,"doc_content":15,"file_id":16,"file_url":17,"file_type":18,"file_size":19,"view_count":20,"is_deleted":4,"is_public":21,"is_downloadable":21,"audit_status":21,"page_count":22,"language":23,"language_code":24,"site_id":25,"html_lang":24,"table_of_contents":26,"faqs":27,"seo_title":13,"seo_description":14,"update_tm":28,"read_time":29},85042,1374391975076,"Riley","https://ap-avatar.wpscdn.com/avatar/14000253ca4ec9f6853?x-image-process=image/resize,m_fixed,w_180,h_180&k=1783305029341752051",8,"Research & Report","Toward a Unified GPU-Aware OpenSHMEM Specification","Leadership-class HPC systems are increasingly accelerator-centric, with GPUs delivering most computation and memory bandwidth. As accelerators become integrated through high-speed fabrics and interconnects, PGAS models like OpenSHMEM help express fine-grained remote memory operations across tightly coupled device domains. OpenSHMEM 1.x is lean for irregular communication, atomics, synchronization, and collectives, but its memory model lacks accelerator-portable semantics, fragmenting implementations and coherence across vendors. This work proposes a backward-compatible OpenSHMEM Auxiliary Specification adding GPU-scoped memory semantics, capability queries, and defined remote access, atomic, synchronization, and collective behavior for GPU-attached buffers.","Toward a Unified GPU-Aware OpenSHMEM Specification  \nNaveen Ravi  \nNathan Wichmann  \nMd. Wasi-ur-Rahman  \n[nravi@hpe.com](nravi@hpe.com)[ ](nravi@hpe.com)[wichmann@hpe.com](wichmann@hpe.com)[ ](wichmann@hpe.com)[md.rahman@hpe.com](md.rahman@hpe.com)[ ](md.rahman@hpe.com)Hewlett Packard Enterprise (HPE) Bloomington, Minnesota, USA  \nAurelien Bouteiller  \nYıltan Hassan Temuçin  \nAvinash Kethineedi Johnathan Alsop Brandon Potter  \n[Aurelien.Bouteiller@amd.com](Aurelien.Bouteiller@amd.com)[yiltan@amd.com](yiltan@amd.com)[avinash.kethineedi@amd.com](avinash.kethineedi@amd.com)[ ](avinash.kethineedi@amd.com)[Johnathan.Alsop@amd.com](Johnathan.Alsop@amd.com)[ ](Johnathan.Alsop@amd.com)[Brandon.Potter@amd.com](Brandon.Potter@amd.com)[ ](Brandon.Potter@amd.com)[Advanced Micro Devices](Advanced Micro Devices), [Inc](Inc). Austin, Texas, USA  \nShubhendra Pal Singhal Jun Shirako Akihiro Hayashi Vivek Sarkar  \n[ssinghal74@gatech.edu](ssinghal74@gatech.edu)[ ](ssinghal74@gatech.edu)[shirako@gatech.edu](shirako@gatech.edu)[ ](shirako@gatech.edu)[ahayashi@gatech.edu](ahayashi@gatech.edu)[vsarkar@gatech.edu](vsarkar@gatech.edu)[ ](vsarkar@gatech.edu)Georgia Institute of Technology Atlanta, Georgia, USA  \narXiv :2607 .08006v 1 [ cs .DC] 9 Jul 2026  \nLawrence C. Stewart  \n[stewart@serissa.com](stewart@serissa.com)[ ](stewart@serissa.com)Serissa Research Wayland, Massachusetts, USA  \nMichael Beebe  \n[michael.beebe@ttu.edu](michael.beebe@ttu.edu)[ ](michael.beebe@ttu.edu)Texas Tech University Lubbock, Texas, USA  \nBenjamin Michalowicz  \n[michalowicz.2@osu.edu](michalowicz.2@osu.edu)[ ](michalowicz.2@osu.edu)The Ohio State University Columbus, Ohio, USA  \nJeongnim Kim Thiago Teixeria Mark F. Brown  \n[jeongnim.kim@intel.com](jeongnim.kim@intel.com)[ ](jeongnim.kim@intel.com)[thiago.teixeira@intel.com](thiago.teixeira@intel.com)[ ](thiago.teixeira@intel.com)[mark.f.brown@intel.com](mark.f.brown@intel.com)[ ](mark.f.brown@intel.com)Intel Corporation Hillsboro, Oregon, USA  \nAaron Welch Oscar Hernandez  \n[welchda@ornl.gov](welchda@ornl.gov)[ ](welchda@ornl.gov)[oscar@ornl.gov](oscar@ornl.gov)[ ](oscar@ornl.gov)Oak Ridge National Laboratory Oak Ridge, Tennessee, USA  \nWendy Poole Steve Poole  \n[wkpoole@lanl.gov](wkpoole@lanl.gov)[ ](wkpoole@lanl.gov)[swpoole@lanl.gov](swpoole@lanl.gov)[ ](swpoole@lanl.gov)Los Alamos National Laboratory Los Alamos, New Mexico, USA  \nAbstract  \nLeadership-class HPC systems are now accelerator-centric, with GPUs providing most floating-point throughput and memory bandwidth. As next-generation systems increasingly integrate accelerators through high-speed memory fabrics and system interconnects, exposing larger tightly coupled device domains, partitioned global address space (PGAS) models such as OpenSHMEM provide a natural abstraction for expressing fine-grained remote memory operations across these devices. While OpenSHMEM 1.x offers a lean PGAS model for irregular communication, atomics, finegrained synchronization, and collectives, its memory model lacks portable semantics for accelerator architectures. As a result, existing GPU-enabled OpenSHMEM implementations differ in memory  \nPermission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission [and/or a fee. Request permissions from permissions@acm.org](and/or a fee. Request permissions from permissions@acm.org).  \nCUG’26, Nice, France  \n© 2026 Copyright held by the owner/author(s) . Publication rights licensed to ACM. ACM ISBN 978-x-xxxx-xxxx-x/YYYY/MM  \n[https://doi.org/10.1145/nnnnnnn.nnnnnnn](https://doi.org/10.1","cbCaijtF6hemGyVH","https://ap.wps.com/l/cbCaijtF6hemGyVH","pdf",510289,2,1,15,"English","en",105,"# Abstract\n## Motivation for GPU-aware PGAS\n## Proposed OpenSHMEM Auxiliary Specification\n## GPU-scoped memory semantics and operation rules\n## Goals: portability and unification","[{\"question\":\"Why does OpenSHMEM 1.x need an auxiliary specification for GPU-aware behavior?\",\"answer\":\"Its memory model lacks portable semantics for accelerator architectures, so GPU-enabled implementations diverge in management, capability discovery, and operation semantics, reducing portability and community unification.\"},{\"question\":\"What does the proposed OpenSHMEM Auxiliary Specification add?\",\"answer\":\"A lightweight, backward-compatible extension that introduces a minimal memory model via a GPU-scoped memory space abstraction, plus capability queries and well-defined semantics for using GPU-attached buffers in remote access, atomic, synchronization, and collective operations.\"},{\"question\":\"How is the specification intended to be supported across devices and vendors?\",\"answer\":\"It is initially conceived through a host-initiated interface, while providing general semantics that can also enable optional device-initiated support, aiming to specify and implement unified GPU-aware semantics across GPUs from multiple vendors.\"}]",1784200566,38,{"code":4,"msg":31,"data":32},"ok",{"site_id":25,"language":24,"slug":33,"title":13,"keywords":34,"description":14,"schema_data":35,"social_meta":86,"head_meta":88,"extra_data":90,"updated_unix":28},"toward-a-unified-gpu-aware-openshmem-specification","",{"@graph":36,"@context":85},[37,53,68],{"@type":38,"itemListElement":39},"BreadcrumbList",[40,44,47,50],{"item":41,"name":42,"@type":43,"position":21},"https://docshare.wps.com","Home","ListItem",{"item":45,"name":46,"@type":43,"position":20},"https://docshare.wps.com/document/","Document",{"item":48,"name":12,"@type":43,"position":49},"https://docshare.wps.com/document/research-report/",3,{"item":51,"name":13,"@type":43,"position":52},"https://docshare.wps.com/document/toward-a-unified-gpu-aware-openshmem-specification/85042/",4,{"url":51,"name":13,"@type":54,"author":55,"headline":13,"publisher":57,"fileFormat":60,"inLanguage":24,"description":14,"dateModified":61,"datePublished":62,"encodingFormat":60,"isAccessibleForFree":63,"interactionStatistic":64},"DigitalDocument",{"name":9,"@type":56},"Person",{"url":41,"name":58,"@type":59},"DocShare","Organization","application/pdf","2026-07-23","2026-07-16",true,{"@type":65,"interactionType":66,"userInteractionCount":20},"InteractionCounter",{"@type":67},"ViewAction",{"@type":69,"mainEntity":70},"FAQPage",[71,77,81],{"name":72,"@type":73,"acceptedAnswer":74},"Why does OpenSHMEM 1.x need an auxiliary specification for GPU-aware behavior?","Question",{"text":75,"@type":76},"Its memory model lacks portable semantics for accelerator architectures, so GPU-enabled implementations diverge in management, capability discovery, and operation semantics, reducing portability and community unification.","Answer",{"name":78,"@type":73,"acceptedAnswer":79},"What does the proposed OpenSHMEM Auxiliary Specification add?",{"text":80,"@type":76},"A lightweight, backward-compatible extension that introduces a minimal memory model via a GPU-scoped memory space abstraction, plus capability queries and well-defined semantics for using GPU-attached buffers in remote access, atomic, synchronization, and collective operations.",{"name":82,"@type":73,"acceptedAnswer":83},"How is the specification intended to be supported across devices and vendors?",{"text":84,"@type":76},"It is initially conceived through a host-initiated interface, while providing general semantics that can also enable optional device-initiated support, aiming to specify and implement unified GPU-aware semantics across GPUs from multiple vendors.","https://schema.org",{"og:url":51,"og:type":87,"og:title":13,"og:site_name":58,"og:description":14},"article",{"robots":89,"canonical":51},"index,follow",{"doc_id":7,"site_id":25},{"code":4,"msg":5,"data":92},[93,97,101,105,110,115,120,123,128,131,135],{"id":21,"doc_module":4,"doc_module_name":46,"category_name":94,"show_sort_weight":95,"slug":96},"Story & Novel",90,"story-novel",{"id":20,"doc_module":4,"doc_module_name":46,"category_name":98,"show_sort_weight":99,"slug":100},"Literature",80,"literature",{"id":52,"doc_module":4,"doc_module_name":46,"category_name":102,"show_sort_weight":103,"slug":104},"Exam",70,"exam",{"id":106,"doc_module":4,"doc_module_name":46,"category_name":107,"show_sort_weight":108,"slug":109},5,"Comic",60,"comic",{"id":111,"doc_module":4,"doc_module_name":46,"category_name":112,"show_sort_weight":113,"slug":114},6,"Technology",50,"technology",{"id":116,"doc_module":4,"doc_module_name":46,"category_name":117,"show_sort_weight":118,"slug":119},7,"Healthcare",40,"healthcare",{"id":11,"doc_module":4,"doc_module_name":46,"category_name":12,"show_sort_weight":121,"slug":122},30,"research-report",{"id":124,"doc_module":4,"doc_module_name":46,"category_name":125,"show_sort_weight":126,"slug":127},9,"Religion & Spirituality",20,"religion-spirituality",{"id":126,"doc_module":4,"doc_module_name":46,"category_name":129,"show_sort_weight":126,"slug":130},"World Cup","world-cup",{"id":132,"doc_module":4,"doc_module_name":46,"category_name":133,"show_sort_weight":132,"slug":134},10,"Lifestyle","lifestyle",{"id":136,"doc_module":4,"doc_module_name":46,"category_name":137,"show_sort_weight":106,"slug":138},19,"General","general"]