On 02/19/2014 06:05 PM, Ian Romanick wrote: > On 02/19/2014 05:40 PM, Kenneth Graunke wrote: >> brw_init_state() calls brw_upload_initial_gpu_state(). If hardware >> contexts are enabled (brw->hw_ctx != NULL), this will upload some >> initial invariant state for the GPU. Without hardware contexts, we >> rely on this state being uploaded via atoms that subscribe to the >> BRW_NEW_CONTEXT bit. >> >> Commit 46d3c2bf4ddd227193b98861f1e632498fe547d8 accidentally moved >> the call to brw_init_state() before creating a hardware context. >> This meant brw_upload_initial_gpu_state would always early return. >> Except on Gen6+, we stopped uploading the initial GPU state via >> state atoms, so it never happened. >> >> Fixes a regression since 46d3c2bf4ddd227193b98861f1e632498fe547d8. > > This seems like a rational change... but why didn't 46d3c2b blow up the > world on IVB and HSW? ...and only cause heisenbugs on BDW?
Presumably because it doesn't do much. On Gen6+, all it does is: - PIPELINE_SELECT (probably already render, unless you're doing media/gpgpu) - STATE_SIP (basically only matters if you hit breakpoints or invalid operations) - VF_STATISTICS (we don't use the counters anyway) On Broadwell, it also uploads 3DSTATE_SAMPLE_PATTERN, which meant that any Piglit test that relied on legitimate sample positions would fail. That is, until I ran with a branch that actually emitted 3DSTATE_SAMPLE_PATTERN---after that, the sample positions remained programmed, and tests continued to work fine until reboot. >> Cc: "10.0 10.1" <mesa-sta...@lists.freedesktop.org> >> Signed-off-by: Kenneth Graunke <kenn...@whitecape.org> > > Either way, > > Reviewed-by: Ian Romanick <ian.d.roman...@intel.com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
