Probably nv30 would do well to "move on" as well. But it also presents
an interesting question -- the nv30 driver has lots of problems. I
have no plans to fix them, nor am I aware of anyone else with such
plans. However if such a developer were to turn up, would it be
reasonable to assume that
Hi Jordan,
https://cgit.freedesktop.org/piglit
This still displays the "master" branch by default. I think you're
supposed to change ... something ... in the repo, which indicates
which is the default branch.
Cheers,
-ilia
On Mon, Mar 29, 2021 at 8:31 PM Jordan Justen wrote:
>
> On
On Tue, 30 Mar 2021 at 01:34, Ilia Mirkin wrote:
> https://cgit.freedesktop.org/piglit
>
> This still displays the "master" branch by default. I think you're
> supposed to change ... something ... in the repo, which indicates
> which is the default branch.
>
*jedi handwave* no it doesn't
> On
On Mon, Mar 29, 2021 at 5:59 PM Ilia Mirkin wrote:
>
> Probably nv30 would do well to "move on" as well. But it also presents
> an interesting question -- the nv30 driver has lots of problems. I
> have no plans to fix them, nor am I aware of anyone else with such
> plans. However if such a
Alright that's r300 and swr that are going to find a new home in the lts
branch. Do any other gallium drivers want to join them?
Marek
On Mon., Mar. 29, 2021, 13:51 Zielinski, Jan,
wrote:
> On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
> > Same thinking could be applied to other gallium
I'm considering freedreno a2xx, although that is not a separate build
option from meson PoV.. I'd welcome arguments one way or another from
any stakeholder
(we also have a bit of a CI gap for a4xx.. although other than the
usual "shuffle all the registers/bitfields around" that we see between
On 2021-03-24 23:47:46, Jordan Justen wrote:
> On 2021-03-24 21:14:57, Jason Ekstrand wrote:
> >
> > Jordan, is there any way you can make the script sort by last updated
> > before it
> > re-targets the MRs so they at least stay in the same order? Updating them
> > in MR
> > # order wouldn't
I've brought this up in the past, but I have some patches implementing
it now, so I was hoping to get some further feedback on the idea of
supporting GBM backends external to Mesa.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902
From my reading, the GBM core code was intended
On Thursday, March 25, 2021 8:47 Marek Olšák wrote:
> Same thinking could be applied to other gallium drivers for old hardware that
> don't receive new development and are becoming more and more irrelevant every
> year due to their age.
Can we also keep Gallium for OpenSWR driver on -lts
