opencl and opengles Interop problem

Two levels of timeout can be set in the kernel driver, and are configured by the system integrator:

• SOFT_STOP - jobs taking longer than this are suspended to allow other things to run, but can be restarted later
• HARD_STOP - jobs which take longer than this and which don't SOFT_STOP are killed

However in general these are relatively high timeouts designed for system stability, not for interactive scheduling of work within a process. If the foreground application is sending very large workloads to the GPU then it probably has a good reason to do so, and it really isn't the job of the GPU driver to second guess what the application developer told us to do. Even for graphics-only applications there is content which runs slower than 30 FPS especially at high resolutions - we've certainly seen some benchmarks submit single rendering operations which take longer than 200ms - and it would be "wrong" to kill those workloads.

Two levels of timeout can be set in the kernel driver, and are configured by the system integrator:

• SOFT_STOP - jobs taking longer than this are suspended to allow other things to run, but can be restarted later
• HARD_STOP - jobs which take longer than this and which don't SOFT_STOP are killed

However in general these are relatively high timeouts designed for system stability, not for interactive scheduling of work within a process. If the foreground application is sending very large workloads to the GPU then it probably has a good reason to do so, and it really isn't the job of the GPU driver to second guess what the application developer told us to do. Even for graphics-only applications there is content which runs slower than 30 FPS especially at high resolutions - we've certainly seen some benchmarks submit single rendering operations which take longer than 200ms - and it would be "wrong" to kill those workloads.