There's an intermittent flushing problem with VkEvent that we need to
root cause. For now, using the snooping feature keeps the memory pools
up to date with GPU writes and fixes the problem.
We can't use the more fine-grained load and store fence commands (lfence
and mfence), since clflush is only guaranteed to be ordered with respect
to mfence.
The attachments should be const, but the driver's function signatures
are generally not const-friendly.
Drop the const because it conflicts with upcoming
anv_cmd_buffer_resolve_subpass().
The adjusted polynomial coefficients come from the numerical
minimization of the L2 norm of the relative error. The old
coefficients would give a maximum relative error of about 15000 ULP in
the neighborhood around acos(x) = 0, the new ones give a relative
error bounded by less than 2000 ULP in the same neighborhood.
SKL has a workaround which requires either some weird programming of buffer 3,
OR, just never using buffer 0. Since we don't actually use multiple constant
buffers, it's easier to just not use 0.
Only SKL requires this workaround, but there is no harm in applying it to all
platforms. The big change here is that buffer #0 is relative to dynamic state
base normally (depending upon ISTPM), where buffer 1-3 is a GPU virtual address.
Remove all the fine-grained cleanup in
anv_device_init_meta_clear_state(). Instead, if anything fails during
initialization, simply call anv_device_finish_meta_clear_state() and let
it clean up the partially initialized anv_meta_state::clear.
This handles multisample color images that have a floating-point or
normalized format and have a single array layer.
This does not yet handle integer formats nor multisample array images.
As far as I can tell, this patch sets all pipeline multisample state
except:
- alpha to coverage
- alpha to one
- the dispatch count for per-sample dispatch
The dEQP "precision" test tries to verify that the reference functions
float sinh(float a) { return ((exp(a) - exp(-a)) / 2); }
float cosh(float a) { return ((exp(a) + exp(-a)) / 2); }
float tanh(float a) { return (sinh(a) / cosh(a)); }
produce the same values as the built-ins. We simplified away the
multiplication by 0.5 in the numerator and denominator, and apparently
this causes them not to match for exactly 1 out of 13,632 values.
So, put it back in, fixing the test, but making our code generation
(and precision?) worse.
