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
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
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
> 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
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
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
> 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
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
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
> 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
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
