Vulkan 1.0.9 Specification Released
Collapse
X
-
One thing I forgot to mention - there were some comments about the initial Vulkan drivers not being able to run fullscreen (on Windows I think), but running "borderless" instead. Not sure how much that would affect performance but seems like it might be a factor. If there was an additional full-screen copy required every frame that could have some of the same "gap widens with resolution" effect as a slow shader compiler.Last edited by bridgman; 09 April 2016, 04:51 PM.Test signature
Comment
-
-
Originally posted by norsetto View Post
I was reading this just yesterday (http://www.aosabook.org/en/llvm.html) and I understood that a first optimization in llvm is done at the IR level. Still, I would expect some form of optimization to take place in the last compilation step as in principle during the IR processing phase one would know nothing about the target hardware.
I must admit this whole Vulkan rigmarole is quite above my head right now, I dream of the day I may have drivers available on my machine so that I can start tinkering around...
note this example
if (1 == 0) { // a lot of lines of expensive code } }
with dead code removal, this will simply be dropped. but, main question here is? how do you define this in specification? will you create gazillion samples of such "invalid" code?
what would be more than possible is some sort of standalone SPIR-V post processor that does what you say. feed SPIR-V and get out step 1 optimized SPIR-V and note the main thing here. both are same SPIR-V, so i cannot really figure out how optimization would fall into its scope. and since SPIR-V specification is completely open, nothing prevents people to write such tool
update: this is just my opinion, but you really want to have at least one result that does exactly what you told it to. as soon as first possible result is optimized you're prone to find errors in that and if you have no exact reference, it makes job of assigning blame to find the root of the problem much harderLast edited by justmy2cents; 09 April 2016, 01:41 PM.
Comment
-
-
Thanks for talking about this a bit, I forwarded the info to the original developer who sparked it, perhaps he will rethink Vulkan support in the future. I was trying to get him to reconsider it so that perhaps we could get Linux support at the end of development with Vulkan API but I just know very little about the whole issue so couldn't help.
Comment
-
-
Originally posted by theriddick View PostThanks for talking about this a bit, I forwarded the info to the original developer who sparked it, perhaps he will rethink Vulkan support in the future. I was trying to get him to reconsider it so that perhaps we could get Linux support at the end of development with Vulkan API but I just know very little about the whole issue so couldn't help.Last edited by justmy2cents; 09 April 2016, 05:35 PM.
Comment
-
-
As of today, the only spir-v compiler available is glslang, which, in their own words, is still experimental and not optimized. Then again, nothing prevents anyone to invent their own shading language and write up a spir-v compiler for it (I know at least one developer who might do just that ...). And of corse why not writing them in spir-5 itself?Last edited by norsetto; 10 April 2016, 12:31 AM. Reason: It could actually be fun to write a spir-5 shader
Comment
-
-
Originally posted by norsetto View PostAs of today, the only spir-v compiler available is glslang, which, in their own words, is still experimental and not optimized. Then again, nothing prevents anyone to invent their own shading language and write up a spir-v compiler for it (I know at least one developer who might do just that ...). And of corse why not writing them in spir-5 itself?
Besides Time, Effort, and Money? :/
Comment
-
Comment