> By far the limiting factor for i915g progress now that I've got some
> CI rigged up is review. My preference would be that we all agree that
> nobody wants to look at i915, and some responsible folks (ajax and a
> couple Intel volunteers, perhaps?) bless me to merge without review
> once an i915
Why not proceed with splitting the classic drivers including i965 as
was discussed previously?
Then, when you feel that crocus and i915g are ready to be default, you
can simply delete i965 from the classic branch and tell users they can
use mesa main once again.
On Tue, 2021-06-15 at 20:03 -0500,
On Tue, Jun 15, 2021 at 8:16 PM Jason Ekstrand wrote:
>
> On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri wrote:
> >
> > On 6/16/21 11:03 AM, Jason Ekstrand wrote:
> >
> > I'm bringing this up via e-mail so it gets a wider audience. Given how will
> > crocus is working at this point, is like to p
On 6/16/21 1:16 PM, Jason Ekstrand wrote:
On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri wrote:
On 6/16/21 11:03 AM, Jason Ekstrand wrote:
I'm bringing this up via e-mail so it gets a wider audience. Given how will
crocus is working at this point, is like to propose we hold off for about thr
On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri wrote:
>
> On 6/16/21 11:03 AM, Jason Ekstrand wrote:
>
> I'm bringing this up via e-mail so it gets a wider audience. Given how will
> crocus is working at this point, is like to propose we hold off for about
> three more releases before we drop cl
On 6/16/21 11:03 AM, Jason Ekstrand wrote:
I'm bringing this up via e-mail so it gets a wider audience. Given how
will crocus is working at this point, is like to propose we hold off
for about three more releases before we drop classic. This next
release, 21.2, we'll have crocus as an option w
I'm bringing this up via e-mail so it gets a wider audience. Given how will
crocus is working at this point, is like to propose we hold off for about
three more releases before we drop classic. This next release, 21.2, we'll
have crocus as an option with i965 as the default. There will also be a
Quoting Dylan Baker (2021-03-22 15:15:30)
> Hi list,
>
> We've talked about it a number of times, but I think it's time time to
> discuss splitting the classic drivers off of the main development branch
> again, although this time I have a concrete plan for how this would
> work.
>
> First, why?
Another thing is that glsl_to_tgsi is going to be removed but an old driver
may want to keep it. For this case, glsl_to_tgsi will be preserved in the
lts branch.
Marek
On Mon., Mar. 29, 2021, 18:59 Ilia Mirkin, wrote:
> Probably nv30 would do well to "move on" as well. But it also presents
> an
On 3/25/21 3:13 PM, Jason Ekstrand wrote:
> On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke wrote:
>>
>> On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
>>> On 3/25/21 10:49 AM, Jason Ekstrand wrote:
>>> Can you be more specific? Also, is there a reason why that work can't
>>> or sh
> 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
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
gens
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 develop
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 thei
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 d
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 branch?
On Thu, Mar 25, 2021 at 2:12 PM Kenneth Graunke wrote:
>
> On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote:
> > Other than the minor detail that we don't have pci-id's to
> > differentiate between adreno generations, I might suggest a2xx users
> > to use -lts
> >
> > BR,
> > -R
>
> Cou
On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke wrote:
>
> On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> > On 3/25/21 10:49 AM, Jason Ekstrand wrote:
> > Can you be more specific? Also, is there a reason why that work can't
> > or shouldn't be done directly in the LTS branch? A
On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> On 3/25/21 10:49 AM, Jason Ekstrand wrote:
[snip]
> > I'm not sure we want to totally declare those drivers dead. People can
> > still do feature or enhancement development of they want to, it just
> > happens in a different branch.
>
On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote:
> Other than the minor detail that we don't have pci-id's to
> differentiate between adreno generations, I might suggest a2xx users
> to use -lts
>
> BR,
> -R
Could it be set up such that freedreno in mainline fails to load on
a2xx (and
On 3/25/21 10:49 AM, Jason Ekstrand wrote:
> Can you be more specific? Also, is there a reason why that work can't
> or shouldn't be done directly in the LTS branch? As Ken pointed out,
The bulk of things that I had going were to enable some extensions and
make those extensions non-optional. ARB
On Thu., Mar. 25, 2021, 12:14 Dylan Baker, wrote:
> By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from
> Meson. Maybe it makes sense to keep gallium for r300? But how many r300
> breakages have we had in recent memory?
>
We don't have any recent information on the status of r3
Can you be more specific? Also, is there a reason why that work can't
or shouldn't be done directly in the LTS branch? As Ken pointed out,
I'm not sure we want to totally declare those drivers dead. People can
still do feature or enhancement development of they want to, it just
happens in a differ
Other than the minor detail that we don't have pci-id's to
differentiate between adreno generations, I might suggest a2xx users
to use -lts
BR,
-R
On Thu, Mar 25, 2021 at 9:14 AM Dylan Baker wrote:
>
> By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from Meson.
> Maybe it makes
By delete I mean "remove -Dgallium-drivers and -Dvulkan-drivers" from Meson.
Maybe it makes sense to keep gallium for r300? But how many r300 breakages have
we had in recent memory?
On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote:
> On Wed, Mar 24, 2021 at 10:28 AM Rob Clark wrote:
> >
> >
Maybe I could have been clearer, but I meant "We only guarantee that we'll keep
the build working and that major security problems get fixed", If you or
someone else wants to fix other issues that's fine, but I meant if someone says
"i915c is too slow for some workload", we reserve the right to
On Wed, Mar 24, 2021 at 10:28 AM Rob Clark wrote:
>
> On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker wrote:
> >
> > Hi list,
> >
> > We've talked about it a number of times, but I think it's time time to
> > discuss splitting the classic drivers off of the main development branch
> > again, although
On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker wrote:
>
> Hi list,
>
> We've talked about it a number of times, but I think it's time time to
> discuss splitting the classic drivers off of the main development branch
> again, although this time I have a concrete plan for how this would
> work.
>
> Fi
> And, yeah, I'd love to drop vec4 but yeah... One advantage to keeping
> vec4 in the tree for some stuff is that it means we have full-featured
> hardware able to test vec4 NIR. That seems like a feature.
I have to keep caring about Midgard for the next indefinitely so please
don't break vec4 N
+1
We still have some CPU overhead performance targets we haven't reached. One
of them is to decrease CPU overhead for one benchmark 4 times compared to
everything we already have in master. I don't know how we are going to do
that, but we'll try.
Marek
On Mon, Mar 22, 2021 at 6:15 PM Dylan Bake
On Tue, Mar 23, 2021 at 8:39 AM Kenneth Graunke wrote:
>
> On Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote:
> > On March 23, 2021 01:46:54 Kenneth Graunke wrote:
> [snip]
> > > One extra thought: can we also fork off anv Gen7.x support at the same
> > > time? If distros are alread
On 3/23/21 7:26 PM, Ian Romanick wrote:
I would like to wait a couple more releases to do this. I have a couple
things that I've been gradually working on for some of the non-i965
classic drivers that I'd like to land before they're put out to pasture.
I talked to ajax about this a few weeks
On Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote:
> On March 23, 2021 01:46:54 Kenneth Graunke wrote:
[snip]
> > One extra thought: can we also fork off anv Gen7.x support at the same
> > time? If distros are already going to be building i965 for Gen7.x from
> > that branch, buildin
On March 23, 2021 01:46:54 Kenneth Graunke wrote:
On Monday, March 22, 2021 3:15:30 PM PDT Dylan Baker wrote:
Hi list,
We've talked about it a number of times, but I think it's time time to
discuss splitting the classic drivers off of the main development branch
again, although this time I ha
I'd like to see it happen, though I don't understand how to make these
coexist for distros. Would like to hear from the Debian/etc maintainers
of mesa.
Then again I *think* classic-lts doesn't need to be built for
armhf/arm64 at all, so I suppose I'm personally unaffected :-P
On Mon, Mar 22, 2021
I would like to wait a couple more releases to do this. I have a couple
things that I've been gradually working on for some of the non-i965
classic drivers that I'd like to land before they're put out to pasture.
I talked to ajax about this a few weeks ago, and he was amenable at the
time.
I can
On Monday, March 22, 2021 3:15:30 PM PDT Dylan Baker wrote:
> Hi list,
>
> We've talked about it a number of times, but I think it's time time to
> discuss splitting the classic drivers off of the main development branch
> again, although this time I have a concrete plan for how this would
> work.
+1. I'd we think GLVND and X are ready for this, I think it's a good plan.
On March 22, 2021 17:34:09 Eric Anholt wrote:
On Mon, Mar 22, 2021 at 3:27 PM Dylan Baker wrote:
Hi list,
We've talked about it a number of times, but I think it's time time to
discuss splitting the classic drivers
On Mon, Mar 22, 2021 at 3:27 PM Dylan Baker wrote:
>
> Hi list,
>
> We've talked about it a number of times, but I think it's time time to
> discuss splitting the classic drivers off of the main development branch
> again, although this time I have a concrete plan for how this would
> work.
>
> Fi
Hi list,
We've talked about it a number of times, but I think it's time time to
discuss splitting the classic drivers off of the main development branch
again, although this time I have a concrete plan for how this would
work.
First, why? Basically, all of the classic drivers are in maintanence
m
40 matches
Mail list logo
