Address comment from Jaime

Author: gmlueck

sycl/doc/extensions/proposed/sycl_ext_intel_cslice.asciidoc

@@ -83,19 +83,21 @@ Therefore, a device must first be partitioned into per-tile sub-devices via
 be further partitioned by `ext_intel_partition_by_cslice`.
 
 It is important to understand that the device driver virtualizes work
-submission to the cslice sub-devices.  This virtualization happens only between
-processes, and not within a single process.  For example, consider a single
-process that constructs two SYCL queues on cslice sub-device #0.  Kernels
-submitted to these two queues are guaranteed to conflict, both using the same
-set of execution units.  Therefore, if a single process wants to explicitly
-submit kernels to cslice sub-devices and it wants to avoid conflict, it should
-create queues on different sub-devices.  By contrast, consider an example where
-two separate processes create a SYCL queue on cslice sub-device #0.  In this
-case, the device driver virtualizes access to this cslice, and kernels
-submitted from the first process may run on different execution units than
-kernels submitted from the second process.  In this second case, the device
-driver binds the process's requested cslice to a physical cslice according to
-the overall system load.
+submission to the cslice sub-devices.  (More specifically, the device driver
+virtualizes work submission to different CCS-es, and this means that on PVC
+the work submission to a cslice is virtualized.)  This virtualization happens
+only between processes, and not within a single process.  For example, consider
+a single process that constructs two SYCL queues on cslice sub-device #0.
+Kernels submitted to these two queues are guaranteed to conflict, both using
+the same set of execution units.  Therefore, if a single process wants to
+explicitly submit kernels to cslice sub-devices and it wants to avoid conflict,
+it should create queues on different sub-devices.  By contrast, consider an
+example where two separate processes create a SYCL queue on cslice sub-device
+#0.  In this case, the device driver virtualizes access to this cslice, and
+kernels submitted from the first process may run on different execution units
+than kernels submitted from the second process.  In this second case, the
+device driver binds the process's requested cslice to a physical cslice
+according to the overall system load.
 
 Note that this extension can be supported by any implementation.  If an
 implementation supports a backend or device without the concept of cslice