Skip to content

Commit 570587e

Browse files
committed
Update base for Update on "[ET-VK] Use shared pointer for vTensorStorage"
## Changes * In `vTensor`, store the `storage_` member using a shared pointer instead of a direct `vTensorStorage` object * Remove the ability to construct a tensor view with a buffer offset ## Motivation > * In `vTensor`, store the `storage_` member using a shared pointer instead of a direct `vTensorStorage` object Previously, to support the ability to create tensor views I implemented copy constructors for `VulkanImage`, `VulkanBuffer`, and `vTensorStorage`. The idea was that the copied object instance would have the same handles as the original, but would not own the handle (and therefore not be responsible for destroying it). However, the problem with this approach is that in order to construct pipeline barriers and image layout transitions properly, we must know the details of how a resource was last accessed. Since tensor views make copies, accessing the original tensor will not update the access information of any copies it may have. Therefore, if the copy is then accessed, the last access information it stores would then be out of date. I originally tried to solve this problem with crude assumptions in the `transition()` function, but unfortunately the solution was not robust enough. I discovered validation errors such as ``` [ RUN ] VulkanComputeGraphOpsTest.test_transpose_with_mm VUID-VkImageMemoryBarrier-oldLayout-01197(ERROR / SPEC): msgNum: 307231540 - Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01197 ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x124ffb34 | vkCmdPipelineBarrier(): pImageMemoryBarriers[2].image (VkImage 0x35643f0000000111[]) cannot transition the layout of aspect=1, level=0, layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_GENERAL. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197) Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x21eba07e160[] expects VkImage 0x35643f0000000111[] (subresource: aspectMask VK_IMAGE_ASPECT_COLOR_BIT array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL VUID-VkImageMemoryBarrier-oldLayout-01197(ERROR / SPEC): msgNum: 307231540 - Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01197 ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x124ffb34 | vkCmdPipelineBarrier(): pImageMemoryBarriers[2].image (VkImage 0x35643f0000000111[]) cannot transition the layout of aspect=1, level=0, layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_GENERAL. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197) Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x21eba07e160[] expects VkImage 0x35643f0000000111[] (subresource: aspectMask VK_IMAGE_ASPECT_COLOR_BIT array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL VUID-VkImageMemoryBarrier-oldLayout-01197(ERROR / SPEC): msgNum: 307231540 - Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01197 ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x124ffb34 | vkCmdPipelineBarrier(): pImageMemoryBarriers[2].image (VkImage 0x35643f0000000111[]) cannot transition the layout of aspect=1, level=0, layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_GENERAL. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197) Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x21eba07e160[] expects VkImage 0x35643f0000000111[] (subresource: aspectMask VK_IMAGE_ASPECT_COLOR_BIT array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL VUID-VkImageMemoryBarrier-oldLayout-01197(ERROR / SPEC): msgNum: 307231540 - Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01197 ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x124ffb34 | vkCmdPipelineBarrier(): pImageMemoryBarriers[2].image (VkImage 0x35643f0000000111[]) cannot transition the layout of aspect=1, level=0, layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_GENERAL. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197) Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x21eba07e160[] expects VkImage 0x35643f0000000111[] (subresource: aspectMask VK_IMAGE_ASPECT_COLOR_BIT array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL VUID-VkImageMemoryBarrier-oldLayout-01197(ERROR / SPEC): msgNum: 307231540 - Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01197 ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x124ffb34 | vkCmdPipelineBarrier(): pImageMemoryBarriers[2].image (VkImage 0x35643f0000000111[]) cannot transition the layout of aspect=1, level=0, layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_GENERAL. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197) Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout(ERROR / SPEC): msgNum: 1303270965 - Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x21eba07e160, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x35643f0000000111, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x21eba07e160[] expects VkImage 0x35643f0000000111[] (subresource: aspectMask VK_IMAGE_ASPECT_COLOR_BIT array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. Objects: 2 [0] 0x21eba07e160, type: 6, name: NULL [1] 0x35643f0000000111, type: 10, name: NULL [ OK ] VulkanComputeGraphOpsTest.test_transpose_with_mm (26 ms) ``` when using tensor views. The simplest solution is to use a shared pointer to store the tensor storage object, that way tensor views can point to the same underlying object instance, and last access metadata will be consistent among all tensor views. > * Remove the ability to construct a tensor view with a buffer offset Removed this because it turns out that buffer properties cannot have arbitrary offsets; there are restrictions for what offsets can be used. The validation errors say it all: ``` [ RUN ] VulkanComputeGraphTest.test_simple_graph_with_view VUID-VkWriteDescriptorSet-descriptorType-00328(ERROR / SPEC): msgNum: -368569266 - Validation Error: [ VUID-VkWriteDescriptorSet-descriptorType-00328 ] | MessageID = 0xea08144e | vkUpdateDescriptorSets(): pDescriptorWrites[1].pBufferInfo[0].offset (84) must be a multiple of device limit minStorageBufferOffsetAlignment 16 when descriptor type is VK_DESCRIPTOR_TYPE_STORAGE_BUFFER. The Vulkan spec states: If descriptorType is VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC, the offset member of each element of pBufferInfo must be a multiple of VkPhysicalDeviceLimits::minStorageBufferOffsetAlignment (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkWriteDescriptorSet-descriptorType-00328) VUID-VkDescriptorBufferInfo-range-00342(ERROR / SPEC): msgNum: -371195848 - Validation Error: [ VUID-VkDescriptorBufferInfo-range-00342 ] Object 0: handle = 0xee647e0000000009, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0xe9e00038 | vkUpdateDescriptorSets(): pDescriptorWrites[1].pBufferInfo[0].range (224) is larger than buffer size (224) + offset (84). The Vulkan spec states: If range is not equal to VK_WHOLE_SIZE, range must be less than or equal to the size of buffer minus offset (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkDescriptorBufferInfo-range-00342) Objects: 1 [0] 0xee647e0000000009, type: 9, name: NULL VUID-VkBufferMemoryBarrier-size-01189(ERROR / SPEC): msgNum: -1238074894 - Validation Error: [ VUID-VkBufferMemoryBarrier-size-01189 ] Object 0: handle = 0x25d7d900870, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0xb63479f2 | vkCmdPipelineBarrier(): pBufferMemoryBarriers[0].size VkBuffer 0xee647e0000000009[] has offset 0x54 and size 0xe0 whose sum is greater than total size 0xe0. The Vulkan spec states: If size is not equal to VK_WHOLE_SIZE, size must be less than or equal to than the size of buffer minus offset (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkBufferMemoryBarrier-size-01189) Objects: 1 [0] 0x25d7d900870, type: 6, name: NULL [ OK ] VulkanComputeGraphTest.test_simple_graph_with_view (8 ms) ``` ## Impact * Heap allocation upon tensor construction * Increased pointer chasing when accessing `vTensor` members I will validate that the impact of this change does not regress load/inference latency. Differential Revision: [D76047204](https://our.internmc.facebook.com/intern/diff/D76047204/) [ghstack-poisoned]
1 parent c5bea71 commit 570587e

File tree

31 files changed

+522
-696
lines changed

31 files changed

+522
-696
lines changed

.ci/scripts/build_llama_android.sh

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -42,7 +42,6 @@ build_llama_runner() {
4242
popd
4343
ANDROID_ABI=arm64-v8a
4444
cmake -DBUCK2="${BUCK2}" \
45-
-DBUILD_TESTING=OFF \
4645
-DCMAKE_TOOLCHAIN_FILE="$ANDROID_NDK"/build/cmake/android.toolchain.cmake \
4746
-DANDROID_ABI="${ANDROID_ABI}" \
4847
-DCMAKE_INSTALL_PREFIX=cmake-android-out \

.ci/scripts/test_llama.sh

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -169,7 +169,6 @@ cmake_build_llama_runner() {
169169
popd
170170
dir="examples/models/llama"
171171
retry cmake \
172-
-DBUILD_TESTING=OFF \
173172
-DCMAKE_INSTALL_PREFIX=cmake-out \
174173
-DCMAKE_BUILD_TYPE="$CMAKE_BUILD_TYPE" \
175174
-Bcmake-out/${dir} \

.ci/scripts/test_llama_torchao_lowbit.sh

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,6 @@ cmake --build cmake-out -j16 --target install --config Release
4040

4141
# Install llama runner with torchao
4242
cmake -DPYTHON_EXECUTABLE=python \
43-
-DBUILD_TESTING=OFF \
4443
-DCMAKE_BUILD_TYPE=Release \
4544
-DEXECUTORCH_BUILD_KERNELS_CUSTOM=ON \
4645
-DEXECUTORCH_BUILD_KERNELS_OPTIMIZED=ON \

.ci/scripts/test_llava.sh

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -64,10 +64,9 @@ cmake_install_executorch_libraries_for_android() {
6464

6565

6666
LLAVA_COMMON_CMAKE_ARGS=" \
67-
-DBUILD_TESTING=OFF \
6867
-DPYTHON_EXECUTABLE="$PYTHON_EXECUTABLE" \
6968
-DCMAKE_INSTALL_PREFIX=${BUILD_DIR} \
70-
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} \
69+
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} \
7170
-DEXECUTORCH_BUILD_KERNELS_CUSTOM=ON \
7271
-DEXECUTORCH_BUILD_KERNELS_OPTIMIZED=ON \
7372
-DEXECUTORCH_BUILD_XNNPACK=ON"

backends/vulkan/test/vulkan_compute_api_test.cpp

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3177,8 +3177,10 @@ void test_to_copy() {
31773177

31783178
EXPECT_EQ(data_in.size(), output_data.size());
31793179

3180+
#ifdef VULKAN_DEBUG
31803181
float mse_ex = 0.0f;
31813182
float mse_vk = 0.0f;
3183+
#endif
31823184

31833185
// check results
31843186
for (size_t i = 0; i < output_data.size(); ++i) {
@@ -3200,6 +3202,9 @@ void test_to_copy() {
32003202
std::bitset<16>(*output_bits).to_string() + ")";
32013203

32023204
std::cout << msg << std::endl;
3205+
3206+
mse_ex += std::pow(expected_output - input, 2);
3207+
mse_vk += std::pow(output - input, 2);
32033208
#endif
32043209

32053210
// Note: Torch executor half "rounds up" when converting to fp16 whereas
@@ -3221,13 +3226,12 @@ void test_to_copy() {
32213226
EXPECT_TRUE(
32223227
(*output_bits == *expected_bits) ||
32233228
/*rounding error*/ ((*output_bits + 1u) == *expected_bits));
3224-
mse_ex += std::pow(expected_output - input, 2);
3225-
mse_vk += std::pow(output - input, 2);
32263229
}
32273230

3231+
#ifdef VULKAN_DEBUG
32283232
mse_ex /= output_data.size();
32293233
mse_vk /= output_data.size();
3230-
#ifdef VULKAN_DEBUG
3234+
32313235
std::cout << "========================================================="
32323236
<< std::endl;
32333237
std::cout << "mse_ex = " << mse_ex << ", mse_vk = " << mse_vk << std::endl;

examples/demo-apps/apple_ios/LLaMA/LLaMARunner/LLaMARunner/Exported/LLaMARunner.mm

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,6 @@
1414

1515
using executorch::extension::llm::GenerationConfig;
1616
using executorch::extension::llm::Image;
17-
using executorch::extension::llm::TextLLMRunner;
1817
using executorch::runtime::Error;
1918

2019
NSErrorDomain const LLaMARunnerErrorDomain = @"LLaMARunnerErrorDomain";
@@ -24,15 +23,15 @@ @interface LLaMARunner ()<ExecuTorchLogSink>
2423
@end
2524

2625
@implementation LLaMARunner {
27-
std::unique_ptr<TextLLMRunner> _runner;
26+
std::unique_ptr<example::Runner> _runner;
2827
}
2928

3029
- (instancetype)initWithModelPath:(NSString*)modelPath
3130
tokenizerPath:(NSString*)tokenizerPath {
3231
self = [super init];
3332
if (self) {
3433
[ExecuTorchLog.sharedLog addSink:self];
35-
_runner = example::create_llama_runner(
34+
_runner = example::Runner::create(
3635
modelPath.UTF8String, tokenizerPath.UTF8String);
3736
}
3837
return self;

examples/models/llama/CMakeLists.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -220,6 +220,7 @@ endif()
220220
target_include_directories(
221221
llama_main
222222
PUBLIC ${_common_include_directories}
223+
${EXECUTORCH_ROOT}/extension/llm/tokenizers/include
223224
)
224225
target_link_libraries(llama_main PUBLIC llama_runner ${link_libraries})
225226
target_compile_options(llama_main PUBLIC ${_common_compile_options})

examples/models/llama/main.cpp

Lines changed: 2 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -81,13 +81,8 @@ int32_t main(int32_t argc, char** argv) {
8181
}
8282
#endif
8383
// create llama runner
84-
std::unique_ptr<::executorch::extension::llm::TextLLMRunner> runner =
85-
example::create_llama_runner(model_path, tokenizer_path, data_path);
86-
87-
if (runner == nullptr) {
88-
ET_LOG(Error, "Failed to create llama runner");
89-
return 1;
90-
}
84+
std::unique_ptr<example::Runner> runner =
85+
example::Runner::create(model_path, tokenizer_path, data_path);
9186

9287
if (warmup) {
9388
runner->warmup(prompt, /*max_new_tokens=*/seq_len);

examples/models/llama/runner/CMakeLists.txt

Lines changed: 12 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -52,20 +52,23 @@ else()
5252
add_library(llama_runner SHARED ${_llama_runner__srcs})
5353
endif()
5454

55-
# For extension_llm_runner
56-
if(NOT TARGET extension_llm_runner)
57-
add_subdirectory(
58-
${EXECUTORCH_ROOT}/extension/llm/runner
59-
${CMAKE_CURRENT_BINARY_DIR}/../../../../extension/llm/runner
60-
)
61-
endif()
62-
6355
set(llama_runner_deps executorch_core extension_data_loader extension_module
64-
extension_tensor extension_flat_tensor extension_llm_runner
56+
extension_tensor extension_flat_tensor
6557
)
6658

6759
target_link_libraries(llama_runner PUBLIC ${llama_runner_deps})
6860

61+
target_include_directories(
62+
llama_runner
63+
INTERFACE ${_common_include_directories}
64+
)
65+
66+
# Include tokenizers dependency
67+
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
68+
add_subdirectory(
69+
${EXECUTORCH_ROOT}/extension/llm/tokenizers
70+
${CMAKE_CURRENT_BINARY_DIR}/tokenizers
71+
)
6972
target_link_libraries(
7073
llama_runner PUBLIC tokenizers
7174
)

0 commit comments

Comments
 (0)