oes this seem like something worth pursuing to others? I've been trying
> to decide how to best move the allocation constraints efforts forward,
> so it's potentially something I could put some time into this year.
It's a fairly interesting idea I hadn't thought of.
My limited experience with all the graphics protocols and their history
means I have had limited exposure to the pain that communicating
modifiers everywhere has generated. As a result, I would have (perhaps
naively) tried to design a new mechanism. Using modifiers as a transport
mechanism is clearly a hack, but it may be a clever one. It seems worth
experimenting with it at least.
After reading the whole thread, I however wonder if this will be
backward compatible. If two devices expose a constraint that ends up
being encoded in the same binary form in a modifier (let's say for
instance the same pitch alignment), isn't there a risk that an
application not aware of this new scheme will pick that common modifier
when intersecting the modifiers list as done today, without realizing
it's not a real modifier ?
--
Regards,
Laurent Pinchart
agree with your concern in general, AFAIK there's no other
> solution for this even on the horizon, after years of talking about
> it. The solution proposed here seems like an acceptable stop gap,
> assuming it won't result in a gazillion linear modifiers.
Flipping that argument, the reason why we still have no solution is
because we've constantly accepted stop-gap measures. Maybe it's time to
stop. It may feel a bit unfair to Marek that everybody until know got
away with hacks, but I don't think he would be left alone designing a
proper solution.
--
Regards,
Laurent Pinchart
t
that to be the majority case, but I can't rule it out either. There's
also the issue that, even if the devices support configurable pitches,
the drivers may not implement it. That's fixable, but hardcoding the
pitch to 256 bytes without fixing that would be a regression.
--
Regards,
Laurent Pinchart
I know for sure of one other person falling
> for the same.
Make that two. Thanks for the notice.
> Now, the members page for this year says "Application for the period:
> 02/2024-02/2025". Thanks to the people adding the month to reduce
> confusion.
--
Regards,
Laurent Pinchart
the
> > upcoming election is 26 March 2023 at 23:59 UTC.
> >
> > If you are interested in joining the X.Org Foundation or in renewing
> > your membership, please visit the membership system site at:
> > https://members.x.org/
> >
> > Ricardo Garcia, on behalf of the X.Org elections committee
--
Regards,
Laurent Pinchart
Hi Jason,
On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> >> (I know I'm going to be spammed by so many mailing list ...)
> &
rantee on the order in which
buffers will be used. I'm aware this wouldn't be compatible with
explicit synchronization, and that's my point: camera hardware may not
always support explicit synchronization. As long as we can fall back to
not using fences then we should be fine.
--
Regards,
Laurent Pinchart
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
ould like to break things apart. Towards that end, I have
> > > an actual proposal.
> > >
> > > A couple weeks ago, I sent a series of patches to the dri-devel
> > > mailing list which adds a pair of new ioctls to dma-buf which allow
> > &
t the microconference, please feel
free to contact us. Looking forward to seeing everyone in New Orleans.
--
Thanks in advance,
Jesse Barker (jesse 'dot' barker 'at' arm 'dot' com)
Laurent Pinchart (laurent 'dot' pinchart 'at' ideasonboard 'dot
