Repository navigation
The SUBSLICE_MASK GETPARAM interface isn't a well defined api #5
Description
Packing sub slice masks for all slices into a single mask is possible for current Gens but from userspace it's awkward to work with if it's not sure how many bits are used for each sub slice mask.
Although we expect for Broadwell the maximum number of slices to be 2, the HW has EU disable registers that theoretically account for up to 3 slices and the implementation of broadwell_sseu_info_init() works in terms of 3 as the maximum number of slices.
This isn't obvious to userspace which might reasonably assume only 2 bits are used for each sub slice mask on Broadwell. An interface that can avoid this kind of ambiguity would be less error prone.
Activity
matt-auld commentedon Jan 27, 2016
So If I understand this correctly, on gen graphics the hardware is split up into so called 'slices', the number of which is specific to each gen. Each slice is then made up of some number 'sub-slices', again specific to each gen, a sub-slice then has some number of EU's, usually 8(always?) , so on gen9 we have 3 slices, and 3 sub-slices, giving us 72 EU's. I guess the slicing idea is mostly helpful for power management, since slices/sub-slices can be power gated?
But this seems to be complicated by the fact that some number of, slices/sub-slices/EU's can be disabled, as seen in the various sseu_info_init methods. Why would these units ever need to be disabled?
Anyway, so the whole point of this is for the OA work, where there is this mythical $SubsliceMask in the xml files, which I guess is used in the equations to derive the various counter values, and this value is itself derived from the subslice_mask. Specifically this seems to be a u32 mask, which is the ss_disable mask covering all enabled slices, as a single mask. So for CHV, which has only 1 slice and 2 sub-slices, this becomes nice and simple.
Why is it that this 'packing' process happens again in GPU top, which seems kind of funky, but I'm probably missing something.
Also as a side-note in GPU top the gen9 ss_max is hard-coded to 4, but in the kernel the value is 3, and for gen8 s_max is 2 but the in the kernel 3.
perf tools: tracepoint_error() can receive e=NULL, robustify it
usb: chipidea: otg: change workqueue ci_otg as freezable
ath9k: fix GPIO mask for AR9462 and AR9565
kexec: fix double-free when failing to relocate the purgatory
ath9k: fix client mode beacon configuration
Merge branch 'sun4v-64bit-DMA'
timekeeping: Use deferred printk() in debug code
inet: frag: release spinlock before calling icmp_send()
cgroup: avoid attaching a cgroup root to two different superblocks
timekeeping: Use deferred printk() in debug code
MIPS: perf: fix deadlock
RDMA/i40iw: Remove MSS change support
perf annotate: Fix branch instruction with multiple operands
USB: gadget: fix GPF in gadgetfs
34 remaining items
fm10k: Fix a potential NULL pointer dereference
Merge branch 'mlxsw-Various-fixes'
net: netrom: Fix error cleanup path of nr_proto_init
perf tools: Fix map reference counting
Merge branch 'mlxsw-Various-fixes'
tracing: Fix out-of-range read in trace_stack_print()
dmaengine: imx-sdma: remove BD_INTR for channel0
ALSA: oxfw: fix return value in error path of isochronous resources r…
ALSA: fireface: fix return value in error path of isochronous resourc…
rtc/cmos: Protect rtc_lock from interrupts
perf/core: Only copy-to-user after completely unlocking all locks, v3.
rtc: cmos: Disable irq around direct invocation of cmos_interrupt()
powerpc/vdso: Fix incorrect CFI in gettimeofday.S
ice: fix crash when writing timestamp on RX rings
KVM: eventfd: Fix false positive RCU usage warning