On Fri, Jun 24, 2016 at 9:02 PM, Mark Janes wrote:
> On snb and ilk, this patch breaks
> piglit.spec.ext_image_dma_buf_import.ext_image_dma_buf_import-sample_nv1
>
> https://bugs.freedesktop.org/show_bug.cgi?id=96674
Looks like rebase fail to me.
>
> Jordan Justen writes:
>
> > Reported-by:
On snb and ilk, this patch breaks
piglit.spec.ext_image_dma_buf_import.ext_image_dma_buf_import-sample_nv1
https://bugs.freedesktop.org/show_bug.cgi?id=96674
Jordan Justen writes:
> Reported-by: Grazvydas Ignotas
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96607
> Signed-off-by: J
On Fri, 2016-06-24 at 10:07 +0200, Gregory Hainaut wrote:
> Code was inspired from _mesa_update_shader_textures_used
>
> However unlike _mesa_update_shader_textures_used that only check for
> a single
> stage, it will check all stages.
>
> It avoids to loop on all uniforms, only active samplers a
On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
>
> Signed-off-by: Rodrigo Vivi
> ---
> intel/intel_chipset.h | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/intel/intel_chipset.h b/intel/intel_chips
On Fri, 2016-06-24 at 22:06 +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> > The spec has been updated adding new PCI IDs.
> >
> > Signed-off-by: Rodrigo Vivi
> > ---
> > include/drm/i915_pciids.h | 3 +++
> > 1 file changed, 3 insertions(+)
> >
>
On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
>
> Signed-off-by: Rodrigo Vivi
> ---
> include/drm/i915_pciids.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 9094
On Fri, Jun 24, 2016 at 7:26 PM, Kenneth Graunke wrote:
> On Friday, June 24, 2016 7:03:35 PM PDT Ilia Mirkin wrote:
>> On Fri, Jun 24, 2016 at 6:41 PM, Kenneth Graunke
>> wrote:
>> > The only part of an ir_texture which can be an array is the
>> > offsets array in textureGatherOffsets() calls.
On Friday, June 24, 2016 7:03:35 PM PDT Ilia Mirkin wrote:
> On Fri, Jun 24, 2016 at 6:41 PM, Kenneth Graunke
> wrote:
> > The only part of an ir_texture which can be an array is the
> > offsets array in textureGatherOffsets() calls. We don't want
> > to lower those, because they're required to
On Fri, Jun 24, 2016 at 6:41 PM, Kenneth Graunke wrote:
> The only part of an ir_texture which can be an array is the
> offsets array in textureGatherOffsets() calls. We don't want
> to lower those, because they're required to remain constants.
>
> Fixes textureGatherOffsets with Gallium drivers
On Fri, 2016-06-24 at 22:42 +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> >
> > The spec has been updated adding new PCI IDs.
> >
> > Signed-off-by: Rodrigo Vivi
> > ---
> > intel/intel_chipset.h | 14 ++
> > 1 file changed, 10 inserti
The only part of an ir_texture which can be an array is the
offsets array in textureGatherOffsets() calls. We don't want
to lower those, because they're required to remain constants.
Fixes textureGatherOffsets with Gallium drivers such as llvmpipe,
which commit ef78df8d3b0cf540e5f08c8c2f6caa338b6
Signed-off-by: Jan Vesely
---
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index 21ac0d7..c68e1366 100644
--- a/src/galli
> On Mon, Jun 20, 2016 at 4:49 PM, Chad Versace
> wrote:
> > Emil, how do you test the Android build? I tried building i965 using
> > vanilla AOSP, but that turned into a long journey in yak shaving.
>
> Fun, isn't it. Here's cut-n-paste from my CI job that is tracks AOSP
>
Hi,
in this moment in
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 96622, which changed state.
Bug 96622 Summary: [radeonsi,apitrace] "Dreamfall Chapters: The longest
Journey" shows visual corruption
https://bugs.freedesktop.org/show_bug.cgi?id=96622
What|Removed
On 24 June 2016 at 20:15, Jason Ekstrand wrote:
>
>
> On Fri, Jun 24, 2016 at 11:59 AM, Emil Velikov
> wrote:
>>
>> From: Emil Velikov
>>
>> Do not rely on the git sha1:
>> - its current truncated form makes it less unique
>> - it does not attribute for local (Vulkand or otherwise) changes
>>
On Fri, Jun 24, 2016 at 11:59 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Do not rely on the git sha1:
> - its current truncated form makes it less unique
> - it does not attribute for local (Vulkand or otherwise) changes
>
> Use a timestamp produced at the time of build. It's perfectly u
On Fri, Jun 24, 2016 at 2:56 PM, Alejandro Piñeiro wrote:
> On 24/06/16 17:15, Ilia Mirkin wrote:
>> On Fri, Jun 24, 2016 at 10:42 AM, Alejandro Piñeiro
>> wrote:
>>>
>>> On 24/06/16 12:17, Nicolai Hähnle wrote:
Hi Alejandro,
>>> Hi, thanks for the quick answer, more comments below.
>>>
From: Emil Velikov
Do not rely on the git sha1:
- its current truncated form makes it less unique
- it does not attribute for local (Vulkand or otherwise) changes
Use a timestamp produced at the time of build. It's perfectly unique,
unless someone explicitly thinkers with their system clock. E
On 24/06/16 17:15, Ilia Mirkin wrote:
> On Fri, Jun 24, 2016 at 10:42 AM, Alejandro Piñeiro
> wrote:
>>
>> On 24/06/16 12:17, Nicolai Hähnle wrote:
>>> Hi Alejandro,
>> Hi, thanks for the quick answer, more comments below.
>>
>>> my understanding of the spec is that the test should be correct as
>
On Mon 20 Jun 2016, Jordan Justen wrote:
> Reported-by: Grazvydas Ignotas
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96607
> Signed-off-by: Jordan Justen
> Cc: Kristian Høgsberg
> Cc: "12.0"
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 15 ++-
> src/mes
On Fri, Jun 24, 2016 at 1:09 PM, Nicolai Hähnle wrote:
> On 22.06.2016 20:29, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> DCC for displayable surfaces is allocated in a separate buffer and is
>> enabled or disabled based on PS invocations from 2 frames ago (to let
>> queries go idle) and the
On Thu 16 Jun 2016, Emil Velikov wrote:
> On 16 June 2016 at 21:14, Haixia Shi wrote:
> > Emil
> >
> > I looked at commit 3689ef32 which started the problem, and it seems that
> > patch removed the line "touch git_sha1.h.tmp". Previously my workflow was
> > "working" because the touch command ensu
On Thu 23 Jun 2016, Ian Romanick wrote:
> ping
>
> *Before* 12.0 ships, we must either land this patch or a patch that
> redacts the GLES 3.1 functions (e.g., glDispatchCompute) that we already
> statically export.
Pong. Yes, please do this.
Yes, this sucks (for Linux ABI conventions). The alter
On 24 June 2016 at 18:15, Jason Ekstrand wrote:
> On Fri, Jun 24, 2016 at 10:13 AM, Emil Velikov
> wrote:
>>
>> From: Emil Velikov
>>
>> As mentioned by the spec (and used by Archlinux and Debian) default to
>> ${datarootdir} as opposed to ${sysconfdir} for the default location.
>
>
> Just to co
On Fri, Jun 24, 2016 at 10:15 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Do not rely on the git sha1:
> - its current truncated form makes it less unique
> - it does not attribute for local (Vulkand or otherwise) changes
>
> Use a timestamp produced at the time of build. It's perfectly u
On Fri, Jun 24, 2016 at 10:13 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> As mentioned by the spec (and used by Archlinux and Debian) default to
> ${datarootdir} as opposed to ${sysconfdir} for the default location.
>
Just to confirm, that is /usr/share/ or ~/.local/share, right?
>
> Cc:
From: Emil Velikov
Do not rely on the git sha1:
- its current truncated form makes it less unique
- it does not attribute for local (Vulkand or otherwise) changes
Use a timestamp produced at the time of build. It's perfectly unique,
unless someone explicitly thinkers with their system clock. E
From: Emil Velikov
As mentioned by the spec (and used by Archlinux and Debian) default to
${datarootdir} as opposed to ${sysconfdir} for the default location.
Cc: Jason Ekstrand
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
I believe there was an earlier agreement about
On 06/22/2016 05:44 PM, Boyuan Zhang wrote:
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vce.c| 4 +
src/gallium/drivers/radeon/radeon_vce.h| 17 +
src/gallium/drivers/radeon/radeon_vce_40_2_2.c | 4 +
src/gallium/drivers/radeon/radeon_vce_50.c
On 20 June 2016 at 19:14, Ian Romanick wrote:
> On 06/17/2016 11:15 AM, Emil Velikov wrote:
>> On 17 June 2016 at 18:20, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> Khronos recommends that the GLES 3.1 library also be called libGLESv2.
>>> It also requires that functions be statically lin
From: Marek Olšák
ported from Vulkan
---
src/gallium/drivers/radeonsi/si_state_draw.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 717149b..5f866d5 100644
--- a
On Fri, Jun 24, 2016 at 11:59 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Otherwise, 1x1 images of arbitrarily high level are accepted.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96639#add_comment
Please nuke the #add_comment bit. With that,
Reviewed-by: Ilia Mirkin
>
From: Nicolai Hähnle
Otherwise, 1x1 images of arbitrarily high level are accepted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96639#add_comment
Cc: 11.2 12.0
---
src/mesa/state_tracker/st_texture.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/state_tracker/st_t
Reviewed-by: Ilia Mirkin
That makes sense. Thanks for looking into it!
On Fri, Jun 24, 2016 at 10:39 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Fixes a regression introduced by commit 42624ea83 which triggered
> an assertion in
> dEQP-GLES2.functional.texture.completeness.cube.not_po
On Fri, Jun 24, 2016 at 10:43 AM, Brian Paul wrote:
> This indicates the alpha channel of the surface should always be one.
> Drivers can use this to adjust blending terms when needed.
>
> v2: also check for R, RG, LUMINANCE surfaces, per Ilia
> ---
> src/mesa/state_tracker/st_cb_fbo.c | 9 ++
On Fri, Jun 24, 2016 at 10:42 AM, Alejandro Piñeiro
wrote:
>
>
> On 24/06/16 12:17, Nicolai Hähnle wrote:
>> Hi Alejandro,
>
> Hi, thanks for the quick answer, more comments below.
>
>>
>> my understanding of the spec is that the test should be correct as
>> originally written, i.e. with glTexture
On 24.06.2016 16:40, Brian Paul wrote:
On 06/24/2016 03:56 AM, Nicolai Hähnle wrote:
On 24.06.2016 04:07, Brian Paul wrote:
If the user requests an RGB drawing surface but we actually create an
RGBA surface, we need it to act as if A=1. For blending, this means
adjusting the blending terms to
On 24.06.2016 16:42, Alejandro Piñeiro wrote:
On 24/06/16 12:17, Nicolai Hähnle wrote:
Hi Alejandro,
Hi, thanks for the quick answer, more comments below.
my understanding of the spec is that the test should be correct as
originally written, i.e. with glTextureBarrier only between full
re
On 24.06.2016 16:11, Nicolai Hähnle wrote:
Are you sure this is Polaris-specific? I see a mention of this 14/30 as
well, but it seems to apply to all of gfx8.
Never mind, I didn't look closely enough. R-b for this patch as well.
Nicolai
The rest of this series is
Reviewed-by: Nicolai Hähnl
For what formats is this really needed? I think that usually if you have
a rgb surface, the corresponding rgbx format should be used instead of
rgba (which implicitly has the alpha == 1 property for blending). But
maybe some formats are missing...
Roland
Am 24.06.2016 um 04:07 schrieb Brian Paul
This indicates the alpha channel of the surface should always be one.
Drivers can use this to adjust blending terms when needed.
v2: also check for R, RG, LUMINANCE surfaces, per Ilia
---
src/mesa/state_tracker/st_cb_fbo.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/stat
On 24/06/16 12:17, Nicolai Hähnle wrote:
> Hi Alejandro,
Hi, thanks for the quick answer, more comments below.
>
> my understanding of the spec is that the test should be correct as
> originally written, i.e. with glTextureBarrier only between full
> rectangle draws.
>
> FWIW, radeonsi passes t
https://bugs.freedesktop.org/show_bug.cgi?id=96629
--- Comment #4 from Nicolai Hähnle ---
I think the correct solution is just to guard this particular call to
guess_and_alloc_texture accordingly. See
https://patchwork.freedesktop.org/patch/95080/
--
You are receiving this mail because:
You are
From: Nicolai Hähnle
Fixes a regression introduced by commit 42624ea83 which triggered
an assertion in
dEQP-GLES2.functional.texture.completeness.cube.not_positive_level_0
While stImage must have a non-zero size as verified by the caller, we also
look at the size of the base image in an attempt
On 06/24/2016 03:56 AM, Nicolai Hähnle wrote:
On 24.06.2016 04:07, Brian Paul wrote:
If the user requests an RGB drawing surface but we actually create an
RGBA surface, we need it to act as if A=1. For blending, this means
adjusting the blending terms to use 1/0 instead of
DST_ALPHA/INV_DST_ALP
On Fri, Jun 24, 2016 at 10:33 AM, Brian Paul wrote:
> On 06/23/2016 08:14 PM, Ilia Mirkin wrote:
>>
>> Isn't this true for any-non-alpha-having format? I.e. _BaseFormat !=
>> GL_RGBA && _BaseFormat != GL_ALPHA && _BaseFormat !=
>> GL_LUMINANCE_ALPHA && _BaseFormat != GL_INTENSITY? (Not sure about
On 06/23/2016 08:14 PM, Ilia Mirkin wrote:
Isn't this true for any-non-alpha-having format? I.e. _BaseFormat !=
GL_RGBA && _BaseFormat != GL_ALPHA && _BaseFormat !=
GL_LUMINANCE_ALPHA && _BaseFormat != GL_INTENSITY? (Not sure about
that last one tbh.)
One would also have to check for GL_DEPTH,
On Fri, Jun 24, 2016 at 1:10 PM, Nicolai Hähnle wrote:
> I remember there was a plausible reason to have a dcc_offset instead of just
> a dcc_address (though I keep forgetting it), but maybe it's time to change
> that now?
Yeah I think having dcc_address would now be more convenient, but I
don't
Hi Andy,
Thanks for testing the patches.
I have made some changes with which hqscaling=0 should work fine. But I
don't know
how to set pillar boxes to black. Do you have some idea how this could be
done?
Any suggestions Christian?
Regards,
Nayan.
On Fri, Jun 24, 2016 at 4:57 AM, Andy Furniss
Same deal on nouveau. This is the TGSI:
FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL IN[0], POSITION, LINEAR
DCL OUT[0], COLOR
DCL SAMP[0]
DCL SVIEW[0], 2D, FLOAT
DCL CONST[5]
DCL CONST[0..3]
DCL TEMP[0]
DCL TEMP[1..2], LOCAL
IMM[0] INT32 {0, 0, 0, 0}
0: MOV TEMP[0], IN[0]
1: MAD TEMP[0].y,
Are you sure this is Polaris-specific? I see a mention of this 14/30 as
well, but it seems to apply to all of gfx8.
The rest of this series is
Reviewed-by: Nicolai Hähnle
On 24.06.2016 14:15, Marek Olšák wrote:
From: Marek Olšák
ported from Vulkan (and no source explains why this is needed
On Fri, Jun 24, 2016 at 3:27 AM, Nicolai Hähnle wrote:
> On 24.06.2016 04:32, Ilia Mirkin wrote:
>>
>> Under some circumstances, the driver may choose to return a temporary
>> surface instead of a pointer to the original. Make sure to pass the
>> actual view volume to be mapped to the transfer fun
Am 24.06.2016 um 14:46 schrieb Ilia Mirkin:
On Fri, Jun 24, 2016 at 8:39 AM, Christian König
wrote:
Ilia and/or maybe other nouveau developers: You guys don't have any plans to
expose the NVidia encoding functionality through the OpenMAX/VA-API state
trackers in the near future don't you?
Not
On Fri, Jun 24, 2016 at 8:39 AM, Christian König
wrote:
> Ilia and/or maybe other nouveau developers: You guys don't have any plans to
> expose the NVidia encoding functionality through the OpenMAX/VA-API state
> trackers in the near future don't you?
Not in the near future, no. As far as I'm awa
On 06/24/2016 02:39 PM, Christian König wrote:
+if (pic->enable_low_level_control == true) {
Well using this enable_low_level_control switch to choose between two
sets of hardcoded values is clearly a no go.
For the motion estimation and most of the other flags I would say just
try to ex
+ if (pic->enable_low_level_control == true) {
Well using this enable_low_level_control switch to choose between two
sets of hardcoded values is clearly a no go.
For the motion estimation and most of the other flags I would say just
try to expose the parameters we have in the hardware
From: Marek Olšák
the kernel sets them, but other UMDs can change them
---
src/gallium/drivers/radeonsi/si_state.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index d12c89b..7e09c8d 100644
--- a/src/gal
From: Marek Olšák
radeonsi will set more fields
---
src/gallium/drivers/r600/evergreen_state.c| 7 ++-
src/gallium/drivers/radeon/cayman_msaa.c | 12 +---
src/gallium/drivers/radeon/r600_pipe_common.h | 3 ++-
src/gallium/drivers/radeonsi/si_state.c | 6 +-
4 fi
From: Marek Olšák
ported from Vulkan (and no source explains why this is needed)
Cc: 12.0
---
src/gallium/drivers/radeonsi/si_hw_context.c | 1 +
src/gallium/drivers/radeonsi/si_pipe.h | 1 +
src/gallium/drivers/radeonsi/si_state.c | 3 ++-
src/gallium/drivers/radeonsi/si_state_d
From: Marek Olšák
ported from Vulkan
Cc: 12.0
---
src/gallium/drivers/radeonsi/si_compute.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 2f7e172..f19e830 100644
--- a/src/gal
From: Marek Olšák
loosely ported from Vulkan
---
src/gallium/drivers/radeonsi/si_pipe.h | 1 +
src/gallium/drivers/radeonsi/si_state.c | 12 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h
b/src/gallium/drivers/radeonsi/si_pip
From: Marek Olšák
ported from Vulkan
---
src/gallium/drivers/radeonsi/si_state.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index f5da153..df188dd 100644
--- a/src/gallium/driv
From: Marek Olšák
Nothing in the GL spec says that we should expand points to triangles.
---
src/gallium/drivers/r600/evergreen_state.c | 1 -
src/gallium/drivers/r600/r600_state.c | 1 -
src/gallium/drivers/radeonsi/si_state.c| 1 -
3 files changed, 3 deletions(-)
diff --git a/src/gal
I remember there was a plausible reason to have a dcc_offset instead of
just a dcc_address (though I keep forgetting it), but maybe it's time to
change that now?
Either way, patches 1-4 & 6 are
Reviewed-by: Nicolai Hähnle
On 22.06.2016 20:29, Marek Olšák wrote:
From: Marek Olšák
---
src
On 22.06.2016 20:29, Marek Olšák wrote:
From: Marek Olšák
DCC for displayable surfaces is allocated in a separate buffer and is
enabled or disabled based on PS invocations from 2 frames ago (to let
queries go idle) and the number of slow clears from the current frame.
At least an equivalent of
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 24, 2016 at 1:42 AM, Nicolai Hähnle wrote:
> Hi,
>
> I'm sending out two changes for Polaris support that should still go into
> 12.0 (fingers crossed that that's it :-)).
>
> Note that the DRAW_PREAMBLE change should really be applica
Pushed, thanks.
Marek
On Thu, Jun 23, 2016 at 7:56 PM, Francesco Ansanelli
wrote:
> ---
> src/mesa/state_tracker/st_cb_fbo.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_fbo.c
> b/src/mesa/state_tracker/st_cb_fbo.c
> index a53b95a..95
Reviewed-by: Marek Olšák
Marek
On Wed, Jun 22, 2016 at 10:14 PM, Axel Davy wrote:
> Emit PA_SU_POLY_OFFSET_DB_FMT_CNTL with the other poly_offset states.
> This will be useful to implement
> PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED.
>
> v2: Increase the num_dw field for the poly offset atom
>
> S
Reviewed-by: Marek Olšák
Marek
On Wed, Jun 22, 2016 at 10:13 PM, Axel Davy wrote:
> Emit PA_SU_POLY_OFFSET_DB_FMT_CNTL with the other poly_offset states.
> This will be useful to implement
> PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED.
>
> v2: Increase the num_dw field for the poly offset atom
>
> S
Pushed, thanks.
Marek
On Thu, Jun 16, 2016 at 1:41 AM, Jan Vesely wrote:
> v2: Merge with PIPE_SHADER_CAP_DOUBLES
> Add CHIP_HEMLOCK
>
> v3: only set the instruction on EG and CM
>
> Signed-off-by: Jan Vesely
> ---
> src/gallium/drivers/r600/r600_pipe.c | 8 +---
> src/gallium/driver
On 24 June 2016 at 03:32, Michel Dänzer wrote:
> On 23.06.2016 22:25, Emil Velikov wrote:
>> On 23 June 2016 at 03:49, Michel Dänzer wrote:
>>> On 22.06.2016 21:04, Emil Velikov wrote:
From: Emil Velikov
Do not rely on the git sha1:
- its current truncated form makes it less
Hi Alejandro,
my understanding of the spec is that the test should be correct as
originally written, i.e. with glTextureBarrier only between full
rectangle draws.
FWIW, radeonsi passes the test as-is (though I reduced the GLSL version
requirement, which I'd ask you to change as well before y
On 24 June 2016 at 03:59, Dave Airlie wrote:
> On 23 June 2016 at 23:25, Emil Velikov wrote:
>> On 23 June 2016 at 03:49, Michel Dänzer wrote:
>>> On 22.06.2016 21:04, Emil Velikov wrote:
From: Emil Velikov
Do not rely on the git sha1:
- its current truncated form makes it
On 24.06.2016 04:07, Brian Paul wrote:
If the user requests an RGB drawing surface but we actually create an
RGBA surface, we need it to act as if A=1. For blending, this means
adjusting the blending terms to use 1/0 instead of DST_ALPHA/INV_DST_ALPHA.
Drivers can use this flag to determine when
Gets the test passing for cases with low resolution, high amount
of triangles and more than one glDrawRangeElements (drawing_passes).
---
Just to catch attention, this issue also affects the failing CTS test
GL44-CTS.texture_barrier_ARB.same-texel-rw-multipass on Intel gen7+.
And sorry for the cr
For both:
Reviewed-by: Nicolai Hähnle
On 22.06.2016 15:13, Marek Olšák wrote:
From: Marek Olšák
- make sure FP32 denormals will stay disabled in LLVM in the future
(the current default is disabled)
- tell LLVM that FP64 denormals are enabled
---
src/gallium/drivers/radeonsi/si_pipe.c |
Code was inspired from _mesa_update_shader_textures_used
However unlike _mesa_update_shader_textures_used that only check for a single
stage, it will check all stages.
It avoids to loop on all uniforms, only active samplers are checked.
Signed-off-by: Gregory Hainaut
---
src/mesa/main/uniform_
I noticed a small number of places where true/false are assigned to
booleans that are still in the Gallium interfaces:
- uses of DEBUG_GET_ONCE_BOOL_OPTION
- timestamp_disjoint.disjoint
... but then if those weren't changed now, it'd just cause
inconsistencies later when the Gallium interface
Reviewed-by: Nicolai Hähnle
On 23.06.2016 00:03, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/radeon_llvm.h | 3 +++
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 28 --
2 files changed, 29 insertions(+), 2 deletions(-)
diff --
On 23.06.2016 00:35, Marek Olšák wrote:
On Thu, Jun 23, 2016 at 12:29 AM, Marek Olšák wrote:
On Tue, Jun 21, 2016 at 4:47 PM, Nicolai Hähnle wrote:
On 21.06.2016 14:17, Marek Olšák wrote:
Hi,
This improves u_queue to be more usable in more cases.
With this, the size of the queue (maximum
On 24.06.2016 04:32, Ilia Mirkin wrote:
Under some circumstances, the driver may choose to return a temporary
surface instead of a pointer to the original. Make sure to pass the
actual view volume to be mapped to the transfer function rather than
adjusting the map pointer after-the-fact.
I'm cu
81 matches
Mail list logo
