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

cube: (Linux) Install image file and change cube(pp) to look for it in system dirs #5

Closed
karl-lunarg opened this issue May 14, 2018 · 4 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@karl-lunarg
Copy link
Contributor

The cube and cubepp demos have the restriction of expecting to find the texture image file (lunarg.ppm) in the same directory as the executable. This restriction makes it infeasible to "install" to a system directory because the image file would have to go into a directory meant for executables and not data.

Choose a suitable system location that is consistent with the FHS or equivalent standard.
Something like /usr/share/vulkan/lunarg/cube/lunarg.ppm as long as it follows conventions.

Modify the cube and cubepp applications to search the current directory first for lunarg.ppm and then this new system location. The current directory has priority and the application should close if it cannot find the file in either location.

Modify the CMake install target to install this file to the selected location.

Note that we had this same request some time ago from a package maintainer, but we turned it down at that time because the compiled shader binaries needed to be installed as well, and we were unsure about doing that.

Since then, the cube(pp) packaging has changed so that the shader binaries are compiled into the program text, removing the need to install the shader binaries and reducing the number of auxiliary files to one. It now seems more feasible to install this image file as described.

Another approach would be to store the contents of the texture image as a C source code file and compile the image into the program text. But this seems clunky.

@karl-lunarg karl-lunarg added the enhancement New feature or request label May 14, 2018
@mikew-lunarg
Copy link

KTX can put the image directly into API native format w/o requiring a runtime conversion library.
xxd can be used for a one-time conversion of binary image data to C code.

karl-lunarg added a commit that referenced this issue May 15, 2018
Now installs vulkaninfo and mock ICD.
Not yet installing cube(pp) pending decision on issue #5.
@sarnex
Copy link
Contributor

sarnex commented May 26, 2018

I am a maintainer for Gentoo and I am looking forward to the cube/cubepp demos and related textures being installed to the system.

Thank you.

karl-lunarg added a commit that referenced this issue May 29, 2018
- Modify cube and cubepp to obtain the texture image data from
  an include file instead of reading a PPM file at runtime.
  (This is the way it works for Android)
  This removes the need to install an image file or otherwise
  make an image file available in a repo build.
- Add cube and cubepp to the install target.

Fixes #5
@karl-lunarg
Copy link
Contributor Author

Although we know how to handle installing the assets (texture image file), we've decided to compile the image data into the cube and cubepp applications, which avoids the need to handle the installation of the image file. The Android version works this way, and it is just generally simpler to handle these simple demos when there are no other dependent files.

The PR for this issue will make these changes to cube(pp) and add them to the install target.

karl-lunarg added a commit that referenced this issue May 29, 2018
- Modify cube and cubepp to obtain the texture image data from
  an include file instead of reading a PPM file at runtime.
  (This is the way it works for Android)
  This removes the need to install an image file or otherwise
  make an image file available in a repo build.
- Add cube and cubepp to the install target.

Note: The file handling code is left in place to make it easy
to add a "-texture_file <file>" option so a user can pass in
a texture file.

Fixes #5
karl-lunarg added a commit that referenced this issue May 29, 2018
- Modify cube and cubepp to obtain the texture image data from
  an include file instead of reading a PPM file at runtime.
  (This is the way it works for Android)
  This removes the need to install an image file or otherwise
  make an image file available in a repo build.
- Add cube and cubepp to the install target.

Note: The file handling code is left in place to make it easy
to add a "-texture_file <file>" option so a user can pass in
a texture file.

Fixes #5
karl-lunarg added a commit that referenced this issue May 29, 2018
- Modify cube and cubepp to obtain the texture image data from
  an include file instead of reading a PPM file at runtime.
  (This is the way it works for Android)
  This removes the need to install an image file or otherwise
  make an image file available in a repo build.
- Add cube and cubepp to the install target.

Note: The file handling code is left in place to make it easy
to add a "-texture_file <file>" option so a user can pass in
a texture file.

Fixes #5
@karl-lunarg karl-lunarg self-assigned this May 29, 2018
karl-lunarg added a commit that referenced this issue May 30, 2018
- Modify cube and cubepp to obtain the texture image data from
  an include file instead of reading a PPM file at runtime.
  (This is the way it works for Android)
  This removes the need to install an image file or otherwise
  make an image file available in a repo build.
- Add cube and cubepp to the install target.

Note: The file handling code is left in place to make it easy
to add a "-texture_file <file>" option so a user can pass in
a texture file.

Fixes #5
@sarnex
Copy link
Contributor

sarnex commented May 30, 2018

Thanks Karl!

@mark-lunarg mark-lunarg added this to the sdk-1.1.77.0 milestone Jun 14, 2018
arunsivaramanneo referenced this issue Jan 23, 2019
We didn't quite get the check on whether a format can be legally
queried on a particular GPU quite right.  We were checking against
the instance version only.  We need to check agains the driver's
supported API version as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants