<p>There seems to be some confusion of terminology here. In Direct3D, you have <em>threads</em> and <em>thread groups</em>. "work item" and "work group" are generally encountered in OpenCL terminology, where a "work item" would be what a <em>thread</em> is in Direct3D and a "work group" corresponds to a Direct3D <em>thread group</em>. <code>groupshared</code> memory is memory accessible to all threads that are part of the same thread group.</p>

<p>It is unclear what exactly you mean by "manipulating L1 cache directly". A cache is a hardware component that is used to transparently optimize memory access. The word "transparent" is crucial here. While, at the hardware level, caches necessarily contain some form of memory, they are generally not explicitly "accessible" as a region of storage. You can't have a pointer that points into a cache. You can have a pointer that points into memory. Memory accesses will typically go through a cache, i.e., any memory request will be handed off to the next cache, which can then check whether it can serve the request directly or has to go further down the memory hierarchy. There's more to a cache than just the memory it uses to cache stuff. A cache also contains additional logic for managing the cache on top of just the storage itself. Caches are implicit by nature. As you manipulate memory, you will typically also cause some caches to manipulate their memory along the way. But you generally can't "manipulate" a cache directly in the sense of explicitly defining what is when to be stored where in the cache. As soon as you can explicitly point into it and read/write from/to it, it kinda stops being a cache and starts being just some form of storage. </p>

<p>That being said, <code>groupshared</code> memory is generally located in fast on-chip storage just like caches are. The whole point of <code>groupshared</code> memory is to take advantage of the knowledge that certain threads reside on the same part of the chip to allow them to communicate faster. And on some hardware (e.g., most of the recent NVIDIA architectures), <code>groupshared</code> memory and the L1 cache will actually use the same physical memory. However, that just means that one part of that memory is used as "normal" memory, accessed directly via addressing through some load-store-unit, while another part is used by the L1 cache to cache stuff&hellip;</p>

CC BY-SA 4.0
2019-03-10T17:28:59.783Z
2019-03-11T00:37:35.983Z
2019-03-11T00:37:35.983Z
Michael Kenzel
<p>The <a href="https://anteru.net/blog/2018/intro-to-compute-shaders/index.html" rel="nofollow noreferrer">article</a> says that L1 cache is shared by work items in the same work group(aka. SM) and L2 cache is shared by different work groups.</p>

<p>In Direct3D, it seems that a thread group (which is specified by <code>numthread(x, y, z)</code>) is mapped to multi work groups, and <code>groupshared</code> could be accessed by all threads of the thread group (which belong to different work groups).</p>

<p>So, is <code>groupshared</code> the L2 cache of GPU? If it is, could I manipulate L1 cache directly in Direct3D?</p>

<directx11><gpgpu>
Is `groupshared` memory stored in L2 cache of GPU?
Cu2S
# Is `groupshared` memory stored in L2 cache of GPU?

(Asked by: username_0 on 2019-03-10)

The [article](https://anteru.net/blog/2018/intro-to-compute-shaders/index.html) says that L1 cache is shared by work items in the same work group(aka. SM) and L2 cache is shared by different work groups.

In Direct3D, it seems that a thread group (which is specified by `numthread(x, y, z)`) is mapped to multi work groups, and `groupshared` could be accessed by all threads of the thread group (which belong to different work groups).

So, is `groupshared` the L2 cache of GPU? If it is, could I manipulate L1 cache directly in Direct3D?

**Tags:** directx11, gpgpu


---

## 1 answers

### Answer by username_1 on 2019-03-10. Score: 5 | Accepted answer

There seems to be some confusion of terminology here. In Direct3D, you have *threads* and *thread groups*. "work item" and "work group" are generally encountered in OpenCL terminology, where a "work item" would be what a *thread* is in Direct3D and a "work group" corresponds to a Direct3D *thread group*. `groupshared` memory is memory accessible to all threads that are part of the same thread group.

It is unclear what exactly you mean by "manipulating L1 cache directly". A cache is a hardware component that is used to transparently optimize memory access. The word "transparent" is crucial here. While, at the hardware level, caches necessarily contain some form of memory, they are generally not explicitly "accessible" as a region of storage. You can't have a pointer that points into a cache. You can have a pointer that points into memory. Memory accesses will typically go through a cache, i.e., any memory request will be handed off to the next cache, which can then check whether it can serve the request directly or has to go further down the memory hierarchy. There's more to a cache than just the memory it uses to cache stuff. A cache also contains additional logic for managing the cache on top of just the storage itself. Caches are implicit by nature. As you manipulate memory, you will typically also cause some caches to manipulate their memory along the way. But you generally can't "manipulate" a cache directly in the sense of explicitly defining what is when to be stored where in the cache. As soon as you can explicitly point into it and read/write from/to it, it kinda stops being a cache and starts being just some form of storage.

That being said, `groupshared` memory is generally located in fast on-chip storage just like caches are. The whole point of `groupshared` memory is to take advantage of the knowledge that certain threads reside on the same part of the chip to allow them to communicate faster. And on some hardware (e.g., most of the recent NVIDIA architectures), `groupshared` memory and the L1 cache will actually use the same physical memory. However, that just means that one part of that memory is used as "normal" memory, accessed directly via addressing through some load-store-unit, while another part is used by the L1 cache to cache stuff…


---

