All SKL SKUs except the lowest one which has half the L3 size actually have 384K
of URB per slice.
For once, I can explain how this mistake was made and how it was missed in
review... Historically when we enable a platform and put the production sizes,
you can simply look at the "smallest" SKU and see what its URB size is (and we
assumed it was the 1 slice variant). Since on newer platforms the URB sizes are
scaled automatically by HW, this was sufficient. On SKL, this is a bit different
as the lowest SKU actually has half of the L3 fused off. GT2 is the 1 slice (not
GT1) variant and it has 384K.
There are no Jenkins tests fixed (or regressions) and we don't expect any fixes
here because you can always run with less URB size.
Thanks to Sarah for bringing this to my attention.
Cc: Sarah Sharp <sarah.a.sharp@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
.max_wm_threads = 64 * 6, \
.max_cs_threads = 56, \
.urb = { \
- .size = 192, \
+ .size = 384, \
.min_vs_entries = 64, \
.max_vs_entries = 1856, \
.max_hs_entries = 672, \
static const struct brw_device_info brw_device_info_skl_gt1 = {
GEN9_FEATURES, .gt = 1,
+ .urb.size = 192,
};
static const struct brw_device_info brw_device_info_skl_gt2 = {