search for: is_sign

...s=c,c++ --disable-multilib when I run: $ make I get the following errors: /home/draikes/src/llvm/include/llvm/ADT/StringRef.h:346:19: error: â EURO ~enable_ifâ EURO (tm) in namespace â EURO ~stdâ EURO (tm) does not name a template type typename std::enable_if<std::numeric_limits<T>::is_signed, bool>::type ^ /home/draikes/src/llvm/include/llvm/ADT/StringRef.h:346:28: error: expected unqualified-id before â EURO ~<â EURO (tm) token typename std::enable_if<std::numeric_limits<T>::is_signed, bool>::type ^ /home/draikes/...

...to use the sigset_t type in all places where it should, using "int" some places instead. Here is a diff of the needed corrections: @@ -253,7 +253,7 @@ sighandler_t signal(int signal_Number, sighandler_t signal_Handler) int sigaddset(sigset_t* sigset_Info,int signal_Number) { if (IS_SIGNAL(signal_Number)) { - (*sigset_Info) |= (1 << (signal_Number - 1)); + (*sigset_Info) |= ((sigset_t)1 << (signal_Number - 1)); return 0; } else { @@ -267,7 +267,7 @@ int sigaddset(sigset_t* sigset_Info,int signal_Number) int sigdelset(sigset_t* sigset_Info,...

...not atomic context. >>> >>> If a driver needs to avoid blocking it should just use a workqueue and checking a fence outside your own driver is probably be better done in a bottom halve handler anyway. >> >> Except that you might want to do something like >> fence_is_signaled() in another driver to check whether you need to >> defer, or can submit the batch buffer immediately, saving a bunch of >> context switches. Running the is_signaled atomic is really useful here >> because it means you can't do too many scary things in your is_signaled &gt...

...gt; atomic context. >> >> If a driver needs to avoid blocking it should just use a workqueue >> and checking a fence outside your own driver is probably be better >> done in a bottom halve handler anyway. > > Except that you might want to do something like > fence_is_signaled() in another driver to check whether you need to > defer, or can submit the batch buffer immediately, saving a bunch of > context switches. Running the is_signaled atomic is really useful here > because it means you can't do too many scary things in your is_signaled > handler....

...ush. I get it that it doesn't apply to radeon and nouveau, but for other drivers that could be necessary, like vmwgfx. Ironically that is also a part of the ttm fence, except it was called flush there. I would also like to note that ttm_bo_wait currently is also a function that currently uses is_signaled from atomic_context... For the more complicated locking worries: Lockdep is your friend, use PROVE_LOCKING and find bugs before they trigger. ;-) >> Like I've said I think restricting the insanity other people are willing >> to live with just because you don't like it isn&...

...up to a second is not really desirable also. > I've checked the code a little but that can be the case now as well. > the new implementation's __radeon_fence_wait will be protected by the > exclusive_lock,, but enable_signaling is only protected by the > fence_queue.lock and is_signaled is not protected. But this is not a > change from the current situation, so it would only become a problem > if the gpu hangs in a cross-device situation. > > I think adding 1 to the irq refcount in the reset sequence and adding > a down_read_trylock on the exclusive lock woul...

...on a lock for up to a second is not really desirable also. >> I've checked the code a little but that can be the case now as well. the new implementation's __radeon_fence_wait will be protected by the exclusive_lock,, but enable_signaling is only protected by the fence_queue.lock and is_signaled is not protected. But this is not a change from the current situation, so it would only become a problem if the gpu hangs in a cross-device situation. >> >> I think adding 1 to the irq refcount in the reset sequence and adding a down_read_trylock on the exclusive lock would help. If...

...ush again and make it optional like in TTM. You've posted a lot of concerns, but I haven't seen you come up with any scenario that could create a lockup and lockdep wouldn't warn about. >> I would also like to note that ttm_bo_wait currently is also a function that currently uses is_signaled from atomic_context... > > I know, but TTM is only called from inside a single driver, no inter driver needs here. We currently even call the internal fence implementation from interrupt context as well and at more than one occasion assume that TTM only uses radeon fences. This is no long...

...example of locking inversion. In the preliminary patches where I can sync radeon with other GPU's I've been very careful in all the places that call into fences, to make sure that radeon wouldn't try to handle lockups for a different (possibly also radeon) card. This is also why fence_is_signaled should never block, and why it trylocks the exclusive_lock. :-) I think lockdep would complain if I grabbed exclusive_lock while blocking in is_signaled. >> So from the core fence framework I think we already have exactly this, >> and we only need to adjust the radeon implementatio...

...er drivers that could be necessary, like vmwgfx. > > Ironically that is also a part of the ttm fence, except it was called flush there. Then call it flush again and make it optional like in TTM. > I would also like to note that ttm_bo_wait currently is also a function that currently uses is_signaled from atomic_context... I know, but TTM is only called from inside a single driver, no inter driver needs here. We currently even call the internal fence implementation from interrupt context as well and at more than one occasion assume that TTM only uses radeon fences. Christian. > For...

...spinning on a lock for up to a second is not really desirable also. I've checked the code a little but that can be the case now as well. the new implementation's __radeon_fence_wait will be protected by the exclusive_lock,, but enable_signaling is only protected by the fence_queue.lock and is_signaled is not protected. But this is not a change from the current situation, so it would only become a problem if the gpu hangs in a cross-device situation. I think adding 1 to the irq refcount in the reset sequence and adding a down_read_trylock on the exclusive lock would help. If the trylock fail...

Am 15.05.2014 17:58, schrieb Maarten Lankhorst: > op 15-05-14 17:48, Christian K?nig schreef: >> Am 15.05.2014 16:18, schrieb Maarten Lankhorst: >>> op 15-05-14 15:19, Christian K?nig schreef: >>>> Am 15.05.2014 15:04, schrieb Maarten Lankhorst: >>>>> op 15-05-14 11:42, Christian K?nig schreef: >>>>>> Am 15.05.2014 11:38, schrieb

...not such a good idea. In case of a lockup we need to handle the lockup cause otherwise it could happen that radeon waits for the lockup to be resolved and the lockup handling needs to wait for a fence that's never signaled because of the lockup. Christian. > > This is also why fence_is_signaled should never block, and why it trylocks the exclusive_lock. :-) I think lockdep would complain if I grabbed exclusive_lock while blocking in is_signaled. > >>> So from the core fence framework I think we already have exactly this, >>> and we only need to adjust the radeon i...

Am 22.07.2014 17:42, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >> Drivers exporting fences need to provide a fence->signaled and a fence->wait >> function, everything else like fence->enable_signaling or calling >> fence_signaled() from the driver is optional. >> >> Drivers

...a driver needs to avoid blocking it should just use a workqueue >>>> and checking a fence outside your own driver is probably be better >>>> done in a bottom halve handler anyway. >>> >>> Except that you might want to do something like >>> fence_is_signaled() in another driver to check whether you need to >>> defer, or can submit the batch buffer immediately, saving a bunch of >>> context switches. Running the is_signaled atomic is really useful here >>> because it means you can't do too many scary things in your is_...

On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote: > Am 22.07.2014 13:57, schrieb Daniel Vetter: > >On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: > >>On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote: > >>>Am 22.07.2014 06:05, schrieb Dave Airlie: > >>>>On 9 July 2014 22:29, Maarten Lankhorst