On Tue, Apr 5, 2016 at 9:04 AM, Marek Olšák wrote:
> On Mon, Apr 4, 2016 at 2:43 PM, Rob Clark wrote:
>> Hmm, what are the requirements of eglClientWaitSyncKHR() about having
>> current context bound? Not being thread-safe (ie. being associated w/
>> current ctx) is pretty important to allow app
On Mon, Apr 4, 2016 at 2:43 PM, Rob Clark wrote:
> Hmm, what are the requirements of eglClientWaitSyncKHR() about having
> current context bound? Not being thread-safe (ie. being associated w/
> current ctx) is pretty important to allow apps that create fences at
> in-opportune times to not force
Hmm, so we could actually use EGL_SYNC_FLUSH_COMMANDS_BIT_KHR (which
is ignored when there is not a ctx bound).. from looking closer at
KHR_fence_sync this appears to be how things are expected to work.
ofc that means that you end up needing to keep both
ctx->fence_finish() and screen->fence_finis
well,
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/IFiv8rZfAq0
does imply that it could be called without a ctx bound.. hmm..
BR,
-R
On Mon, Apr 4, 2016 at 8:43 AM, Rob Clark wrote:
> Hmm, what are the requirements of eglClientWaitSyncKHR() about having
> current
Hmm, what are the requirements of eglClientWaitSyncKHR() about having
current context bound? Not being thread-safe (ie. being associated w/
current ctx) is pretty important to allow apps that create fences at
in-opportune times to not force a mid-frame flush for tilers.. :-(
BR,
-R
On Mon, Apr
There is one problem with this: It doesn't allow calling
pipe_context::fence_finish from another thread in a thread-safe
manner, and it implies that fence_finish is generally NOT thread-safe.
This thread safety is something I'd like to preserve.
I would say that a flush flag telling the driver not
Am 03.04.2016 um 17:05 schrieb Rob Clark:
> On Sat, Apr 2, 2016 at 8:31 PM, Rob Clark wrote:
>> On Sat, Apr 2, 2016 at 7:55 PM, Roland Scheidegger
>> wrote:
>>> I don't really have anything against the new interface (though don't
>>> really feel qualified for a proper review), but it is indeed t
Am 03.04.2016 um 02:31 schrieb Rob Clark:
> On Sat, Apr 2, 2016 at 7:55 PM, Roland Scheidegger wrote:
>> I don't really have anything against the new interface (though don't
>> really feel qualified for a proper review), but it is indeed the
>> existence of the two interfaces living in parallel se
On Sat, Apr 2, 2016 at 8:31 PM, Rob Clark wrote:
> On Sat, Apr 2, 2016 at 7:55 PM, Roland Scheidegger wrote:
>> I don't really have anything against the new interface (though don't
>> really feel qualified for a proper review), but it is indeed the
>> existence of the two interfaces living in par
On Sat, Apr 2, 2016 at 7:55 PM, Roland Scheidegger wrote:
> I don't really have anything against the new interface (though don't
> really feel qualified for a proper review), but it is indeed the
> existence of the two interfaces living in parallel seemingly doing
> mostly the same which bothers m
I don't really have anything against the new interface (though don't
really feel qualified for a proper review), but it is indeed the
existence of the two interfaces living in parallel seemingly doing
mostly the same which bothers me. To make things worse, the per context
fence_finish is even calle
I did toy with the idea of adding a
DONT_REALLY_FLUSH_JUST_CREATE_A_FENCE flag to existing pctx->flush()..
I'm not really sure I could call that better. And either way, we want
the ctx ptr in fence_finish(), otherwise we are hiding the ctx ptr
internally in the driver's pipe_fence struct so that i
I'll admit I'm not an expert on this but I got a bad feeling on it.
Do you really need another per-context fence_finish function?
This looks to me like rather than improving the existing api, it throws
another one at the same problem, which is to be sort of used in parallel
making things confusing
From: Rob Clark
Since current thing is kinda horrible for tilers. And that issue will
be even worse with EGL_ANDROID_native_fence_sync.
Not wired up yet for gl syncobj, which can come later. For now we just
need this with EGL.
Signed-off-by: Rob Clark
---
src/gallium/include/pipe/p_context.
14 matches
Mail list logo
