GPU texture system prototype by aconty · Pull Request #5228 · AcademySoftwareFoundation/OpenImageIO

aconty · 2026-06-09T15:58:04Z

Description

Implemented as a standalone testsuite prototype, without modifying the core OpenImageIO library, this work demonstrates the proposed data model and runtime design in a working executable that already produces images.

The prototype validates the host/device architecture end to end: request-driven texture lookup, residency updates, retry flow, filtering behavior, and output generation. It is intentionally scoped to the testsuite so we can iterate quickly on API shape, data structures, and execution strategy before promoting pieces into library code.

More details in README.md, started from SPEC.md. Designed and written by me, assisted by gpt-5.3-codex in copilot.

Nobody wanted to jump into this task, including myself. So I wrote a prototype SPEC for AI to do it. Since I didn't like where it was going I took full control. of it and ended up enjoying the job a lot. Came up with a couple of patterns that I like a lot. My aim was simplicity and clarity. Hope you people like it.

Tests

The prototype itself is a test. This doesn't interfere with the rest of the library.

Checklist:

I have read the guidelines on contributions and code review procedures.
I have read the Policy on AI Coding Assistants
and if I used AI coding assistants, I have an Assisted-by: TOOL / MODEL
line in the pull request description above.
I have updated the documentation if my PR adds features or changes
behavior.
I am sure that this PR's changes are tested in the testsuite.
I have run and passed the testsuite in CI before submitting the
PR, by pushing the changes to my fork and seeing that the automated CI
passed there. (Exceptions: If most tests pass and you can't figure out why
the remaining ones fail, it's ok to submit the PR and ask for help. Or if
any failures seem entirely unrelated to your change; sometimes things break
on the GitHub runners.)
My code follows the prevailing code style of this project and I
fixed any problems reported by the clang-format CI test.
If I added or modified a public C++ API call, I have also amended the
corresponding Python bindings. If altering ImageBufAlgo functions, I also
exposed the new functionality as oiiotool options.

linux-foundation-easycla · 2026-06-09T15:58:11Z

The committers listed above are authorized under a signed CLA.

✅ login: aconty / name: Alejandro Conty (d2e27d0)

aconty · 2026-06-09T16:30:18Z

Here is the README, btw https://github.com/imageworks/OpenImageIO/blob/gputex/testsuite/texture-device/README.md

Implemented as a standalone testsuite prototype, without modifying the core OpenImageIO library, this work demonstrates the proposed data model and runtime design in a working executable that already produces images. The prototype validates the host/device architecture end to end: request-driven texture lookup, residency updates, retry flow, filtering behavior, and output generation. It is intentionally scoped to the testsuite so we can iterate quickly on API shape, data structures, and execution strategy before promoting pieces into library code. More details in README.md, started from SPEC.md. Designed and written by me, assisted by gpt-5.3-codex in copilot. Signed-off-by: Alejandro Conty <aconty@imageworks.com>

lgritz

I see where you're going with this, and LGTM. The threshold is pretty low since this is just a testsuite experiment for now, so by no means does anything need to be perfect or final.

I made a number of comments, but really it's nothing that we can't fix up as we continue to work on it, if you are inclined to address any of it in subsequent PRs rather than now.

I would like to discuss it at the TSC meeting today before we merge it, to make sure nobody has any reservations.

One overarching comment/question -- would it be a big simplification to the scheme (and would it be feasible and performant on today's HW) to use unified/managed memory rather than separate allocations and explicit copies?

lgritz · 2026-06-15T18:27:25Z

+inline uint64_t
+ptrtag(const char* s)
+{
+    if (!s || !s[0])
+        return 0;
+    return OIIO::Strutil::strhash64(std::strlen(s), s);
+}
+
+template<size_t N>
+inline constexpr uint64_t
+ptrtag(const char (&s)[N])
+{
+    static_assert(N > 1, "tag literal must be non-empty");
+    return OIIO::Strutil::strhash64(N - 1, s);
+}


Does the string_view overload of Strutil::strhash64 subsume both of these?

lgritz · 2026-06-15T18:36:59Z

+template<class T, size_t N> struct vector_lite : public std::array<T, N> {
+    using Base = std::array<T, N>;


C++26 includes a new inplace_vector<> that I think is the same as this. If so, we should adopt their nomenclature and as much of the semantics as makes sense.

I'm a little suspicious of it being is-a std::array versus has-a. Is it just to save a few lines by not having to repeat operator[] and the like? Are we inadvertently inheriting anything from std::array that we wouldn't want here?

Will do that change.

lgritz · 2026-06-15T18:37:47Z

+
+    void push_back(const T& value)
+    {
+        assert(m_size < N);


I would prefer OIIO_CONTRACT_ASSERT these days.

lgritz · 2026-06-15T18:39:17Z

+    std::vector<std::string> m_texture_paths;
+    std::unordered_map<std::string, TextureMetadata> m_metadata_cache;


Would these be better as ustring? (asking; I do not yet have a strong opinion)

lgritz · 2026-06-15T18:41:25Z

+        return loader_error("unsupported tile size for " + filename + " got "
+                            + std::to_string(spec.tile_width) + "x"
+                            + std::to_string(spec.tile_height) + " expected "
+                            + std::to_string(TileRecord::kTileWidth) + "x"
+                            + std::to_string(TileRecord::kTileHeight));


Strutil::format is probably more idiomatic for OIIO than string::operator+ (and almost certainly much faster). If we want to be really fancy, we can make loader_error itself format input instead of passing an already formatted string.

lgritz · 2026-06-15T18:53:13Z

Needless to say, there are a whole bunch of things here that are idiomatically different from TextureSystem (in implementation as well as in use). I'm noting that here only to say that as we eventually make this all part of TS, we'll probably want to revisit which should become more like the other, or if TS should support multiple usage idioms.

For example, should TS, even on the CPU, have a set of texture lookup calls that have a "texture not resident" result rather than being obligated to load it within the texture lookup? And a "here are a set of tiles we need, go get them all as efficiently as possible" function. It would be interesting to know how that approach to texture compares to what we're doing now, maybe we'd find it to be the method of choice no matter which HW you're running on.

aconty · 2026-06-17T12:25:48Z

Your unified memory support comment got me thinking. I'm going to spin this a bit more because I think I can do that and also simplify.

The API design, yes, probably better to discuss that live.

aconty force-pushed the gputex branch 2 times, most recently from d2e27d0 to a4b4e67 Compare June 9, 2026 16:25

aconty mentioned this pull request Jun 9, 2026

feat: CUDA/OptiX implementation of TextureSystem #4938

Open

aconty force-pushed the gputex branch 2 times, most recently from 0d84c77 to 00ba9bb Compare June 14, 2026 17:58

aconty force-pushed the gputex branch from 00ba9bb to edb923e Compare June 15, 2026 13:18

lgritz approved these changes Jun 15, 2026

View reviewed changes

		template<class T, size_t N> struct vector_lite : public std::array<T, N> {
		using Base = std::array<T, N>;

		std::vector<std::string> m_texture_paths;
		std::unordered_map<std::string, TextureMetadata> m_metadata_cache;

Conversation

aconty commented Jun 9, 2026

Description

Tests

Checklist:

Uh oh!

linux-foundation-easycla Bot commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aconty commented Jun 9, 2026

Uh oh!

lgritz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lgritz commented Jun 15, 2026

Uh oh!

aconty commented Jun 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

linux-foundation-easycla Bot commented Jun 9, 2026 •

edited

Loading