search

KhronosGroup / Vulkan-Ecosystem

Public repository for Vulkan Ecosystem issues
Apache License 2.0
133 stars 15 forks source link

Add spec project to the list #19

Closed krOoze closed 6 years ago

krOoze commented 6 years ago

I wasn't sure who to add as contact (if anyone). @oddhack (Jon Leech) seems to be in charge of the repo...

KarenGhavam-lunarG commented 6 years ago

+1

nsubtil commented 6 years ago

I'm a bit conflicted here. It fits, but it's not clear what the usefulness of having this here really is. A user interested in Vulkan will likely have encoutered the spec before coming over to the ecosystem repo.

Can we clarify the purpose? What value-add does this bring for users? Are there components in that repo that are useful but not well publicized? Should we consider publicizing individual components and/or moving them out of the spec repo?

karl-lunarg commented 6 years ago

From the README:

This repository is used as a tracker for cross-functional issues that affect Vulkan users.

Vulkan users refer to the spec a great deal, so the way it is presented and published affects them. There are a lot of issues like how reference pages work, the size of HTML files which affects usability in terms of loading time, etc.

The Vulkan registry also lives here (vk.xml), which is used by people to make various tools. It also is used by a few of the other repositories already in this list, which satisfies the "cross-functional" component of the purpose of this list.

Seems like this should be in the list, perhaps even at the top of it.

krOoze commented 6 years ago

@nsubtil You could make the same argument over the layers links. We do not make a list for people that already know (or can google 😛 ).

With layers the first surprise typicaly is that they even exist and should be used. The second surprise is that they are open-source.

Similarly it goes for the specification. First surprise is that it is quite readable and should be read (there are many coming from references and tutorials that want to know some detail, yet did not dare to go to the spec, or cannot even imagine there is a formal specification.) Second surprise is that it is open-source, so people should be encouraged to report Issues instead of ignoring them. And third, yea, the repo contains few more things besides the spec.

the size of HTML files which affects usability in terms of loading time, etc.

Seriously though. The KaTeX was big improvement, but it is still atrocious. I think the sidebar or something made it worse... the layout is calculated too long. It would be so nice if someone that knows his html profiling gave it a look.

HansKristian-Work commented 6 years ago

Definitely should be on the list imo. Making it clear the spec is actually open on Github and you can file issues against it will be a big surprise to most.

Part of our goal should be to lead developers to actually file issues which concern them rather than hacking around them.

TomOlson commented 6 years ago

+1 Makes sense to me; a list like this should not be exhaustive (i.e. "here's every project you could possibly want to look at"), but should be complete at its chosen level of must-see-ness (i.e. "here are the top N resource projects", or "here are N project sites every Vulkan developer absolutely needs to know about"). If the list has obvious gaps, it reduces confidence.