Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Timothy Arceri]

On 4/12/19 3:45 pm, Jason Ekstrand wrote:
On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie > wrote:


On Wed, 4 Dec 2019 at 10:39, Marek Olšák mailto:mar...@gmail.com>> wrote:
 >
 > Hi,
 >
 > Here are 2 proposals to simplify and better optimize the
GL->Gallium translation.
 >
 > 1) Move classic drivers to a fork of Mesa, and remove them from
master. Classic drivers won't share any code with master. glvnd will
load them, but glvnd is not ready for this yet.


I'm usually the first person to tell people to stop mucking about with 
old hardware and I fear even I think this would be a bit premature.  
We've not turned iris on by default yet and I'd really like it to bake 
as the default distro driver for a while (maybe a year) before we put 
i965 on life-support.  If we were having this discussion in another 
year's time, I might be in favor of this but, as it currently stands, 
I'm not sure this is a good idea.


 > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/
can be the target location.


I really don't like this option.  For one thing, this means two copies 
of code that will get out-of-sync.  If we had the classic drivers in 
their own branch, we could at least cherry-pick bugfixes back to the 
classic branch.  However, if we have two copies of everything, our 
version control tool can't help us.


The bigger problem is headers.  Currently, the GLSL compiler includes 
mtypes.h so we would need to somehow separate the GLSL compiler out from 
src/mesa/main because we'll have two mtypes.h files.  Unfortunately, 
GLSL isn't the only thing that includes stuff from src/mesa/main.  Our 
header situation has been a disaster for years and I'm afraid it hasn't 
gotten any better with the addition of src/util.  Most people who move 
stuff don't actually do due diligence to keep the includes clean and the 
result is that I'm pretty sure even the Vulkan drivers are including 
src/mesa/main/imports.h.  If we have two copies of src/mesa/main and the 
headers begin to diverge, it's going to be a total disaster.  I would 
love to see someone clean this all up properly and I think Mesa would be 
better for it.  However, it is a LOT of work.


If we did the above cleaning, would I be ok with this approach?  
Possibly.  However, I suspect it'd end up being the worst of both 
worlds.  We still have maintenance of effectively two branches and 
bugfixes have to be ported.  At the same time, we'd still have core 
changes to things like the GLSL compiler breaking old drivers so we 
wouldn't lighten any of the maintenance burden.


 > Option 2 is more acceptable to people who want to keep classic
drivers in the tree and it can be done right now.

These both seem pretty horrible to me right now. Like i965 still
supports a lot of hardware that exists right now even if we move to
iris.


I'm less concerned about the support burden.  When it comes to bugfixes, 
I feel like most of the bugs on gen7 and earlier hardware at this point 
are due to churn in the core and if it lives in a maintenance branch, 
we'll stop breaking it.  The biggest thing we'd loose would be 
additional features that we might get thanks to core changes.  The major 
ones that come to mind are:


  - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we 
haven't due to a lack of testing) >   - GL_EXT_direct_state_access (still underway last I knew)


Is already done and enabled for compat profile.


  - GL_EXT_gpu_shader4


Core mesa parts are done for this also.


  - Compat context support


radeonsi, nouveau and iris all fully enable this. At this point its just 
a driver/classic issue to add support. So as with the two other features 
above options 1 or 2 will not change the fate of this support.




All four of those are more-or-less software-only features that older 
intel drivers could pick up as the core advances.  Compat support likely 
requires a bit of driver work but it should be doable.


The real question is, "How much do we care?"  I can't say I like the 
idea of leaving Gen4-7 out in the cold.  Again, in a year's time, we 
might have most of the above implemented and then it'd be less of a concern.


As per above its only GL_ARB_gl_spirv that would maybe be impacted by 
any fork, but that doesn't change between now and a year so delaying a 
decision for a year based on this is doesn't seem necessary.




I sorta feel there should be a
3) make life harder for classic drivers and optimise things more for
gallium add more dd.h entrypoints, force the classic drivers to jump
through hoops to degallium.


I'd be interested to see what that would look like.  I'm not actually 
convinced that it would work if I'm honest.  Part of gluing them 
together in my mind is deleting dd.h enti

Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate change in encoder

[Zhang, Boyuan]

Patch is
Reviewed-by: Boyuan Zhang mailto:boyuan.zh...@amd.com>>

Regards,
Boyuan

From: Liu, Leo 
Sent: December 3, 2019 9:08 PM
To: Marek Olšák ; Sahu, Satyajit ; 
Zhang, Boyuan 
Cc: ML Mesa-dev ; Sharma, Deepak 

Subject: Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate 
change in encoder

+Boyuan

From: Marek Olšák mailto:mar...@gmail.com>>
Sent: December 3, 2019 7:21:23 PM
To: Sahu, Satyajit mailto:satyajit.s...@amd.com>>; Liu, 
Leo mailto:leo@amd.com>>
Cc: ML Mesa-dev 
mailto:mesa-dev@lists.freedesktop.org>>; 
Sharma, Deepak mailto:deepak.sha...@amd.com>>
Subject: Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate 
change in encoder

+Leo

On Mon, Dec 2, 2019 at 11:31 PM Satyajit Sahu 
mailto:satyajit.s...@amd.com>> wrote:
Added support for bitrate change in between encoding.

Signed-off-by: Satyajit Sahu 
mailto:satyajit.s...@amd.com>>

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 84d3c1e2fa4..7d7a2fa4eb3 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -268,7 +268,8 @@ static void rvce_begin_frame(struct pipe_video_codec 
*encoder,
enc->pic.rate_ctrl.rate_ctrl_method != 
pic->rate_ctrl.rate_ctrl_method ||
enc->pic.quant_i_frames != pic->quant_i_frames ||
enc->pic.quant_p_frames != pic->quant_p_frames ||
-   enc->pic.quant_b_frames != pic->quant_b_frames;
+   enc->pic.quant_b_frames != pic->quant_b_frames ||
+   enc->pic.rate_ctrl.target_bitrate != 
pic->rate_ctrl.target_bitrate;

enc->pic = *pic;
si_get_pic_param(enc, pic);
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index aa9182f273b..c4fb9a7bd92 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -247,6 +247,17 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,
 {
struct radeon_encoder *enc = (struct radeon_encoder*)encoder;
struct vl_video_buffer *vid_buf = (struct vl_video_buffer *)source;
+   bool need_rate_control = false;
+
+   if (u_reduce_video_profile(enc->base.profile) == 
PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+   struct pipe_h264_enc_picture_desc *pic = (struct 
pipe_h264_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rate_ctrl.target_bitrate;
+   } else if (u_reduce_video_profile(picture->profile) == 
PIPE_VIDEO_FORMAT_HEVC) {
+struct pipe_h265_enc_picture_desc *pic = (struct 
pipe_h265_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rc.target_bitrate;
+   }

radeon_vcn_enc_get_param(enc, picture);

@@ -266,6 +277,10 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,
flush(enc);
si_vid_destroy_buffer(&fb);
}
+   if (need_rate_control) {
+   enc->begin(enc, picture);
+   flush(enc);
+   }
 }

 static void radeon_enc_encode_bitstream(struct pipe_video_codec *encoder,
--
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate change in encoder

[Sharma, Deepak]

[AMD Official Use Only - Internal Distribution Only]

Acked-by: Deepak Sharma 

-Original Message-
From: Sahu, Satyajit  
Sent: Monday, December 2, 2019 8:31 PM
To: mesa-dev@lists.freedesktop.org
Cc: Zhang, Boyuan ; Sharma, Deepak 
; Sahu, Satyajit 
Subject: [PATCH] radeonsi: Add support for midstream bitrate change in encoder

Added support for bitrate change in between encoding.

Signed-off-by: Satyajit Sahu 

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 84d3c1e2fa4..7d7a2fa4eb3 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -268,7 +268,8 @@ static void rvce_begin_frame(struct pipe_video_codec 
*encoder,
enc->pic.rate_ctrl.rate_ctrl_method != 
pic->rate_ctrl.rate_ctrl_method ||
enc->pic.quant_i_frames != pic->quant_i_frames ||
enc->pic.quant_p_frames != pic->quant_p_frames ||
-   enc->pic.quant_b_frames != pic->quant_b_frames;
+   enc->pic.quant_b_frames != pic->quant_b_frames ||
+   enc->pic.rate_ctrl.target_bitrate != 
pic->rate_ctrl.target_bitrate;
 
enc->pic = *pic;
si_get_pic_param(enc, pic);
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index aa9182f273b..c4fb9a7bd92 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -247,6 +247,17 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,  {
struct radeon_encoder *enc = (struct radeon_encoder*)encoder;
struct vl_video_buffer *vid_buf = (struct vl_video_buffer *)source;
+   bool need_rate_control = false;
+
+   if (u_reduce_video_profile(enc->base.profile) == 
PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+   struct pipe_h264_enc_picture_desc *pic = (struct 
pipe_h264_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rate_ctrl.target_bitrate;
+   } else if (u_reduce_video_profile(picture->profile) == 
PIPE_VIDEO_FORMAT_HEVC) {
+struct pipe_h265_enc_picture_desc *pic = (struct 
pipe_h265_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rc.target_bitrate;
+   }
 
radeon_vcn_enc_get_param(enc, picture);
 
@@ -266,6 +277,10 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,
flush(enc);
si_vid_destroy_buffer(&fb);
}
+   if (need_rate_control) {
+   enc->begin(enc, picture);
+   flush(enc);
+   }
 }
 
 static void radeon_enc_encode_bitstream(struct pipe_video_codec *encoder,
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dylan Baker]

Quoting Jason Ekstrand (2019-12-03 20:45:33)
> On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie  wrote:
> 
> On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will load them, 
> but
> glvnd is not ready for this yet.
> 
> 
> I'm usually the first person to tell people to stop mucking about with old
> hardware and I fear even I think this would be a bit premature.  We've not
> turned iris on by default yet and I'd really like it to bake as the default
> distro driver for a while (maybe a year) before we put i965 on life-support. 
> If we were having this discussion in another year's time, I might be in favor
> of this but, as it currently stands, I'm not sure this is a good idea.
>  
> 
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/
> main, mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
> location.
> 
> 
> I really don't like this option.  For one thing, this means two copies of code
> that will get out-of-sync.  If we had the classic drivers in their own branch,
> we could at least cherry-pick bugfixes back to the classic branch.  However, 
> if
> we have two copies of everything, our version control tool can't help us.
> 
> The bigger problem is headers.  Currently, the GLSL compiler includes mtypes.h
> so we would need to somehow separate the GLSL compiler out from src/mesa/main
> because we'll have two mtypes.h files.  Unfortunately, GLSL isn't the only
> thing that includes stuff from src/mesa/main.  Our header situation has been a
> disaster for years and I'm afraid it hasn't gotten any better with the 
> addition
> of src/util.  Most people who move stuff don't actually do due diligence to
> keep the includes clean and the result is that I'm pretty sure even the Vulkan
> drivers are including src/mesa/main/imports.h.  If we have two copies of src/
> mesa/main and the headers begin to diverge, it's going to be a total 
> disaster. 
> I would love to see someone clean this all up properly and I think Mesa would
> be better for it.  However, it is a LOT of work.

I have an MR that's been sitting on the list for over a year that remove
imports.h completely. I can rebase that today.

> 
> If we did the above cleaning, would I be ok with this approach?  Possibly. 
> However, I suspect it'd end up being the worst of both worlds.  We still have
> maintenance of effectively two branches and bugfixes have to be ported.  At 
> the
> same time, we'd still have core changes to things like the GLSL compiler
> breaking old drivers so we wouldn't lighten any of the maintenance burden.
>  
> 
> > Option 2 is more acceptable to people who want to keep classic drivers 
> in
> the tree and it can be done right now.
> 
> These both seem pretty horrible to me right now. Like i965 still
> supports a lot of hardware that exists right now even if we move to
> iris.
> 
> 
> I'm less concerned about the support burden.  When it comes to bugfixes, I 
> feel
> like most of the bugs on gen7 and earlier hardware at this point are due to
> churn in the core and if it lives in a maintenance branch, we'll stop breaking
> it.  The biggest thing we'd loose would be additional features that we might
> get thanks to core changes.  The major ones that come to mind are:
> 
>  - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we haven't due 
> to
> a lack of testing)
>  - GL_EXT_direct_state_access (still underway last I knew)
>  - GL_EXT_gpu_shader4
>  - Compat context support
> 
> All four of those are more-or-less software-only features that older intel
> drivers could pick up as the core advances.  Compat support likely requires a
> bit of driver work but it should be doable.
> 
> The real question is, "How much do we care?"  I can't say I like the idea of
> leaving Gen4-7 out in the cold.  Again, in a year's time, we might have most 
> of
> the above implemented and then it'd be less of a concern.
>  
> 
> I sorta feel there should be a
> 3) make life harder for classic drivers and optimise things more for
> gallium add more dd.h entrypoints, force the classic drivers to jump
> through hoops to degallium.
> 
> 
> I'd be interested to see what that would look like.  I'm not actually 
> convinced
> that it would work if I'm honest.  Part of gluing them together in my mind is
> deleting dd.h entirely and making the GL state tracker just call gallium 
> stuff.
> 
> There may be a 4th option here: Write a gallium driver for Intel Gen4-7. 
> Unfortunately, it would be a really hard sell to convince anyone (myself
> included) that this is worth anyone's time.  Sure, it might be a fun pr

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dylan Baker]

Quoting Marek Olšák (2019-12-03 16:39:15)
> Hi,
> 
> Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> 
> 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> Classic
> drivers won't share any code with master. glvnd will load them, but glvnd is
> not ready for this yet.

I think glvnd 1.3.0 will be able to do what we want, and that should happen in
the near future. Matt has been helping that work from the distro point of view,
so maybe he can confirm that.

> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and mesa/
> state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> location.
> 
> Option 2 is more acceptable to people who want to keep classic drivers in the
> tree and it can be done right now.
> 
> Opinions?
> 
> Thanks,
> Marek


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dylan Baker]

Quoting Dave Airlie (2019-12-03 18:18:55)
> On Wed, 4 Dec 2019 at 10:39, Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > Classic drivers won't share any code with master. glvnd will load them, but 
> > glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> > location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in 
> > the tree and it can be done right now.
> 
> These both seem pretty horrible to me right now. Like i965 still
> supports a lot of hardware that exists right now even if we move to
> iris.
> 
> I sorta feel there should be a
> 3) make life harder for classic drivers and optimise things more for
> gallium add more dd.h entrypoints, force the classic drivers to jump
> through hoops to degallium.

Maybe I'm misunderstanding what you mean, but what I'm hearing you say is
"modify src/mesa so that every single classic driver will have to be churned
significantly or stop working", which sounds much worse than options 1 or 2,
because the main problem with classic is that i965 is the only classic driver
that's really being maintained.

> I don't like forking src/mesa/main/* because really 99% of it is just
> a GL frontend implementation, most bugs in it will be in a fork and
> vice-versa, I'd rather refine the abstraction between mesa and
> backends if possible to reduce the overheads.
> 
> I'm probably not convinced that any benefit is worth accepting 1 or 2
> above, but hey I've been persuaded before to do crazy things.
> 
> Dave.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Wed, Dec 4, 2019 at 5:51 AM Timothy Arceri  wrote:

>
>
> On 4/12/19 3:45 pm, Jason Ekstrand wrote:
> > On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie  > > wrote:
> >
> > On Wed, 4 Dec 2019 at 10:39, Marek Olšák  > > wrote:
> >  >
> >  > Hi,
> >  >
> >  > Here are 2 proposals to simplify and better optimize the
> > GL->Gallium translation.
> >  >
> >  > 1) Move classic drivers to a fork of Mesa, and remove them from
> > master. Classic drivers won't share any code with master. glvnd will
> > load them, but glvnd is not ready for this yet.
> >
> >
> > I'm usually the first person to tell people to stop mucking about with
> > old hardware and I fear even I think this would be a bit premature.
> > We've not turned iris on by default yet and I'd really like it to bake
> > as the default distro driver for a while (maybe a year) before we put
> > i965 on life-support.  If we were having this discussion in another
> > year's time, I might be in favor of this but, as it currently stands,
> > I'm not sure this is a good idea.
> >
> >  > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
> > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/
> > can be the target location.
> >
> >
> > I really don't like this option.  For one thing, this means two copies
> > of code that will get out-of-sync.  If we had the classic drivers in
> > their own branch, we could at least cherry-pick bugfixes back to the
> > classic branch.  However, if we have two copies of everything, our
> > version control tool can't help us.
> >
> > The bigger problem is headers.  Currently, the GLSL compiler includes
> > mtypes.h so we would need to somehow separate the GLSL compiler out from
> > src/mesa/main because we'll have two mtypes.h files.  Unfortunately,
> > GLSL isn't the only thing that includes stuff from src/mesa/main.  Our
> > header situation has been a disaster for years and I'm afraid it hasn't
> > gotten any better with the addition of src/util.  Most people who move
> > stuff don't actually do due diligence to keep the includes clean and the
> > result is that I'm pretty sure even the Vulkan drivers are including
> > src/mesa/main/imports.h.  If we have two copies of src/mesa/main and the
> > headers begin to diverge, it's going to be a total disaster.  I would
> > love to see someone clean this all up properly and I think Mesa would be
> > better for it.  However, it is a LOT of work.
> >
> > If we did the above cleaning, would I be ok with this approach?
> > Possibly.  However, I suspect it'd end up being the worst of both
> > worlds.  We still have maintenance of effectively two branches and
> > bugfixes have to be ported.  At the same time, we'd still have core
> > changes to things like the GLSL compiler breaking old drivers so we
> > wouldn't lighten any of the maintenance burden.
> >
> >  > Option 2 is more acceptable to people who want to keep classic
> > drivers in the tree and it can be done right now.
> >
> > These both seem pretty horrible to me right now. Like i965 still
> > supports a lot of hardware that exists right now even if we move to
> > iris.
> >
> >
> > I'm less concerned about the support burden.  When it comes to bugfixes,
> > I feel like most of the bugs on gen7 and earlier hardware at this point
> > are due to churn in the core and if it lives in a maintenance branch,
> > we'll stop breaking it.  The biggest thing we'd loose would be
> > additional features that we might get thanks to core changes.  The major
> > ones that come to mind are:
> >
> >   - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we
> > haven't due to a lack of testing) >   - GL_EXT_direct_state_access
> (still underway last I knew)
>
> Is already done and enabled for compat profile.
>

Nice!  I thought there was still work left to do there.


> >   - GL_EXT_gpu_shader4
>
> Core mesa parts are done for this also.
>

Nice!  Somehow we didn't notice this happen.  I've pushed a MR for Gen6+ on
i965: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2963


> >   - Compat context support
>
> radeonsi, nouveau and iris all fully enable this. At this point its just
> a driver/classic issue to add support. So as with the two other features
> above options 1 or 2 will not change the fate of this support.
>

Yeah, it's mostly debug work not core mesa work.  So maybe not a blocker.


> >
> > All four of those are more-or-less software-only features that older
> > intel drivers could pick up as the core advances.  Compat support likely
> > requires a bit of driver work but it should be doable.
> >
> > The real question is, "How much do we care?"  I can't say I like the
> > idea of leaving Gen4-7 out in the cold.  Again, in a year's time, we
> > might have most of the above implemented and then it'd b

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Anholt]

On Tue, Dec 3, 2019 at 10:48 PM Marek Olšák  wrote:
>
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli,  wrote:
>>
>> Hi;
>>
>> On 12/4/19 2:39 AM, Marek Olšák wrote:
>> > Hi,
>> >
>> > Here are 2 proposals to simplify and better optimize the GL->Gallium
>> > translation.
>> >
>> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
>> > Classic drivers won't share any code with master. glvnd will load them,
>> > but glvnd is not ready for this yet.
>> >
>> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
>> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
>> > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can
>> > be the target location.
>> >
>> > Option 2 is more acceptable to people who want to keep classic drivers
>> > in the tree and it can be done right now.
>> >
>> > Opinions?
>> >
>>
>> I'm still quite newbie with gallium side of things and I'd like to know
>> more about the possible simplifications and optimizations that could be
>> done if this happened. Is this more about 'cleaning up the tree' or are
>> there also some performance opportunities we are missing right now with
>> current state?
>
>
> It's possible to reduce CPU overhead even more by moving state translation 
> from st_validate_state to GL functions. This is possible already, but at the 
> cost of effectively adding dead code to classic drivers. In theory we could 
> do slightly better without classic drivers, but we don't know for sure.

So just go do that!  Seriously, just stuff the state structs in the
Mesa context and maintain them as we go, the overhead for classic will
be low enough.  We're going to want to track the raw-style state
anyway for glGet() and all our validation, so it's not like we're
going to be garbage collecting a ton of stuff by forking out classic
drivers.

> If we had nir_to_tgsi, we could remove TGSI support from st/mesa. Option 1 
> would leave st/mesa as the only consumer of Mesa IR and GLSL IR, so both IRs 
> could be eliminated in favor of NIR more easily. Although I guess a simpler 
> option is not to touch anything.

I would love to see someone pick up my nir-to-tgsi branch (now 5 years
old?) and run with it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Anholt]

On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
>
> Hi,
>
> Here are 2 proposals to simplify and better optimize the GL->Gallium 
> translation.
>
> 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> Classic drivers won't share any code with master. glvnd will load them, but 
> glvnd is not ready for this yet.
>
> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> location.
>
> Option 2 is more acceptable to people who want to keep classic drivers in the 
> tree and it can be done right now.

(resending reply-all)

I object to both of these.  They increase work for Mesa folks like me
who do tree-wide work.

I feel like we're finally (formats, util/ helpers, etc.) paying down
the technical debt that we built with gallium copying so much of
src/mesa/main, and saying "let's go duplicate more code so we can do
some unspecified optimization work" gets me really upset.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Rob Clark]

On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
>
> On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > Classic drivers won't share any code with master. glvnd will load them, but 
> > glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> > location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in 
> > the tree and it can be done right now.
>
> (resending reply-all)
>
> I object to both of these.  They increase work for Mesa folks like me
> who do tree-wide work.
>
> I feel like we're finally (formats, util/ helpers, etc.) paying down
> the technical debt that we built with gallium copying so much of
> src/mesa/main, and saying "let's go duplicate more code so we can do
> some unspecified optimization work" gets me really upset.

tbf option #1 would be a copy of the code.. but a copy that we'd
(hopefully) ignore from the perspective of tree-wide cleanup/refactor.
If we started refactoring the legacy fork, that would strongly defeat
the purpose of having it!

Given that we don't have most of the classic drivers (other than i965)
in CI, and presumably not many folks who are tracking master test the
old classic drivers, moving them off to a fork seems to me to
significantly reduce the risk of refactorings (whether it be for perf
or for cleanup).

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Kristian Høgsberg]

On Wed, Dec 4, 2019 at 10:31 AM Rob Clark  wrote:
>
> On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
> >
> > On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> > >
> > > Hi,
> > >
> > > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > > translation.
> > >
> > > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > > Classic drivers won't share any code with master. glvnd will load them, 
> > > but glvnd is not ready for this yet.
> > >
> > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
> > > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can 
> > > be the target location.
> > >
> > > Option 2 is more acceptable to people who want to keep classic drivers in 
> > > the tree and it can be done right now.
> >
> > (resending reply-all)
> >
> > I object to both of these.  They increase work for Mesa folks like me
> > who do tree-wide work.
> >
> > I feel like we're finally (formats, util/ helpers, etc.) paying down
> > the technical debt that we built with gallium copying so much of
> > src/mesa/main, and saying "let's go duplicate more code so we can do
> > some unspecified optimization work" gets me really upset.
>
> tbf option #1 would be a copy of the code.. but a copy that we'd
> (hopefully) ignore from the perspective of tree-wide cleanup/refactor.
> If we started refactoring the legacy fork, that would strongly defeat
> the purpose of having it!
>
> Given that we don't have most of the classic drivers (other than i965)
> in CI, and presumably not many folks who are tracking master test the
> old classic drivers, moving them off to a fork seems to me to
> significantly reduce the risk of refactorings (whether it be for perf
> or for cleanup).

Another option would be to do a LTS-kind of release of mesa and then
drop the non-gallium drivers. It could even be limited in scope to the
non-gallium drivers, in the sense that we'd only do releases for fixes
to those drivers. It's basically option 1), but saying that we still
care about maintaining the drivers, but they wont receive new
features. With i965 being at GL 4.6, I don't think that's an
unreasonable stance (contrast with years ago when i965 feature level
was lagging the hw capability and spec).

At the end of the day, it will impact the Intel team the most and I
think it's largely their call.

Kristian

>
> BR,
> -R
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Engestrom]

On Wednesday, 2019-12-04 09:48:28 -0800, Eric Anholt wrote:
> On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > Classic drivers won't share any code with master. glvnd will load them, but 
> > glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, 
> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and 
> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target 
> > location.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in 
> > the tree and it can be done right now.
> 
> (resending reply-all)
> 
> I object to both of these.  They increase work for Mesa folks like me
> who do tree-wide work.
> 
> I feel like we're finally (formats, util/ helpers, etc.) paying down
> the technical debt that we built with gallium copying so much of
> src/mesa/main, and saying "let's go duplicate more code so we can do
> some unspecified optimization work" gets me really upset.

I have to agree there, I don't really see the benefit that could offset
the huge cost of forking the repo or duplicating the folders.

I've had extensive experience at $PREV_JOB with people just duplicating
everything "for the new generation" or "to better organise the code",
and the end result was absolutely unmaintainable and is costing everyone
working on it a seriously large multiplying factor on their work as they
had to copy their changes across and deal with all the changes that
hadn't been copied across by other devs.

They are now wasting huge amount of effort to de-duplicate everything so
that they can get to a point where they can maintain it again.

Let's not make the same mistake :)


I think if we really want to get rid of classic drivers, we should just
delete them from master and not support them at all anymore.
I don't think we're ready for that yet, especially not with i965, but in
a year or so I think that's the best move.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Dylan Baker]

Quoting Kristian Høgsberg (2019-12-04 10:43:46)
> On Wed, Dec 4, 2019 at 10:31 AM Rob Clark  wrote:
> >
> > On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
> > >
> > > On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> > > >
> > > > Hi,
> > > >
> > > > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > > > translation.
> > > >
> > > > 1) Move classic drivers to a fork of Mesa, and remove them from master. 
> > > > Classic drivers won't share any code with master. glvnd will load them, 
> > > > but glvnd is not ready for this yet.
> > > >
> > > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
> > > > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can 
> > > > be the target location.
> > > >
> > > > Option 2 is more acceptable to people who want to keep classic drivers 
> > > > in the tree and it can be done right now.
> > >
> > > (resending reply-all)
> > >
> > > I object to both of these.  They increase work for Mesa folks like me
> > > who do tree-wide work.
> > >
> > > I feel like we're finally (formats, util/ helpers, etc.) paying down
> > > the technical debt that we built with gallium copying so much of
> > > src/mesa/main, and saying "let's go duplicate more code so we can do
> > > some unspecified optimization work" gets me really upset.
> >
> > tbf option #1 would be a copy of the code.. but a copy that we'd
> > (hopefully) ignore from the perspective of tree-wide cleanup/refactor.
> > If we started refactoring the legacy fork, that would strongly defeat
> > the purpose of having it!
> >
> > Given that we don't have most of the classic drivers (other than i965)
> > in CI, and presumably not many folks who are tracking master test the
> > old classic drivers, moving them off to a fork seems to me to
> > significantly reduce the risk of refactorings (whether it be for perf
> > or for cleanup).
> 
> Another option would be to do a LTS-kind of release of mesa and then
> drop the non-gallium drivers. It could even be limited in scope to the
> non-gallium drivers, in the sense that we'd only do releases for fixes
> to those drivers. It's basically option 1), but saying that we still
> care about maintaining the drivers, but they wont receive new
> features. With i965 being at GL 4.6, I don't think that's an
> unreasonable stance (contrast with years ago when i965 feature level
> was lagging the hw capability and spec).

This is what I was trying to propose when I proposed this, basically just
security fixes, major bugs, and build breakages. And the release would straight
up disable gallium drivers and vulkan drivers (unless Jason wanted to drop <
gen8 from anv at the same time?) This isn't really all that different than what
we did in mesa 7 with the dri1 drivers, just using glvnd as the loader instead
of the mesa loader.

I really had thought of this as a something to do toward the end of next year or
early 2021, not something to do immediately. Given another 6-18 months Haswell
will have gone from pretty old to really old, and hopefully less interesting to
people.

Dylan

> 
> At the end of the day, it will impact the Intel team the most and I
> think it's largely their call.
> 
> Kristian
> 
> >
> > BR,
> > -R


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Eric Engestrom]

On 2019-12-04 at 18:54, Dylan Baker  wrote:
> Quoting Kristian Høgsberg (2019-12-04 10:43:46)
> > On Wed, Dec 4, 2019 at 10:31 AM Rob Clark  wrote:
> > >
> > > On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt  wrote:
> > > >
> > > > On Tue, Dec 3, 2019 at 4:39 PM Marek Olšák  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Here are 2 proposals to simplify and better optimize the GL->Gallium 
> > > > > translation.
> > > > >
> > > > > 1) Move classic drivers to a fork of Mesa, and remove them from 
> > > > > master. Classic drivers won't share any code with master. glvnd will 
> > > > > load them, but glvnd is not ready for this yet.
> > > > >
> > > > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only 
> > > > > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be 
> > > > > forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ 
> > > > > can be the target location.
> > > > >
> > > > > Option 2 is more acceptable to people who want to keep classic 
> > > > > drivers in the tree and it can be done right now.
> > > >
> > > > (resending reply-all)
> > > >
> > > > I object to both of these. They increase work for Mesa folks like me
> > > > who do tree-wide work.
> > > >
> > > > I feel like we're finally (formats, util/ helpers, etc.) paying down
> > > > the technical debt that we built with gallium copying so much of
> > > > src/mesa/main, and saying "let's go duplicate more code so we can do
> > > > some unspecified optimization work" gets me really upset.
> > >
> > > tbf option #1 would be a copy of the code.. but a copy that we'd
> > > (hopefully) ignore from the perspective of tree-wide cleanup/refactor.
> > > If we started refactoring the legacy fork, that would strongly defeat
> > > the purpose of having it!
> > >
> > > Given that we don't have most of the classic drivers (other than i965)
> > > in CI, and presumably not many folks who are tracking master test the
> > > old classic drivers, moving them off to a fork seems to me to
> > > significantly reduce the risk of refactorings (whether it be for perf
> > > or for cleanup).
> > 
> > Another option would be to do a LTS-kind of release of mesa and then
> > drop the non-gallium drivers. It could even be limited in scope to the
> > non-gallium drivers, in the sense that we'd only do releases for fixes
> > to those drivers. It's basically option 1), but saying that we still
> > care about maintaining the drivers, but they wont receive new
> > features. With i965 being at GL 4.6, I don't think that's an
> > unreasonable stance (contrast with years ago when i965 feature level
> > was lagging the hw capability and spec).
> 
> This is what I was trying to propose when I proposed this, basically just
> security fixes, major bugs, and build breakages. And the release would 
> straight
> up disable gallium drivers and vulkan drivers (unless Jason wanted to drop <
> gen8 from anv at the same time?) This isn't really all that different than 
> what
> we did in mesa 7 with the dri1 drivers, just using glvnd as the loader instead
> of the mesa loader.

Yes, this as the last release before we delete the classic drivers is the best 
option IMO 👍

> 
> I really had thought of this as a something to do toward the end of next year 
> or
> early 2021, not something to do immediately. Given another 6-18 months Haswell
> will have gone from pretty old to really old, and hopefully less interesting 
> to
> people.
> 
> Dylan
> 
> > 
> > At the end of the day, it will impact the Intel team the most and I
> > think it's largely their call.
> > 
> > Kristian
> > 
> > >
> > > BR,
> > > -R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Ian Romanick]

On 12/3/19 10:48 PM, Marek Olšák wrote:
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli,  > wrote:
> 
> Hi;
> 
> On 12/4/19 2:39 AM, Marek Olšák wrote:
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> > translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from
> master.
> > Classic drivers won't share any code with master. glvnd will load
> them,
> > but glvnd is not ready for this yet.
> >
> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> > mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be
> > forked and mesa/state_tracker moved.
> src/gallium/state-trackers/gl/ can
> > be the target location.
> >
> > Option 2 is more acceptable to people who want to keep classic
> drivers
> > in the tree and it can be done right now.
> >
> > Opinions?
> >
> 
> I'm still quite newbie with gallium side of things and I'd like to know
> more about the possible simplifications and optimizations that could be
> done if this happened. Is this more about 'cleaning up the tree' or are
> there also some performance opportunities we are missing right now with
> current state?
> 
> 
> It's possible to reduce CPU overhead even more by moving state
> translation from st_validate_state to GL functions. This is possible
> already, but at the cost of effectively adding dead code to classic
> drivers. In theory we could do slightly better without classic drivers,
> but we don't know for sure.

If someone wants to start on this, I would be more than happy to help
with the work on the old, poorly maintained drivers.  I have almost all
of the necessary hardware installed in (mostly) functioning systems.
The "big CPU system" I have in my house has a PCI Radeon 9000 installed,
and I use it fairly regularly.

> If we had nir_to_tgsi, we could remove TGSI support from st/mesa. Option
> 1 would leave st/mesa as the only consumer of Mesa IR and GLSL IR, so
> both IRs could be eliminated in favor of NIR more easily. Although I
> guess a simpler option is not to touch anything.
> 
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [ANNOUNCE] mesa 19.3.0-rc6

[Dylan Baker]

Hi list,

Available today is mesa 19.3.0-rc6. Things are starting to slow down, and there
are now only two open issues in the 19.3 milestone, so I'm hopeful that next
week will bring 19.3.0 final, and not an rc7, but I can always be surprised.

By far radv + aco dominate the list of changes, but there's also changes to anv,
panfrost, core gallium, fixes for OpenBSD, iris, and nir.

Dylan

Shortlog


Bas Nieuwenhuizen (2):
  radv: Unify max_descriptor_set_size.
  radv: Fix timeline semaphore refcounting.

Boris Brezillon (2):
  gallium: Fix the ->set_damage_region() implementation
  panfrost: Make sure we reset the damage region of RTs at flush time

Christian Gmeiner (1):
  etnaviv: remove dead code

Daniel Schürmann (2):
  aco: don't split live-ranges of linear VGPRs
  aco: fix a couple of value numbering issues

Dylan Baker (1):
  VERSION: bump version for 19.3-rc6

Jason Ekstrand (1):
  anv: Set up SBE_SWIZ properly for gl_Viewport

Jonathan Gray (2):
  winsys/amdgpu: avoid double simple_mtx_unlock()
  i965: update Makefile.sources for perf changes

Jordan Justen (1):
  iris: Allow max dynamic pool size of 2GB for gen12

Kenneth Graunke (2):
  driconf, glsl: Add a vs_position_always_invariant option
  drirc: Set vs_position_always_invariant for Shadow of Mordor on Intel

Rhys Perry (5):
  aco: propagate p_wqm on an image_sample's coordinate p_create_vector
  aco: fix i2i64
  aco: add v_nop inbetween exec write and VMEM/DS/FLAT
  radv: set writes_memory for global memory stores/atomics
  nir/lower_io_to_vector: don't create arrays when not needed

Samuel Pitoiset (2):
  radv: fix enabling sample shading with SampleID/SamplePosition
  radv/gfx10: fix implementation of exclusive scans


git tag: mesa-19.3.0-rc6

https://mesa.freedesktop.org/archive/mesa-19.3.0-rc6.tar.xz
SHA256: 61dc7b465133734aa2f762f52b0d21831c98e0899f601f00cf81cad58854c7fc  
mesa-19.3.0-rc6.tar.xz
SHA512: 
44b6629a5181c64a7dc141299f4ef7a68cd4d5c339952a94a0aea774e8495b2a7b206a86e42cee965ac27eddd9549d09cf253bbeb7048ddff20ed5cec6d36f80
  mesa-19.3.0-rc6.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.3.0-rc6.tar.xz.sig



signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [ANNOUNCE] mesa 19.2.7

[Dylan Baker]

Hi list,

Mesa 19.2.7 is now available. This is a regularly scheduled release.  Things
look slow, but this is only one week's worth of changes, so its actually a
pretty big release for being this far in the cycle.

radv makes up the majority of the changes, but there's also changes for gallium,
intel, anv, meson, core mesa, and some OpenBSD fixes.

Dylan


Shortlog


Bas Nieuwenhuizen (2):
  radv: Allocate cmdbuffer space for buffer marker write.
  radv: Unify max_descriptor_set_size.

Boris Brezillon (1):
  gallium: Fix the ->set_damage_region() implementation

Dylan Baker (2):
  docs: Add release notes for 19.2.7
  VERSION: bump version for 19.2.7

Ian Romanick (1):
  intel/fs: Disable conditional discard optimization on Gen4 and Gen5

Jason Ekstrand (1):
  anv: Set up SBE_SWIZ properly for gl_Viewport

Jonathan Gray (2):
  winsys/amdgpu: avoid double simple_mtx_unlock()
  i965: update Makefile.sources for perf changes

Rhys Perry (1):
  radv: set writes_memory for global memory stores/atomics

Samuel Pitoiset (3):
  radv: fix enabling sample shading with SampleID/SamplePosition
  radv/gfx10: fix implementation of exclusive scans
  radv: fix compute pipeline keys when optimizations are disabled

Yevhenii Kolesnikov (1):
  meson: Fix linkage of libgallium_nine with libgalliumvl

Zebediah Figura (1):
  Revert "draw: revert using correct order for prim decomposition."


git tag: mesa-19.2.7

https://mesa.freedesktop.org/archive/mesa-19.2.7.tar.xz
SHA256: e3799fb7896fd9ed2f90f651fb907b95cdebfbd494968ff116e6bf1be143579e  
mesa-19.2.7.tar.xz
SHA512: 
87a82664381432e956ee23dc92bec5accf667606232e38d9458d67132c16fdc44584f65671293b83f00c58ad7742b80e942a5d1bd66d457705be60aaaf35395b
  mesa-19.2.7.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.2.7.tar.xz.sig



signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Projects for 2020's GSoC?

[João Duarte]

Greetings

I was skimming through X.Org's project proposals for next year's GSoC/EVoC.
I'd like to learn more about mesa related projects because/albeit it is a
totally new domain for me!
I've noticed some of the listed projects have already been developed. For
example, the DriConf project has in the mean time been implement as
ADriConf. Jean, its creator, told me about some ideas for further
development. Would it be a viable GSoC proposal for Mesa?

Thanks for the attention!

Best regards,

João Duarte
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Add support for midstream bitrate change in encoder

[Leo Liu]

On 2019-12-02 11:30 p.m., Satyajit Sahu wrote:

Added support for bitrate change in between encoding.

Signed-off-by: Satyajit Sahu 

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 84d3c1e2fa4..7d7a2fa4eb3 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -268,7 +268,8 @@ static void rvce_begin_frame(struct pipe_video_codec 
*encoder,
enc->pic.rate_ctrl.rate_ctrl_method != 
pic->rate_ctrl.rate_ctrl_method ||
enc->pic.quant_i_frames != pic->quant_i_frames ||
enc->pic.quant_p_frames != pic->quant_p_frames ||
-   enc->pic.quant_b_frames != pic->quant_b_frames;
+   enc->pic.quant_b_frames != pic->quant_b_frames ||
+   enc->pic.rate_ctrl.target_bitrate != 
pic->rate_ctrl.target_bitrate;
  
  	enc->pic = *pic;

si_get_pic_param(enc, pic);
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index aa9182f273b..c4fb9a7bd92 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -247,6 +247,17 @@ static void radeon_enc_begin_frame(struct pipe_video_codec 
*encoder,
  {
struct radeon_encoder *enc = (struct radeon_encoder*)encoder;
struct vl_video_buffer *vid_buf = (struct vl_video_buffer *)source;
+   bool need_rate_control = false;
+
+   if (u_reduce_video_profile(enc->base.profile) == 
PIPE_VIDEO_FORMAT_MPEG4_AVC) {
+   struct pipe_h264_enc_picture_desc *pic = (struct 
pipe_h264_enc_picture_desc *)picture;
+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rate_ctrl.target_bitrate;
+   } else if (u_reduce_video_profile(picture->profile) == 
PIPE_VIDEO_FORMAT_HEVC) {
+struct pipe_h265_enc_picture_desc *pic = (struct 
pipe_h265_enc_picture_desc *)picture;


Please fix your indentation here.

And then rebase with Mesa master, it seem your patch doesn't get 
compiled with Mesa master. Please resend after the fixes.


Regards,

Leo




+   need_rate_control =
+   enc->enc_pic.rc_layer_init.target_bit_rate != 
pic->rc.target_bitrate;
+   }
  
  	radeon_vcn_enc_get_param(enc, picture);
  
@@ -266,6 +277,10 @@ static void radeon_enc_begin_frame(struct pipe_video_codec *encoder,

flush(enc);
si_vid_destroy_buffer(&fb);
}
+   if (need_rate_control) {
+   enc->begin(enc, picture);
+   flush(enc);
+   }
  }
  
  static void radeon_enc_encode_bitstream(struct pipe_video_codec *encoder,

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util: unbreak endian detection on OpenBSD

[Jonathan Gray]

Since cbee1bfb34274668a05995b9d4c78ddec9e5ea4c endian.h is unconditionally
used if available.

glibc has byte order defines with two leading underscores.  OpenBSD
has private defines with a single leading underscore in machine/endian.h
and public defines in endian.h with no underscore.

The code under the endian.h block did not check if symbols were
defined before equating them so '#if __BYTE_ORDER == __LITTLE_ENDIAN'
would turn into '#if 0 == 0' which is always true.

Signed-off-by: Jonathan Gray 
Fixes: cbee1bfb342 ("meson/configure: detect endian.h instead of trying to 
guess when it's available")
---
 src/util/u_endian.h | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/util/u_endian.h b/src/util/u_endian.h
index 6bbae3c444c..3f76f340837 100644
--- a/src/util/u_endian.h
+++ b/src/util/u_endian.h
@@ -30,10 +30,20 @@
 #ifdef HAVE_ENDIAN_H
 #include 
 
-#if __BYTE_ORDER == __LITTLE_ENDIAN
+/* glibc */
+#if defined(__BYTE_ORDER) && (__BYTE_ORDER == __LITTLE_ENDIAN)
 # define UTIL_ARCH_LITTLE_ENDIAN 1
 # define UTIL_ARCH_BIG_ENDIAN 0
-#elif __BYTE_ORDER == __BIG_ENDIAN
+#elif defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)
+# define UTIL_ARCH_LITTLE_ENDIAN 0
+# define UTIL_ARCH_BIG_ENDIAN 1
+#endif
+
+/* OpenBSD */
+#if defined(BYTE_ORDER) && (BYTE_ORDER == LITTLE_ENDIAN)
+# define UTIL_ARCH_LITTLE_ENDIAN 1
+# define UTIL_ARCH_BIG_ENDIAN 0
+#elif defined(BYTE_ORDER) && (BYTE_ORDER == BIG_ENDIAN)
 # define UTIL_ARCH_LITTLE_ENDIAN 0
 # define UTIL_ARCH_BIG_ENDIAN 1
 #endif
@@ -60,8 +70,8 @@
 # define UTIL_ARCH_BIG_ENDIAN 1
 #endif
 
-#elif defined(__OpenBSD__) || defined(__NetBSD__) || \
-  defined(__FreeBSD__) || defined(__DragonFly__)
+#elif defined(__NetBSD__) || defined(__FreeBSD__) || \
+  defined(__DragonFly__)
 #include 
 #include 
 
-- 
2.24.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] CVE-2019-19520: Local privilege escalation via xlock

[Jonathan Gray]

Until very recently OpenBSD built xlockmore against Mesa.  xlock is
setgid auth.  As described by Qualys in their advisory
https://marc.info/?l=oss-security&m=157549260013521&w=2
"CVE-2019-19520: Local privilege escalation via xlock"
the setuid check in the loader for LIBGL_DRIVERS_PATH does not handle
this.

In OpenBSD we now build xlock with --without-opengl --without-mesa and
build Mesa with the following patch.  This is not an approach that would
work on linux and other systems without issetugid().
https://man.openbsd.org/issetugid.2
But it is worth bringing this issue to people's attention.

xenocara/lib/mesa/src/loader/loader.c
revision 1.8
date: 2019/12/04 02:26:36;  author: deraadt;  state: Exp;  lines: +2 -2;  
commitid: w6WeeZZ0y0WnF7VD;
Constrain honouring of path-related environment variables based upon
issetugid(), not just the sloppy uid != euid test. gid != egid cases
can occur also.
Part of 6.6/009_mesaxlock.patch.sig and 6.5/020_mesaxlock.patch.sig
From Qualys, ok

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 67cf92c19df..7865fe45c87 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -446,7 +446,7 @@ loader_get_driver_for_fd(int fd)
 * user's problem, but this allows vc4 simulator to run on an i965 host,
 * and may be useful for some touch testing of i915 on an i965 host.
 */
-   if (geteuid() == getuid()) {
+   if (issetugid() == 0 && geteuid() == getuid()) {
   driver = getenv("MESA_LOADER_DRIVER_OVERRIDE");
   if (driver)
  return strdup(driver);
@@ -534,7 +534,7 @@ loader_open_driver(const char *driver_name,
const struct __DRIextensionRec **(*get_extensions)(void);
 
search_paths = NULL;
-   if (geteuid() == getuid() && search_path_vars) {
+   if (issetugid() == 0 && geteuid() == getuid() && search_path_vars) {
   for (int i = 0; search_path_vars[i] != NULL; i++) {
  search_paths = getenv(search_path_vars[i]);
  if (search_paths)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] CVE-2019-19520: Local privilege escalation via xlock

[Dave Airlie]

On Thu, 5 Dec 2019 at 13:42, Jonathan Gray  wrote:
>
> Until very recently OpenBSD built xlockmore against Mesa.  xlock is
> setgid auth.  As described by Qualys in their advisory
> https://marc.info/?l=oss-security&m=157549260013521&w=2
> "CVE-2019-19520: Local privilege escalation via xlock"
> the setuid check in the loader for LIBGL_DRIVERS_PATH does not handle
> this.
>
Should we just use secure_getenv?

DAve.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] CVE-2019-19520: Local privilege escalation via xlock

[Jonathan Gray]

On Thu, Dec 05, 2019 at 01:59:50PM +1000, Dave Airlie wrote:
> On Thu, 5 Dec 2019 at 13:42, Jonathan Gray  wrote:
> >
> > Until very recently OpenBSD built xlockmore against Mesa.  xlock is
> > setgid auth.  As described by Qualys in their advisory
> > https://marc.info/?l=oss-security&m=157549260013521&w=2
> > "CVE-2019-19520: Local privilege escalation via xlock"
> > the setuid check in the loader for LIBGL_DRIVERS_PATH does not handle
> > this.
> >
> Should we just use secure_getenv?
> 
> DAve.

That is also not portable, appears to be glibc only.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: remove second prototype of brw_batch_reloc

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 91720dad5b4..137158f168a 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -67,11 +67,6 @@ uint64_t brw_batch_reloc(struct intel_batchbuffer *batch,
  struct brw_bo *target,
  uint32_t target_offset,
  unsigned flags);
-uint64_t brw_state_reloc(struct intel_batchbuffer *batch,
- uint32_t batch_offset,
- struct brw_bo *target,
- uint32_t target_offset,
- unsigned flags);
 
 #define USED_BATCH(_batch) \
((uintptr_t)((_batch).map_next - (_batch).batch.map))
-- 
2.23.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Kenneth Graunke]

On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:
> Hi,
> 
> Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> 
> 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will load them, but
> glvnd is not ready for this yet.
> 
> 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
> mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
> mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
> location.
> 
> Option 2 is more acceptable to people who want to keep classic drivers in
> the tree and it can be done right now.
> 
> Opinions?
> 
> Thanks,
> Marek

FWIW, I am not in favor of either plan for the time being.

- I agree with Eric that we're finally starting to clean up and
  de-duplicate things, and pay off technical debt we've put off for
  a long time.  I think forking everything in-tree would just be a
  giant mess.

- I agree with Dave that this seems to be a giant hassle for our
  downstreams with little benefit for them in the short term.

- Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems
  like a fine plan.  They're ancient hardware that can't (or barely
  can) do GL 2.x.  Nothing much has happened with them in years,
  and I'm not sure all of them even really have maintainers.

  The main blocker here I think would be ironing out all the glvnd
  issues and making sure that is working solidly for everyone.
  (FWIW, glvnd is not even enabled by default in our build system!)

- Shuffling i965 off to legacy is really premature I think.  Iris
  isn't even shipping in distros yet (hopefully soon!), and even
  then, we have a _ton_ of Haswell users.  Check the Phoronix
  comments if you want to see how pissed off people are about even
  bringing up this topic.  (Or better yet, don't...basic human
  decency toward others seems to be lacking.  Hooray, internet...)

- Writing a Gallium driver for Intel Gen4-7.5 would be interesting.

  I've been thinking about this some, and it might be possible to
  retain some of the niceties of the iris memory model even on older
  hardware, by relying on a modern kernel and possibly making some
  (hopefully minor) improvements.  Even if we didn't, going back to
  the i965 model wouldn't be the worst thing.  The new driver would
  almost certainly be faster than i965, if not as good as iris.

  ajax and I were planning to call it crocus, if I wrote one.  I don't
  think it would take nearly as long.  But it's still a bunch of time
  that I don't think I can justify spending.  The new hardware can do
  so much more, and is so much faster, and much lower power.  I think
  it would be better for me to spend my time on Gen11+.

- Vulkan has really taken off, and OpenGL feels increasingly like a
  dead end.  DXVK has brought more games than we had with native ports.
  Feral is even reworking some native OpenGL ports to use Vulkan.  New
  graphics features are happening in the Vulkan space.

  So, I kind of wonder whether it's worth our time to go through and
  massively clean up and rearchitecture the OpenGL drivers at this
  point.  By the time we're finished, will anyone care?

- Are there concrete things that are prohibitively expensive with
  classic around?  Otherwise, Eric's suggestion of "so go do that!"
  sounds like a good idea.  We've started finally merging a bunch
  of code and I think this is a positive direction.

I'd say let's shelve this for now and think about it again later.
I suspect in a year or so the calculus will look fairly different.

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev