Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out the best format to represent strings for names of uniform parameters, blocks, and attributes. #24

Closed
kvark opened this issue Jun 28, 2014 · 2 comments

Comments

@kvark
Copy link
Member

kvark commented Jun 28, 2014

Here are the instances of names that we need to store:

  • Uniform parameter
  • Uniform block
  • Texture name
  • Shader attribute
  • Mesh attribute

These may need to be accessed at run-time for draw-call execution. Using String type will force the heap allocation (prevents static initialization of, to say, mesh::Attribute) and involve a guaranteed data cache miss on access due to indirection.

One of the possible solutions is to have fixed-size u8 arrays:

pub static MAX_UNIFORM_NAME: uint = 24;
pub type UniformName = [u8, ..MAX_UNIFORM_NAME];
@kvark kvark added the question label Jun 28, 2014
@kvark kvark changed the title Use fixed-size ASCII strings for names of uniform parameters, blocks, and attributes. Figure out the best format to represent strings for names of uniform parameters, blocks, and attributes. Jun 29, 2014
@kvark
Copy link
Member Author

kvark commented Jun 29, 2014

From @csherratt:

bjz, I think your symbol table is actually a great idea.
If every string in the pipeline that is the same always points to the same memory address, we can avoid the cache miss in the case for a string compare. Pointer A == Pointer B, no point in comparing their content.

@kvark
Copy link
Member Author

kvark commented Jul 1, 2014

This is superseded by the current architecture and future implementation of #46. Strings are still stored on the heap, but will be accessed only for new draw calls, and the shortcuts are going to be cached for faster binding.

@kvark kvark closed this as completed Jul 1, 2014
kvark pushed a commit to kvark/gfx that referenced this issue Jun 14, 2015
Fix compilation with fresh build of rustc.
kvark added a commit to kvark/gfx that referenced this issue Jun 14, 2015
adamnemecek pushed a commit to adamnemecek/gfx that referenced this issue Apr 1, 2021
24: Actually begin render passes r=grovesNL a=kvark

For now, we create the render pass and the frame buffer in place. Of course, we'd need to cache it properly, but this is blocked on W3C discussions on the API side.

With this PR, the Rust example is able to create a texture and run a render pass on it, all without a single Vulkan validation error 🎉 

Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant