On Mon, Feb 4, 2019 at 6:43 PM Ilia Mirkin wrote:
> On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand
> wrote:
> >
> > On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig
> wrote:
> >>
> >> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> >> > far as I understand) basically be
Thanks :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand wrote:
>
> On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig wrote:
>>
>> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
>> > far as I understand) basically be owning the panfrost bits in mesa,
>> > you should be able to commit
On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig
wrote:
> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> > far as I understand) basically be owning the panfrost bits in mesa,
> > you should be able to commit to them.
>
> Oh, thank you! :)
>
> > 1. Don't break the build
> Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> far as I understand) basically be owning the panfrost bits in mesa,
> you should be able to commit to them.
Oh, thank you! :)
> 1. Don't break the build
Acked-by: Alyssa Rosenzweig
> 2. No merge commits
Just to be cle
On Mon, Feb 4, 2019 at 3:13 PM Rob Herring wrote:
> On Sun, Feb 3, 2019 at 9:33 PM Alyssa Rosenzweig
> wrote:
> >
> > > You should just land it and start doing in-tree development!
> >
> > I don't have push access, you know :P
>
> I can push it if you don't want to go the MR route. That goes for
On Sun, Feb 3, 2019 at 9:33 PM Alyssa Rosenzweig wrote:
>
> > You should just land it and start doing in-tree development!
>
> I don't have push access, you know :P
I can push it if you don't want to go the MR route. That goes for
subsequent changes too.
Rob
_
On February 3, 2019 21:33:39 Alyssa Rosenzweig wrote:
You should just land it and start doing in-tree development!
I don't have push access, you know :P
Make a MR with all the acks on it and I'll click the button. I say MR
because the full patch would be huge.
--Jason
__
> You should just land it and start doing in-tree development!
I don't have push access, you know :P
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sun, Feb 3, 2019 at 6:18 PM Alyssa Rosenzweig
wrote:
> > Small comment, you should plan on single build for all supported
> > generations.. I'm not entirely sure if this same header is eventually
> > planned to be #include'd from different C code w/ different defines
> > for gpu gen (afaict yo
> Small comment, you should plan on single build for all supported
> generations.. I'm not entirely sure if this same header is eventually
> planned to be #include'd from different C code w/ different defines
> for gpu gen (afaict you just currently hard-code it at the top of this
> header).. But
> Doing merge commits for new drivers is not unheard of and preserves
> history (if the history is something you want to preserve).
The history downstream is a total mess (read: probably not bisectable),
and a lot of it was committed sloppily knowing it would get squished. So
thank you for offerin
On Wed, Jan 30, 2019 at 12:43 AM Alyssa Rosenzweig wrote:
>
> This patch adds an initial stub for the Gallium driver, containing
> simple screen functions and the majority of the driver headers but no
> actual functionality. It further adds the winsys glue for linking in
> this stub driver via kms
On Thu, Jan 31, 2019 at 10:36 AM Eric Anholt wrote:
> Alyssa Rosenzweig writes:
>
> >> There's u_pipe_screen_get_param_defaults() that you really want to be
> >> using to avoid regressions when people add new pipe caps. You can get
> >> rid of a lot of your switch statement that way, too.
> >
>
Alyssa Rosenzweig writes:
>> There's u_pipe_screen_get_param_defaults() that you really want to be
>> using to avoid regressions when people add new pipe caps. You can get
>> rid of a lot of your switch statement that way, too.
>
> Oh, good to know. Is that newer? I'm pretty sure that whole bloc
> There's u_pipe_screen_get_param_defaults() that you really want to be
> using to avoid regressions when people add new pipe caps. You can get
> rid of a lot of your switch statement that way, too.
Oh, good to know. Is that newer? I'm pretty sure that whole block was
copied from vc4 at some poin
Alyssa Rosenzweig writes:
> This patch adds an initial stub for the Gallium driver, containing
> simple screen functions and the majority of the driver headers but no
> actual functionality. It further adds the winsys glue for linking in
> this stub driver via kmsro on Rockchip/Amlogic boards.
>
17 matches
Mail list logo
