- Program one PS with gpgpu selection and media sampler
- Program PS only when media sampler requirement changed
or when preamble was not sent
Change-Id: I85ba3f74087733e79d048e120aeb8b4b04796e00
Fixing InterfaceDescriptor programming for
blocked commands when MidThread preemption is
enabled
Additionally, fixing couple of tests that block
global preemption enabling in ULTs
Change-Id: I454c9608f8606f23d7446785ac24c7c7d8701ae0
- It should use thread count not EU count.
- change variable name to reflect that we work on sublices.
- fix test description, add missing test
- change hasBarrier variable to be boolean
Change-Id: I627bdf17b661d2f9b5eb3d8cd6ca53eba5d46b81
- Call waitForTaskCountAndCleanAllocationList with latest flushed task count
to reflect what was actually sent to HW.
- refactor cleanAllocationList to waitForTaskCountAndCleanAllocationList
Change-Id: I5301185c5fce212e39eb017b952b43c279559cf4
- Prevents destruction of MemObj while it may still be in use.
- Add UNRECOVERABLE to check whether object is deleted while having
dependencies, fix all problems is tests due to that fact.
- Fix special queue setting, clean interfaces.
Change-Id: I2a467e80df00ea1650decdcfa6866acf10b441f8
- When command queue is blocked, all heaps are being stored in temporary
allocations, command buffers are being pre-programmed, heaps are being set
on those temporary allocations with the assumption that all heaps start with
offset 0.
- Problem was when the actual submissions happened, all those temporary heaps
were just copied to appended command queue heaps, so when something was there
then new stuff was copied right after it. It means that all state was
incorrect as the offsets are not valid anymore and will point to wrong
location.
- This change releases command queue heaps when blocked command is being
submitted to make sure they will be programmed with the proper offset in newly
allocate command queue heap.
Change-Id: I3e30be13caf4df8621ddb18f8448ffaf0f1278d1
- due to the fact that device mutex was obtained to prevent threaded access to
image there was a problem when other thread was also doing readImage call
That thread got read Image kernel mutex first and then it was acquiring device
mutex, which was taken by other thread doing mapImage call.
- In current code device mutex is not taken to service mapImage call, instead
image is being guarded by its own mutex.
Change-Id: Ic4c5a019708d7ec5b240bc5b08c5a65173827392
- Fix tests that were triggering the UNRECOVERABLE scenario
- Change UNRECOVERABLE to DEBUG_BREAK in some places
Change-Id: I479baac4941b485af9ea81a61a1a03d2f3f42e6a
- This causes event tree update if virtual event is holding commands or
callbacks
- That causes race between other threads that may be updating the tree
Change-Id: Ic80a8b71ed1e1c1deab8af1bc64f8ce81c21de1b
Mateusz Jablonski