anholt has quit [Remote host closed the connection]
Dark-Show has joined #zink
eukara has quit [Ping timeout: 480 seconds]
cjxgm has quit [Quit: cjxgm]
cjxgm has joined #zink
cjxgm has quit []
Dark-Show has quit [Ping timeout: 480 seconds]
Dark-Show has joined #zink
Dark-Show has quit [Quit: Leaving]
pac85 has joined #zink
<pac85>
zmike: so currently in my legacy precompilation MR only the Uber shader gets precompiled and it gets used for the base variant (temporarily) as well. Now I was thinking of extending this to be more clever.
<pac85>
As discussed we don't want to compile uber shader until a legacy feature is ever encountered. So at first we would precompile base variants then switch to the current logic.
<pac85>
However readiing back some older discussions you suggested to instead precompile both a uber and base variant pipeline once a legacy feature is enountered.
<pac85>
The uber shaders can obviosuly handle the base variants and are only used for a few frames at most then replaced with the real base variant (compiled asyncrhously starting from when they are requested like any other variant) so do you still think this is necessary?
<zmike>
hm I have no memory of these discussions
<zmike>
let me consider this
<pac85>
understandable, I myself had forgotten what you had said and had to look back. But wither way yeah just let me know what you think so I can start working on that. I think the rest of the series is pretty solid as this point (besides flatshading emulation, I will get rid of it temporarily at some point)
<zmike>
pac85: was this comments on the MR or discussion here?
<pac85>
zmike: here, grep for "loading screen"
<zmike>
hm I don't see it in my logs
<zmike>
let me look harder
<pac85>
try load screen
<zmike>
ahh right
<zmike>
okay
<zmike>
I think I'd need to see timing info on a couple drivers for pipeline compiles of ubershaders vs standard precompile variants to be able to say "always compile ubershader"
<zmike>
because the number of passes being run to generate the ubershader and the increased size of those shaders could unnecessarily extend load screens in cases where no legacy features are used
<zmike>
as far as using ubershaders:
<zmike>
* originally I'd said to use standard variants because the ubershader precompile variants will have extra key data needing to be compared which would slow down execution; this is not going to change
<zmike>
* if it's possible to use the ubershader variants without doing those extra comparisons (i.e., the ubershader by default takes the non-legacy path) then it becomes possible to use them by default
<zmike>
in short: in order to use the ubershaders for all precompiles, they would need to not be measurably more cpu-ful to generate than standard variants and they would need to be able to operate without accessing legacy key data
<pac85>
mmm, I intepreted your original message as precompiling both uber and base variants when at least one legacy feature is seen. Always using the uber shader even when no legacy features are encountered is not something I'd do myself.
<zmike>
it depends
<zmike>
being able to always use the ubershader for the precompile path will be more optimal for maintenance/debugging since it means there is only one precompile path
<zmike>
so ideally we can take this route
<zmike>
the alternative is that yes, we will need to precompile both variants
<pac85>
but not at the same time right?
<zmike>
yes
<zmike>
because both would need to be ready
<pac85>
mmm, but why? the uber shader can handle base variants and we are already paying the price to compile it right?
<zmike>
in the case where the ubershader cannot, by default, select all the non-legacy paths, then the base variant would need to be used
<pac85>
mmm what do you mean?
<zmike>
I'm saying in the scenario where an ubershader is used for a pipeline with no legacy features, the push constant range should be zeroed with memset
<zmike>
so the "default" (zero) path for all the legacy branching in the ubershader should work such that reading zero means take the non-legacy path
<pac85>
yeah that's how it works
<zmike>
great
<pac85>
I mean the st key is always kept up to date when a uber shader is bound so implicitly the base case is hadnled correctly
<pac85>
so we never truly require the base variant
<zmike>
right but this needs to happen without accessing the st key
<zmike>
there needs to be a flag on the prog like "uses_legacy_features" and then switching that on/off on prog bind writes pushconst data
<pac85>
mmm, the st key is always there. Once the pipe caps are set (which happens at screen creation time) all of the st emulation is done in zink which needs the st key needs to be up to date, it also needs to be sent to push constants because some things are always sent that way. How could this be avoided?
<pac85>
well not all of the st emulation but at least the subset currently supported
<zmike>
ah I misspoke
<zmike>
when st features are in use, there should be a bitmask on the ctx
<zmike>
which should enable compares like if (!cur_state && cur_state != last_state) -> memset(pushconsts, 0, sizeof(pushconsts)
<zmike>
and then the usual foreach iterating of the mask to track updates or somesuch
<zmike>
is probably how I'd do it
<zmike>
this way the "fast" (non-legacy) path only hits a single int comparison of the mask to determine there are no legacy features active, and in this case it does nothing
<pac85>
well, the st key is currently devided in half and updated on state changes. One half is sent as push constants and it happens to be 0 when no features are used
<pac85>
actually all of it is sent as push constants
<pac85>
but one half also acts as the key for the optimized variants
<zmike>
yes, I'm talking about a mask just of which features are enabled
<zmike>
not their values
<pac85>
yes that woukld be the first half basically
<zmike>
so it sounds like you're on track
<pac85>
hopefully yeah
<pac85>
so given all of this, do you think swtiching to uber shaders for base variants would be accteptable after encountering one legacy feature?
<zmike>
sounds like yes
<pac85>
(again, temporarilt, a proper base variant would be compiled after a few frames)
<pac85>
good, thank you!
<zmike>
the "base variant" in this case I'd expect would be the optimized variant
<pac85>
yes
<zmike>
after precompile
<pac85>
we have a special path for it to avoid hasmap lookups
<pac85>
but yeah it acts like any other optimized variant semantically
<zmike>
cool
Dark-Show has joined #zink
neobrain has quit [Remote host closed the connection]
italove8 has joined #zink
anholt has joined #zink
<Dark-Show>
Hey, doing some testing on V3DV again. Having some graphical issues on Zink, tried most of the debugging options listed on the blog with no change.
<zmike>
uh oh
<Dark-Show>
The issue is with a Glide wrapper from www.svenswrapper.de It uses one of: GL_EXT_paletted_texture, GL_ARB_fragment_program, GL_ATI_fragment_shader.
<Dark-Show>
When all three are disabled in glide-init.exe the proper image is displayed. The graphics error changes depending on which extensions you have enabled. The earliest bug is the menu items being 'too short' and textures having 'black areas' in game. With only paletted_texture the menu is rendured in a shade of red.
<Dark-Show>
I have yet to compile and test on x64
<Dark-Show>
I use the wrapper with Diablo II
<zmike>
it'd be good if you could test on another platform for comparison