# More proprietary runtime for Adreno GPU

**URL:** <https://discuss.tvm.apache.org/t/more-proprietary-runtime-for-adreno-gpu/14368>\
**Category:** Uncategorized\
**Created:** [February 17, 2023, 11:19am UTC](https://discuss.tvm.apache.org/t/more-proprietary-runtime-for-adreno-gpu/14368 "2023-02-17T11:19:32Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![srkreddy1238](https://discuss.tvm.apache.org/user_avatar/discuss.tvm.apache.org/srkreddy1238/32/3518_2.png) [@srkreddy1238](https://discuss.tvm.apache.org/u/srkreddy1238)\
**Post date:** [February 17, 2023, 11:19am UTC](https://discuss.tvm.apache.org/t/more-proprietary-runtime-for-adreno-gpu/14368/1 "2023-02-17T11:19:32Z")

</div>

@echuraev @elvin-n

In the context of adding new features for Adreno (OpenCL runtime) like

- clImage1D instead instead of clBuffers as default allocation (global scope) as Adreno can benefit through texture path.
- Recordable queue support
- More tight integration between CLML and OpenCL while context switch (Reuse CLML/TVM allocated cl mem objects across with out additional copies)

Features like these need changes across Codegen and also the runtime.

Codegen part is a bit easy as defining a virtual target “adreno” as shown below and extending `CodeGenOpenCL` as `CodeGenAdrenoCL` to generate sampler based load/store for 1D buffers can achieve this. Here we reuse most of the OpenCL codegen here.

```auto
TVM_REGISTER_TARGET_KIND("adreno", kDLOpenCL)
    . . . . .
    .set_default_keys({"opencl", "gpu"});

```

On the runtime we don’t have information to differentiate regular opencl vs adreno based memory allocation strategy and management.

I see two options here

- We can define `kDLAdreno` as native target
- Alter graph runtime to supply the device specific options via the graph json attributes.

Any thoughts ?

Thanks, Siva

---

<div class="post-metadata">

**Author:** ![elvin-n](https://discuss.tvm.apache.org/user_avatar/discuss.tvm.apache.org/elvin-n/32/2682_2.png) [@elvin-n](https://discuss.tvm.apache.org/u/elvin-n)\
**Post date:** [February 17, 2023, 12:09pm UTC](https://discuss.tvm.apache.org/t/more-proprietary-runtime-for-adreno-gpu/14368/2 "2023-02-17T12:09:29Z")

</div>

I would like to avoid introduction of `kDLAdreno` so far. The examples that you showed can be covered without introduction of compilation flag

1. climage1d - it is just another memory scope which will be marked in the network, handled in tvm opencl runtime universally, does not belong to Adreno
2. Recordable queue support - we can verify in tvm opencl runtime part existence of certain opencl extension and go by certain flow with reusing/extending/copying of [cuda streaming capture graph executor](https://github.com/apache/tvm/blob/main/src/runtime/graph_executor/cuda_graph/graph_runtime_cuda_graph.cc). We are prototyping this feature
3. Need more context what happen here and why we need to have interaction between compilation and runtime that would not fit into standard opencl flow

---

<div class="post-metadata">

**Author:** ![srkreddy1238](https://discuss.tvm.apache.org/user_avatar/discuss.tvm.apache.org/srkreddy1238/32/3518_2.png) [@srkreddy1238](https://discuss.tvm.apache.org/u/srkreddy1238)\
**Post date:** [February 17, 2023, 12:56pm UTC](https://discuss.tvm.apache.org/t/more-proprietary-runtime-for-adreno-gpu/14368/3 "2023-02-17T12:56:12Z")

</div>

Avoiding new target compilation flag make sense.

1D enablement is not proprietary to Adreno, but not every body want this by default. I think we can define and use target attributes (`use_textures`) to enable/disable at compilation. Runtime can inspect the device as Adreno and enable them.

Good to hear prototyping of recordable queue. Looking forward to see the PR.