On Sat, Jun 6, 2015 at 3:21 PM, Francisco Jerez <curroje...@riseup.net> wrote: > Giuseppe Bilotta <giuseppe.bilo...@gmail.com> writes: > >> What I was trying to say is that while the cap itself is per-device, >> the OpenCL property that relies on this cap isn't. >> In this sense, I would expect the cap to report the actual _hardware_ >> property, and the higher level stack (OpenCL or whatever, if and when >> it will be supported) to massage the value as appropriate (e.g. by >> multiplying by 4x —the overcommit needed to keep the device pipes >> full— and then dividing by the vector width of the kernel). >> > The problem is that it requires a lot of hardware-specific knowledge to > find the right over-commit factor (instruction latencies, issue > overhead, the fact that in some cases the pipeline is twice as wide), > and whether and to what extent the kernel needs to be scalarized -- and > the OpenCL state tracker is hardware-independent.
I see. In this sense, it does make sense that the hardware capability itself tries to encompass as much information as possible, and thus provide a value that the OpenCL state tracker can use without further knowledge. I still suspect that this number by itself won't be sufficient (so some other information _will_ be needed for efficiency), but as long as it's the only one I do agree that using (for ILO) 16 (or even 32) will be better than using the hardware SIMD width of 4 (or 8). As such, for me the patch in question can go in, with possibly some extra details in the comment. -- Giuseppe "Oblomov" Bilotta _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
