Luca Barbieri <l...@luca-barbieri.com> writes: >> Sounds like premature optimization to me. I'm just stating my personal >> view here, but I have a feeling a patch with 60% of lines could do very >> well the same for most realistic cases. > > Perhaps, but really, the only thing you would probably save by using > spinlocks in the fast path is retrying in nouveau_sem_alloc, which > should be at most 10 lines saved. > You'd also save some bookkeeping and the double error checking.
> You could save much more by supporting only a single static semaphore > BO, and still retain almost all flexibility by making it large. > However, it's somewhat inelegant, and why not just keep the > functionality so we never need to revisit this again? Yup, I'm fine with having several semaphore BOs. > >> BTW, the kernel has some linked list helpers you might want to use for >> sem_bo_free_list > It is a singly linked list, and slist.h never got merged. > I could possibly make it doubly linked, even though it's a bit useless. > >> and probably the best place for the sem stuff to live >> is "dev_priv->fence" instead of the root of drm_nouveau_private. > There is no "fence" currently in drm_nouveau_private. > Adding a "sem" or "fence" substructure could make sense though. Yes, that would make sense.
pgpI03p35ZWqr.pgp
Description: PGP signature
_______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau