| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider the following situation:
mtx_lock(mutex);
do_something();
util_queue_add_job(...);
mtx_unlock(mutex);
If the queue is full, util_queue_add_job will wait for a free slot.
If the job which is currently being executed tries to lock the mutex,
it will be stuck forever, because util_queue_add_job is stuck.
The deadlock can be trivially resolved by increasing the queue size
(reallocating the queue) in util_queue_add_job if the queue is full.
Then util_queue_add_job becomes wait-free.
radeonsi will use it.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
for HUD integration in following commits. This valuable profiling data
will allow us to see on the HUD how well glthread is able to utilize
parallelism. This is better than benchmarking, because you can see
exactly what's happening and you don't have to be CPU-bound.
u_threaded_context has the same counters.
Reviewed-by: Timothy Arceri <[email protected]>
|
| |
|
|
| |
Reviewed-by: Samuel Pitoiset <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
This will allow us to use it outside of gallium for things like
compressing shader cache entries.
Reviewed-by: Marek Olšák <[email protected]>
|
