<kusma>
zmike: I rather want a good reason to do it than to not do it...?
<kusma>
Oh. PIPE_MAX_VIEWPORTS is 16. Yeah, then that's the right thing to do!
<kusma>
But yeah, clamp it to PIPE_MAX_VIEWPORTS, not 16 hard-coded ;)
<zmike>
cool
<zmike>
I'm working on consolidating pipeline hash bits
<zmike>
ANGLE was recently bragging about their 256bit pipeline hash, and zink's is...a lot bigger
<kusma>
Haha :)
<kusma>
I was wondering if it would make sense to have a small and a big hash, for with and without various dynamic state-ism...
<zmike>
we already have that
<kusma>
Well, just sorta.
<kusma>
We don't exclude everything there
<kusma>
In particular the vertex state AFAIK
<zmike>
that's because the vertex state can't be excluded without dynamic vertex input ext
<kusma>
That being said, I think that particular state needs to be conditional, because of stride-limitations that we can't guarantee
<kusma>
(ref !9829)
<zmike>
I think that's going to end up being another extension
<kusma>
What do you mean?
<zmike>
there's no reason drivers can't do stride==0, it's just a problem with guaranteeing robustness if that's the case, which was required for the original ext
<zmike>
so for stride==0 a new extension with a new dynamic state is required
<kusma>
Right. But we still need to handle the situation of having EXT_extended_dynamic_state but not that extension, no? Or are you planning on not using EXT_extended_dynamic_state for vertex-stuff in that case?
<zmike>
it's not a high priority for me in either case since I have to do spec stuff for it, which is going to take a while
<zmike>
there's much more important things that can realistically be handled now
<zmike>
hch12907: I found an issue in the dispatch table loader
<zmike>
if I try to use this and don't enable all the features, it still tries to load all the functions, fails because the features aren't enabled, and then aborts
<zmike>
I guess this is an issue with the verify code
<hch12907>
welp, we hit that problem faster than what I thought
<zmike>
I don't believe there's any way to detect this from the xml
<zmike>
hm
<zmike>
really I'm not sure why we're verifying now that it's all autogenerated?
<zmike>
at that point it's either a core mesa issue or a loader bug, so carrying on and crashing later seems fine to me
<hch12907>
yep, the registry does not include information such as "this is available when that is enabled"
<zmike>
so I think you can just remove the verify code
<hch12907>
it was either crash-fast with information, or crash-later and scratch our heads, I chose crash-fast
<zmike>
haha
<zmike>
hm
<zmike>
maybe just print that it's missing
<zmike>
and don't fail screen setup
<kusma>
Dropping the verification seems fine to me
<zmike>
then we'll have the info and can still run the app if it's not a fatal error
<hch12907>
working on it
<zmike>
cool, thanks
<kusma>
Do we get null pointers for them? If so, we could replace them with a function that complain if called
<zmike>
yea
<zmike>
seems easier to just warn on startup, though then it's going to be warning 100% of the time once I get this stuff in, which seems annoying...
<hch12907>
kusma: yea we get null pointers if the functions are not loaded
<hch12907>
maybe a stub that prints "X is unimplemented, here be dragons" for NULL functions?