| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables EGL_KHR_fence_sync and EGL_KHR_wait_sync.
Below is the difference in piglit results, before and after this patch.
No regressions and several tests improve from 'skip' to 'pass'. Out of
EGL_KHR_fence_sync tests, two of the multithreaded tests skip; all other
tests pass.
cmdline: piglit run -p gbm -t sync tests/quick.py
mesa: master@1ac7db0
piglit: 4069bec
hw: Ivybridge
| before after
------+-------------
pass | 32 46
fail | 0 0
crash | 0 0
skip | 35 21
total | 67 67
v2:
- Set fence->signalled = true in brw_fence_has_completed() too.
Reviewed-by: Daniel Stone <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm about to implement DRI2_Fenc in intel_syncobj.c. To prevent
madness, we need to prefix functions for GL_ARB_sync with 'gl' and
functions for DRI2_Fence with 'dri'. Otherwise, the file will become
a jumble of similiarly named functions.
For example:
old-name: intel_client_wait_sync()
new-name: intel_gl_client_wait_sync()
soon-to-come: intel_dri_client_wait_sync()
I wrote this renaming commit separately from the commit that implements
DRI2_Fence because I wanted the latter diff to be reviewable.
Reviewed-by: Daniel Stone <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Daniel Stone <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Don't pass NULL to drm_intel_bo_unreference(). It doesn't like that.
Bug found by code inspection.
Reviewed-by: Daniel Stone <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
DRM_IOCTL_I915_GEM_WAIT takes an int64_t for the timeout value but
GL_ARB_sync takes an uint64_t. Further, the ioctl used to wait
indefinitely when passed a negative timeout, but it's been broken and
now returns immediately in that case. Thus, if an application passes
UINT64_MAX to wait forever, we overflow to -1LL and return immediately.
Work around this mess by clamping the wait timeout to INT64_MAX.
Signed-off-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
| |
|
|
|
|
| |
These don't appear to be necessary. Everything compiles just fine.
Signed-off-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
| |
intel_flush() now did nothing except call through (and
intel_batchbuffer_flush() does the no-op check, too!)
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
| |
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Acked-by: Chris Forbes <[email protected]>
Acked-by: Paul Berry <[email protected]>
Acked-by: Anuj Phogat <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes brw_context available in every function that used
intel_context. This makes it possible to start migrating fields from
intel_context to brw_context.
Surprisingly, this actually removes some code, as functions that use
OUT_BATCH don't need to declare "intel"; they just use "brw."
Signed-off-by: Kenneth Graunke <[email protected]>
Acked-by: Chris Forbes <[email protected]>
Acked-by: Paul Berry <[email protected]>
Acked-by: Anuj Phogat <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
brw_context.h includes intel_context.h, but additionally makes the
brw_context structure available. Switching this allows us to start
using brw_context in more places.
Signed-off-by: Kenneth Graunke <[email protected]>
Acked-by: Chris Forbes <[email protected]>
Acked-by: Paul Berry <[email protected]>
Acked-by: Anuj Phogat <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Now that i915's forked off, they don't need to live in a shared directory.
Acked-by: Kenneth Graunke <[email protected]>
Acked-by: Chad Versace <[email protected]>
Acked-by: Adam Jackson <[email protected]>
(and I hear second hand that idr is OK with it, too)
|
|
|
We currently weasel out of supporting the timeout parameter, but otherwise
this extension looks ready, and should make the common case happy.
|
