On Thu, Mar 23, 2017 at 6:32 PM, Matt Turner wrote:
> On Wed, Mar 22, 2017 at 12:53 PM, Rob Herring wrote:
>> On Wed, Mar 22, 2017 at 6:50 AM, Emil Velikov
>> wrote:
>>> n 21 March 2017 at 20:58, Kenneth Graunke
Series is:
Reviewed-by: Ilia Mirkin
On Wed, Mar 22, 2017 at 8:51 PM, Lyude wrote:
> While working on adding NV_fill_polygon support for mesa, I noticed a good
> number of parts of mesa that had somewhat broken indenting, trailing
> whitespace, etc. So I
On 24/03/17 10:42, Marek Olšák wrote:
From: Marek Olšák
---
src/mesa/drivers/dri/i965/brw_state_upload.c | 3 ++-
src/mesa/main/attrib.c | 2 +-
src/mesa/main/debug.c| 3 ++-
src/mesa/main/state.c|
Signed-off-by: Lyude
---
src/mesa/main/polygon.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
index 60af88f..46673ee 100644
--- a/src/mesa/main/polygon.c
+++ b/src/mesa/main/polygon.c
@@ -143,14
While working on adding NV_fill_polygon support for mesa, I noticed a good
number of parts of mesa that had somewhat broken indenting, trailing
whitespace, etc. So I decided to fix up anything close to the code I was
touching.
This series contains no functional changes, only minor style fixes.
On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker wrote:
> Quoting Colin Cross (2017-03-23 15:14:16)
>> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote:
>> > On 03/22/2017 02:48 PM, Rob Clark wrote:
>> >>
>> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan
On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote:
> On 03/22/2017 02:48 PM, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
>>>
>>> Quoting Rob Clark (2017-03-22 10:07:54)
I guess an interesting question (from
Signed-off-by: Lyude
---
src/gallium/drivers/vc4/vc4_screen.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/vc4/vc4_screen.c
b/src/gallium/drivers/vc4/vc4_screen.c
index b53e71d..46229a7 100644
---
Signed-off-by: Lyude
---
src/gallium/drivers/r300/r300_screen.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index 07a09d5..752cf82 100644
---
Signed-off-by: Lyude
---
src/mesa/main/polygon.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
index 46673ee..4caf62a 100644
--- a/src/mesa/main/polygon.c
+++ b/src/mesa/main/polygon.c
@@ -75,7 +75,7
From: Boyuan Zhang
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vce.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_vce.c
b/src/gallium/drivers/radeon/radeon_vce.c
index
https://bugs.freedesktop.org/show_bug.cgi?id=100091
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
On Thu, Mar 23, 2017 at 1:50 PM, Jason Ekstrand
wrote:
> On Wed, Mar 22, 2017 at 4:14 AM, Juan A. Suarez Romero <
> jasua...@igalia.com> wrote:
>
>> On Wed, 2017-03-15 at 13:05 +0100, Juan A. Suarez Romero wrote:
>> > Current Anv allocator assign memory in terms of a fixed
There are some nice cleanups here.
Series:
Reviewed-by: Timothy Arceri
On 24/03/17 10:42, Marek Olšák wrote:
From: Marek Olšák
---
src/mesa/main/state.c| 7 +--
src/mesa/main/texstate.c | 22 --
Patches 1 & 2 are:
Reviewed-by: Samuel Pitoiset
No clue about about 3.
On 03/24/2017 01:00 AM, Marek Olšák wrote:
From: Marek Olšák
Cc: 17.0
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
1
This series is,
Reviewed-by: Edward O'Callaghan
On 03/24/2017 10:42 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/main/state.c| 7 +--
> src/mesa/main/texstate.c | 22 --
> src/mesa/main/texstate.h
From: Marek Olšák
This should fix this radeonsi error:
"mesa: for the -simplifycfg-sink-common option: may only occur zero or one
times!"
---
src/gallium/targets/va/va.sym | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/targets/va/va.sym
From: Marek Olšák
Cc: 17.0
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_compute.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 19a9189..46476b6 100644
---
I'll send a fix.
Marek
On Thu, Mar 23, 2017 at 12:38 PM, Nicolai Hähnle wrote:
> On 22.03.2017 21:00, Andy Furniss wrote:
>>
>> Samuel Pitoiset wrote:
>>
>> This patch has a minor issue for me using radeonsi on tonga.
>>
>> ffmpeg vaapi hwdecode by cli or via mpv now
Quoting Colin Cross (2017-03-23 15:14:16)
> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote:
> > On 03/22/2017 02:48 PM, Rob Clark wrote:
> >>
> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
> >>>
> >>> Quoting Rob Clark (2017-03-22
On 03/23/2017 08:53 PM, Marek Olšák wrote:
NAK.
I wouldn't like more overhead in cso_context when better solutions are
available. There are several ways of dealing with texture update
overhead:
1) Split _NEW_TEXTURE into multiple flags, each covering a disjoint
set of states smaller than
From: Marek Olšák
---
src/mesa/main/state.c| 7 +--
src/mesa/main/texstate.c | 22 --
src/mesa/main/texstate.h | 7 +--
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index
From: Marek Olšák
---
src/mesa/drivers/dri/r200/r200_state.c| 5 +
src/mesa/drivers/dri/r200/r200_vertprog.c | 16
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_state.c
From: Marek Olšák
---
src/mesa/drivers/common/driverfuncs.c | 1 -
src/mesa/main/arbprogram.c| 3 --
src/mesa/main/atifragshader.c | 3 --
src/mesa/main/dd.h| 3 --
src/mesa/main/state.c | 55
From: Marek Olšák
---
src/mesa/drivers/dri/i965/brw_state_upload.c | 3 ++-
src/mesa/main/attrib.c | 2 +-
src/mesa/main/debug.c| 3 ++-
src/mesa/main/state.c| 10 +-
src/mesa/main/texstate.c
From: Marek Olšák
No performance testing has been done, because it makes sense to make this
change regardless of that. Also, _NEW_TEXTURE is still used in many places,
but the obvious occurences are replaced here.
It's now possible to split _NEW_TEXTURE_OBJECT further.
---
From: Marek Olšák
The same thing is done in i915_update_program called by i915InvalidateState.
Why do it twice.
---
src/mesa/drivers/dri/i915/i915_fragprog.c | 25 -
1 file changed, 25 deletions(-)
diff --git
On 03/23/2017 08:30 PM, Nicolai Hähnle wrote:
On 23.03.2017 20:17, Samuel Pitoiset wrote:
Instead add is_cube_shadow like is_cube_array.
I'm curious: why? Anyway, looks fine, so
Preliminary work for ARB_bindless_texture. I will introduce new types
like sampler2DBindless_type.
On 24/03/17 09:47, Miklós Máté wrote:
Thank you for the review. Could someone please commit this? I have no
access.
MM
Pushed. Thanks!
On 20/03/17 17:36, Marek Olšák wrote:
Reviewed-by: Marek Olšák
Marek
On Sat, Mar 18, 2017 at 10:55 PM, Miklós Máté
Thank you for the review. Could someone please commit this? I have no
access.
MM
On 20/03/17 17:36, Marek Olšák wrote:
Reviewed-by: Marek Olšák
Marek
On Sat, Mar 18, 2017 at 10:55 PM, Miklós Máté wrote:
Signed-off-by: Miklós Máté
On Wed, Mar 22, 2017 at 12:53 PM, Rob Herring wrote:
> On Wed, Mar 22, 2017 at 6:50 AM, Emil Velikov
> wrote:
>> n 21 March 2017 at 20:58, Kenneth Graunke wrote:
>>> On Tuesday, March 21, 2017 4:40:26 AM PDT Emil Velikov wrote:
On Thu, Mar 23, 2017 at 9:59 PM, Ilia Mirkin wrote:
> On Thu, Mar 23, 2017 at 3:33 PM, Marek Olšák wrote:
>> On Thu, Mar 23, 2017 at 7:45 PM, Lyude Paul wrote:
>>> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
On Thu, Mar
https://bugs.freedesktop.org/show_bug.cgi?id=99817
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
On 03/22/2017 02:48 PM, Rob Clark wrote:
On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
Quoting Rob Clark (2017-03-22 10:07:54)
I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
On Thu, Mar 23, 2017 at 3:33 PM, Marek Olšák wrote:
> On Thu, Mar 23, 2017 at 7:45 PM, Lyude Paul wrote:
>> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák
>>> wrote:
>>> > Is there any
Misfire. Ignore this one.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
We want to be able to check the progress of each pass and dump the NIR
for debugging purposes if it changed.
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_nir.c | 42 +++---
1 file changed, 19 insertions(+), 23 deletions(-)
On Wed, Mar 22, 2017 at 4:14 AM, Juan A. Suarez Romero
wrote:
> On Wed, 2017-03-15 at 13:05 +0100, Juan A. Suarez Romero wrote:
> > Current Anv allocator assign memory in terms of a fixed block size.
> >
> > But there can be cases where this block is not enough for a memory
SEL can only convert between a few integer types, which we basically
never do.
Fixes fs/vs-double-uniform-array-direct-indirect-non-uniform-control-flow
Cc: mesa-sta...@lists.freedesktop.org
---
src/intel/compiler/brw_fs_sel_peephole.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git
NAK.
I wouldn't like more overhead in cso_context when better solutions are
available. There are several ways of dealing with texture update
overhead:
1) Split _NEW_TEXTURE into multiple flags, each covering a disjoint
set of states smaller than _NEW_TEXTURE.
2) Use a stage-specific flag (e.g.
Reviewed-by: Marek Olšák
Marek
On Thu, Mar 23, 2017 at 1:51 AM, Lyude wrote:
> Signed-off-by: Lyude
> ---
> src/gallium/drivers/r300/r300_screen.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
On 23.03.2017 19:44, Samuel Pitoiset wrote:
Sampler views were only cached for the fragment shader stage, but
this might help other stages.
This is a small opt which should help civ6 a little bit.
Do you have benchmarks? This might help if we don't manage to filter out
redundant state
On Thu, Mar 23, 2017 at 7:45 PM, Lyude Paul wrote:
> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák
>> wrote:
>> > Is there any user of this extension?
>>
>> Based on the spec, it seems like it would be
On 23.03.2017 20:17, Samuel Pitoiset wrote:
Instead add is_cube_shadow like is_cube_array.
I'm curious: why? Anyway, looks fine, so
Reviewed-by: Nicolai Hähnle
Signed-off-by: Samuel Pitoiset
---
On Wed, Mar 22, 2017 at 6:04 PM, Chad Versace
wrote:
> Validate that isl_surf::row_pitch fits in the below bitfields,
> if applicable based on isl_surf::usage.
>
> RENDER_SURFACE_STATE::SurfacePitch
> RENDER_SURFACE_STATE::AuxiliarySurfacePitch
>
Samuel Iglesias Gonsálvez writes:
> On Wed, 2017-03-22 at 15:55 -0700, Francisco Jerez wrote:
>> Samuel Iglesias Gonsálvez writes:
>>
>> > Now the VEC4_OPCODE_FROM_DOUBLE's destination data is written with
>> > stride 2. We need to take into account
Matches the docs.
Reviewed-by: Jason Ekstrand
On Wed, Mar 22, 2017 at 6:03 PM, Chad Versace
wrote:
> isl will use this for validating the depth buffer pitch.
> ---
> src/intel/genxml/gen5.xml | 56 ++
>
Instead add is_cube_shadow like is_cube_array.
Signed-off-by: Samuel Pitoiset
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
Samuel Iglesias Gonsálvez writes:
> On Wed, 2017-03-22 at 15:49 -0700, Francisco Jerez wrote:
>> I'd rename this to lower_conversions instead since after your
>> previous
>> patch it's going to take care of handling unsupported conversions
>> which
>> aren't necessarily to
Samuel Iglesias Gonsálvez writes:
> On Wed, 2017-03-22 at 15:47 -0700, Francisco Jerez wrote:
>> Samuel Iglesias Gonsálvez writes:
>>
>> > Generalize it to lower any unsupported narrower conversion.
>> >
>> > v2 (Curro):
>> > - Add
On Thu, Mar 23, 2017 at 2:57 PM, Ilia Mirkin wrote:
> On Thu, Mar 23, 2017 at 2:45 PM, Lyude Paul wrote:
>> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák
>>> wrote:
>>> > Is there
On Thu, Mar 23, 2017 at 2:45 PM, Lyude Paul wrote:
> On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
>> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák
>> wrote:
>> > Is there any user of this extension?
>>
>> Based on the spec, it seems like it would be
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 93528, which changed state.
Bug 93528 Summary: GPU hang with Borderlands 2 on X1C3
https://bugs.freedesktop.org/show_bug.cgi?id=93528
What|Removed |Added
I'm not going to ask you to rewrite it in mako but that's what we should do
in the future. :-) Someone can rewrite later. I want things to land. :-)
On Wed, Mar 22, 2017 at 6:03 PM, Chad Versace
wrote:
> genX_bits.h contains the sizes of bitfields in genxml
On Thu, 2017-03-23 at 14:22 -0400, Alex Deucher wrote:
> On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák
> wrote:
> > Is there any user of this extension?
>
> Based on the spec, it seems like it would be useful for glamor. No
> idea is anyone has code to use it yet.
Actually me,
Sampler views were only cached for the fragment shader stage, but
this might help other stages.
This is a small opt which should help civ6 a little bit.
Signed-off-by: Samuel Pitoiset
---
src/gallium/auxiliary/cso_cache/cso_context.c | 101 ++
From: Emil Velikov
Some versions of autotools will not create the output directory for
generated sources. Do the safe thing and create it anywhere.
Cc: Dylan Baker
Cc: Steven Newbury
Reported-by: Steven Newbury
On 21 March 2017 at 05:00, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil
On Thu, Mar 23, 2017 at 2:18 PM, Marek Olšák wrote:
> Is there any user of this extension?
Based on the spec, it seems like it would be useful for glamor. No
idea is anyone has code to use it yet.
Alex
>
> Marek
>
> On Thu, Mar 23, 2017 at 4:27 PM, Lyude
Please add a comment into the code that PIPE_USAGE_STAGING is used
because the buffer is mapped for read. With that:
Reviewed-by: Marek Olšák
Marek
On Thu, Mar 23, 2017 at 3:35 PM, Leo Liu wrote:
> Workaround an unknown bug with inside the transfer_map
Is there any user of this extension?
Marek
On Thu, Mar 23, 2017 at 4:27 PM, Lyude wrote:
> This adds basic support for GL_NV_fill_rectangle in Gallium, along with
> enabling it for the GM200+ in nouveau. It should be noted this only
> implements the OpenGL 4.3 bits, since we
Reviewed-by: Marek Olšák
Marek
On Thu, Mar 23, 2017 at 6:14 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> The state tracker no longer uploads those attributes for us,
> so we must conservatively upload the size of the
On Thu, Mar 23, 2017 at 12:25:28PM +0100, Samuel Iglesias Gonsálvez wrote:
> A resolve is not needed on Skylake in this case. We were forcing
> a resolve because we set the input_aux_usage to ISL_AUX_USAGE_NONE.
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
>
> This
The recent changes to anv_entrypoints_gen.py seem to have broken out-of
-tree builds:
Traceback (most recent call last):
File
"/var/tmp/portage/media-libs/mesa--r1/work/Mesa-/src/intel/vulkan/anv_entrypoints_gen.py",
line 381, in
main()
File
Quoting Emil Velikov (2017-03-23 04:39:50)
> On 22 March 2017 at 20:10, Dylan Baker wrote:
>
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\
Sure, but if it's easier to get right (which
Ah I see. So we still get 2 vertex attributes, good. This was just
tripping some assumptions in your code about how attributes are laid
out in a constant vertex buffer. I guess I should double-check nouveau
as well, but I think we should be good. I always forget about the
disconnect between
On 23.03.2017 18:19, Ilia Mirkin wrote:
Wait, you can have constant attribs that are dvec4's? Those don't get
split up into multiple constant attribs (2x dvec2, as it would for a
regular VBO)? Or am I misunderstanding the circumstances?
The draw call will have one vertex buffer for each GL
Wait, you can have constant attribs that are dvec4's? Those don't get
split up into multiple constant attribs (2x dvec2, as it would for a
regular VBO)? Or am I misunderstanding the circumstances?
On Thu, Mar 23, 2017 at 1:14 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
From: Nicolai Hähnle
The state tracker no longer uploads those attributes for us,
so we must conservatively upload the size of the largest
attribute, which is a dvec4.
Fixes a regression of GL45-CTS.gpu_shader_fp64.varyings and
GL45-CTS.vertex_attrib_64bit.limits_test.
On 03/23/2017 09:27 AM, Lyude wrote:
Signed-off-by: Lyude
---
src/gallium/include/pipe/p_defines.h | 1 +
src/gallium/include/pipe/p_state.h | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
On 03/23/2017 09:27 AM, Lyude wrote:
Since we don't have the bits required to support this in OpenGLES yet,
this only enables support for OpenGL 4.3.
Signed-off-by: Lyude
---
src/mesa/main/api_validate.c | 13 +
src/mesa/main/extensions_table.h | 1 +
mesa/st -> st/mesa
On 03/23/2017 04:27 PM, Lyude wrote:
Signed-off-by: Lyude
---
src/mesa/state_tracker/st_atom_rasterizer.c | 2 ++
src/mesa/state_tracker/st_extensions.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
Nice work!
Usually, gallium bits come *after* mesa ones, like:
mesa:
gallium:
st/mesa:
On 03/23/2017 04:27 PM, Lyude wrote:
This adds basic support for GL_NV_fill_rectangle in Gallium, along with
enabling it for the GM200+ in nouveau. It should be noted this only
implements the OpenGL 4.3
On 03/23/2017 04:27 PM, Lyude wrote:
Since we don't have the bits required to support this in OpenGLES yet,
this only enables support for OpenGL 4.3.
Signed-off-by: Lyude
---
src/mesa/main/api_validate.c | 13 +
src/mesa/main/extensions_table.h | 1 +
On Thu, Mar 23, 2017 at 11:27 AM, Lyude wrote:
> This enables support for the GL_NV_fill_rectangle extension on the
> GM200+ for OpenGL 4.3.
For desktop GL. Also please add a note in docs/17.1.0/relnotes.html.
>
> Signed-off-by: Lyude
> ---
>
On Thu, Mar 23, 2017 at 11:27 AM, Lyude wrote:
> Signed-off-by: Lyude
> ---
> src/gallium/include/pipe/p_defines.h | 1 +
> src/gallium/include/pipe/p_state.h | 4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git
On Thu, Mar 23, 2017 at 11:27 AM, Lyude wrote:
> Since we don't have the bits required to support this in OpenGLES yet,
> this only enables support for OpenGL 4.3.
I think the reference to GL 4.3 isn't quite right. Probably meant to
say "Desktop OpenGL". Also, one usually
This misses etnaviv, freedreno, swr, and virgl.
On Thu, Mar 23, 2017 at 11:27 AM, Lyude wrote:
> Signed-off-by: Lyude
> ---
> src/gallium/docs/source/screen.rst | 4
> src/gallium/drivers/i915/i915_screen.c | 1 +
>
On Thu, Mar 23, 2017 at 11:51 AM, tournier.elie wrote:
> Hello,
>
> It's seems impossible to expose all the drivers to soft fp64 with one
> piece of code.
> So what do you think about landing this series (with some fix) for r600?
>
> The other drivers will use the NIR
Hello,
It's seems impossible to expose all the drivers to soft fp64 with one
piece of code.
So what do you think about landing this series (with some fix) for r600?
The other drivers will use the NIR version of soft fp64.
BTW, an "alpha RFC" series is coming on the ML soonish.
Elie
On 13 March
Signed-off-by: Lyude
---
src/mesa/state_tracker/st_atom_rasterizer.c | 2 ++
src/mesa/state_tracker/st_extensions.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
b/src/mesa/state_tracker/st_atom_rasterizer.c
index
This enables support for the GL_NV_fill_rectangle extension on the
GM200+ for OpenGL 4.3.
Signed-off-by: Lyude
---
src/gallium/drivers/nouveau/nvc0/nvc0_3d.xml.h | 3 +++
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
src/gallium/drivers/nouveau/nvc0/nvc0_state.c
Signed-off-by: Lyude
---
src/gallium/include/pipe/p_defines.h | 1 +
src/gallium/include/pipe/p_state.h | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 0f0e260..7f781c4
Since we don't have the bits required to support this in OpenGLES yet,
this only enables support for OpenGL 4.3.
Signed-off-by: Lyude
---
src/mesa/main/api_validate.c | 13 +
src/mesa/main/extensions_table.h | 1 +
src/mesa/main/mtypes.h | 1 +
Signed-off-by: Lyude
---
src/gallium/docs/source/screen.rst | 4
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 +
Signed-off-by: Lyude
---
src/mapi/glapi/gen/gl_API.xml | 4
1 file changed, 4 insertions(+)
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index c1f0f8f..42d28f7 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@
This adds basic support for GL_NV_fill_rectangle in Gallium, along with
enabling it for the GM200+ in nouveau. It should be noted this only
implements the OpenGL 4.3 bits, since we don't have the features required
yet to add this for OpenGLES.
Lyude (6):
glapi: Add GL_NV_fill_rectangle
Hi,
On 23 March 2017 at 15:24, Jason Ekstrand wrote:
> Reviewed-by: Jason Ekstrand
>
> Please land soon so the old API can exist for as short a time as possible.
> :-)
Landed with such haste that I forgot to change the two of your Cc tags
to R-b. :(
Reviewed-by: Jason Ekstrand
Please land soon so the old API can exist for as short a time as possible.
:-)
On Thu, Mar 23, 2017 at 8:14 AM, Daniel Stone wrote:
> The actual offset returned is uint32_t, however int64_t was used as the
> return type
Series is
Reviewed-by: Jason Ekstrand
On Thu, Mar 23, 2017 at 2:32 AM, Iago Toral Quiroga
wrote:
> If we know the device has been lost we should return this error code for
> any command that can report it before we attempt to do anything with the
>
The actual offset returned is uint32_t, however int64_t was used as the
return type from gbm_bo_get_offset to allow negative returns to signal
errors to the caller.
In case of an error getting the offset, the user will also be unable to
get the handle/FD, and thus have nothing to offset into.
On Thu, Mar 23, 2017 at 2:32 AM, Iago Toral Quiroga
wrote:
> The Vulkan specs say:
>
>"A logical device may become lost because of hardware errors, execution
> timeouts, power management events and/or platform-specific events. This
> may cause pending and future
Hi,
On 23 March 2017 at 14:47, Jason Ekstrand wrote:
> On Thu, Mar 23, 2017 at 6:16 AM, Daniel Stone wrote:
>> Returning int64_t is annoying because the relevant interface demands
>> we need uint32_t, so we need to do casts in users. Given that the
>>
Am 23.03.2017 um 15:35 schrieb Leo Liu:
Workaround an unknown bug with inside the transfer_map for certain
ASIC, also tested with un-affected ASICs, the performance actually
improved slightly.
Signed-off-by: Leo Liu
Reviewed-by: Christian König
Workaround an unknown bug with inside the transfer_map for certain
ASIC, also tested with un-affected ASICs, the performance actually
improved slightly.
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 23 March 2017 at 00:21, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> REVIEWERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/REVIEWERS b/REVIEWERS
> index 40db33f67f..0b5d9a4fd3 100644
> --- a/REVIEWERS
> +++
I don't think this patch is needed. Just roll it into patch 3. With that,
the other two are
Reviewed-by: Jason Ekstrand
On Thu, Mar 23, 2017 at 5:55 AM, Iago Toral Quiroga
wrote:
> We need to know if sample shading has been requested during shader
>
On Thu, Mar 23, 2017 at 6:16 AM, Daniel Stone wrote:
> Hi,
>
> On 8 March 2017 at 05:31, Ben Widawsky wrote:
> > Unlike stride, there was no previous offset getter, so it can be right
> > on the first try.
> >
> > v2: Return EINVAL when plane is greater
Hi Ben,
On 24 January 2017 at 06:21, Ben Widawsky wrote:
> @@ -1018,9 +1018,18 @@ intel_from_planar(__DRIimage *parent, int plane, void
> *loaderPrivate)
> int width, height, offset, stride, dri_format, index;
> struct intel_image_format *f;
> __DRIimage
1 - 100 of 144 matches
Mail list logo