Eero Tamminen

> * `hw.type`: Have several examples, but since it's "open" I wonder if this could cause problems? > * `hw.error.type`: Same thing as above: Not defined in an enum or...

> I'm a bit surprised by the actual definition, which is counter-intuitive: a "limit" shouldn't necessarily mean a total amount. > ... > Different types of limits can be precised...

> In the meantime, we recommend using the `firmware_version` attribute to put all necessary information. It's a free format string, it doesn't need to be exactly `x.y.z`. You set this...

>> The `hw.error.type` is a free format string that you can set to any applicable value. > > Not really the answer I was expecting... :-/ @bertysentry I mean, different...

> @eero-t Don't worry, we totally understand there are different types of errors that need different responses. That's the reason of the `hw.error.type` attribute, to cover different types (or categories)...

I'd also like some documentation on the update process, e.g. how often these SHAs will be updated after this? I mean, `unstable` distros (like Debian one) gets updates constantly, even...

> > Can you also try using Level-zero backend? > > How do I do that? NEO/IGC/SyCL is level-zero backend, but as you're selecting GPU, maybe that question was about...

> I'm confused; does NEO/IGC have a _cpu_ back-end? FWIW, using `sycl::cpu_selector` simply throws a `PI_ERROR_DEVICE_NOT_FOUND`. Sorry, I was confused myself... > It doesn't reproduce consistently though; is it possible...

`sharedDevNum` is mostly intended to be used when either: * User running the workloads manually takes care of not oversubscribing the GPUs (e.g. in test cluster), * Cluster runs only...

Could you make also a PR for that?