I'll post a corrected patch shortly, but first some answer to questions:
> Have you found an application that wants these extensions? That might
> be useful to describe in the commit message.
There are some occasional bits in Qt that uses HALF_FLOAT_OES for GLES2 (but I
stress it is not a often
On Tue, 2014-05-06 at 11:45 -0700, Matt Turner wrote:
> Nice work.
>
> On Tue, May 6, 2014 at 1:16 AM, Iago Toral Quiroga wrote:
> > diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
> > b/src/mesa/drivers/dri/i965/brw_shader.cpp
> > index 6e74803..37d3eab 100644
> > --- a/src/mesa/drivers/d
On 05.05.2014 22:39, Brian Paul wrote:
> On 05/03/2014 07:43 AM, Michel Dänzer wrote:
>> On 03.05.2014 22:29, Brian Paul wrote:
>>> The enum numbers were just cruft.
>>
>> I disagree. Nothing's changed about the reason I added them in the first
>> place: When a driver is queried for a cap it doesn'
Many instructions implicitly update the accumulator on Gen < 6. The instruction
scheduling code just calls add_barrier_deps() for each accumulator access on
these platforms, but a large class of operations don't actually update the
accumulator -- mostly move and logical instructions. Teaching the s
As I'm sending this extension bit by bit I thought I'd better list the
outstanding items. I've listed them in the order I'm planning to
implement them.
- update backends (gallium/i965) to support in/out arrays of arrays
- write some piglit tests to double check that the geom shaders front
end is c
Just to make reviewing a quick task. I thought I'd just point out the
reason updating this check is all that is needed to support packed
varyings is because lower_arraylike() and lower_rvalue() already
recursively call each other in inner array to outer array order so
everything just works.
Also
Add support for GLES2 extensions for floating point and half
floating point textures (GL_OES_texture_float, GL_OES_texture_half_float,
GL_OES_texture_float_linear and GL_OES_texture_half_float_linear).
---
src/mesa/main/extensions.c | 12 +-
src/mesa/main/glformats.c | 25
On Tue, May 6, 2014 at 7:32 PM, Eric Anholt wrote:
> Juha-Pekka Heikkila writes:
>
>> These patches allow MAD opcode to be used with pre gen6 hardware.
>> Instead of failing on emitting MAD there will be emitted MUL and ADD
>> to simulate MAD.
>>
>> I tried this with piglit on ILK (gen5) and did
On Tue, May 6, 2014 at 7:37 PM, Matt Turner wrote:
> On Tue, May 6, 2014 at 3:53 AM, Juha-Pekka Heikkila
> wrote:
>> Signed-off-by: Juha-Pekka Heikkila
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 15 ++-
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --g
From: José Fonseca
Port 5f493eed69f6fb11239c04119d602f1c23a68cbd from GLX.
---
src/gallium/state_trackers/wgl/stw_context.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/wgl/stw_context.c
b/src/gallium/state_trackers/wgl/stw_co
From: José Fonseca
We added wglCreateContextAttribsARB but not the extension strings.
This allows creation of GL 3.x contents.
---
src/gallium/state_trackers/wgl/stw_ext_extensionsstring.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/state_trackers/wgl/stw_ext_extensionsstr
This patch set mostly contains cosmetic changes that I made while adding
support for sample shading.
Marek Olšák (8):
r600g: simplify framebuffer state size computation
radeonsi: use DRAW_PREAMBLE on CIK
radeonsi: remove unused variable exports_ps in si_pipe_shader_ps
rade
From: Marek Olšák
Take the upper bound. The number doesn't have to absolutely correct, only safe.
---
src/gallium/drivers/r600/evergreen_state.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/g
From: Marek Olšák
The sample position is one of them.
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 60ade78..f8be0d
From: Marek Olšák
It's the same as setting the 3 regs separately, but shorter, and it also
seems to be required on GFX7.2 and later. This doesn't fix Hawaii.
---
src/gallium/drivers/radeonsi/si_state_draw.c | 13 -
src/gallium/drivers/radeonsi/sid.h | 1 +
2 files changed,
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 38
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 6c0cba7..0ecd317 100644
--- a/src/galli
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state_draw.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 315998c..fce799c 100644
--- a/src/gallium/driver
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 0ecd317..363218f 100644
--- a/src/gallium/drivers/radeon
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_hw_context.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c
b/src/gallium/drivers/radeonsi/si_hw_context.c
index 383157b..aa854d6 100644
--- a/src/gallium/drivers/r
https://bugs.freedesktop.org/show_bug.cgi?id=78393
Priority: medium
Bug ID: 78393
Assignee: mesa-dev@lists.freedesktop.org
Summary: Black "zebra" like lines while playing games on open
source drivers
Severity: normal
Clas
From: Marek Olšák
The sample positions are read from a constant buffer.
---
src/gallium/drivers/radeon/cayman_msaa.c | 17 +
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 10 ++
src/gallium/drivers/radeonsi/si_s
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 24
src/gallium/drivers/radeonsi/si_shader.h | 1 +
src/gallium/drivers/radeonsi/si_state.c | 2 ++
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader
From: Marek Olšák
Only for Cayman, SI, CIK.
---
src/gallium/drivers/r600/evergreen_state.c | 6 ++
src/gallium/drivers/radeon/cayman_msaa.c | 7 ++-
src/gallium/drivers/radeon/r600d_common.h | 3 +++
src/gallium/drivers/radeonsi/si_state.c| 6 ++
4 files changed, 13 insertions
This series adds support for ARB_sample_shading.
The problem is that enabling the SAMPLEMASK fragment shader output by setting
DB_SHADER_CONTROL.MASK_EXPORT_ENABLE hangs the GPU. The output is enabled in
the same way as the depth and stencil outputs. If anybody has an idea about
what I'm doing
From: Marek Olšák
This is how per-sample shading is enabled.
---
src/gallium/drivers/radeonsi/si_pipe.c | 2 ++
src/gallium/drivers/radeonsi/si_pipe.h | 4
src/gallium/drivers/radeonsi/si_state.c | 30 --
src/gallium/drivers/radeonsi/si_state.h | 1 +
4 file
From: Marek Olšák
---
docs/GL3.txt | 2 +-
docs/relnotes/10.3.html| 1 +
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index ea16e3f..0ed26bf 100644
--- a/docs/GL
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 440bcba..0195e54 100644
--- a/src/gallium/drivers/radeo
From: Marek Olšák
The other function will be split up from the framebuffer state.
---
src/gallium/drivers/r600/evergreen_state.c| 3 ++-
src/gallium/drivers/radeon/cayman_msaa.c | 26 +++---
src/gallium/drivers/radeon/r600_pipe_common.h | 4 +++-
src/gallium/driver
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 5bd3057..d0d9837 100644
--- a/src/gallium/drivers/rade
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 8
src/gallium/drivers/radeonsi/si_shader.h | 2 ++
src/gallium/drivers/radeonsi/si_state_draw.c | 18 --
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/radeo
On Wed, May 7, 2014 at 10:00 AM, Marek Olšák wrote:
> +static void si_set_min_samples(struct pipe_context *ctx, unsigned
> min_samples)
> +{
> + struct si_context *sctx = (struct si_context *)ctx;
> +
> + if (sctx->ps_iter_samples == min_samples)
> + return;
> +
> +
https://bugs.freedesktop.org/show_bug.cgi?id=78393
Andreas Boll changed:
What|Removed |Added
Attachment #98627|text/plain |image/png
mime type|
Am 06.05.2014 06:51, schrieb Patrick McMunn:
> I'm using some older hardware - an ATI Radeon 9200 - which can only
> handle up to OpenGL 1.2. I was wondering if it's possible to use the
> hardware renderer generally and have the driver hand off the handling of
> functions which my video card can't
On 05/07/2014 07:11 AM, jfons...@vmware.com wrote:
From: José Fonseca
Port 5f493eed69f6fb11239c04119d602f1c23a68cbd from GLX.
---
src/gallium/state_trackers/wgl/stw_context.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/wgl
https://bugs.freedesktop.org/show_bug.cgi?id=78393
incarnated...@gmail.com changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
Yeah, the sample positions in the fragment shader are always set
correctly even if there is no multisample buffer. It's implemented in
the patch which adds support for SAMPLEPOS.
Marek
On Wed, May 7, 2014 at 4:12 PM, Ilia Mirkin wrote:
> On Wed, May 7, 2014 at 10:00 AM, Marek Olšák wrote:
>> +s
On Wed, May 7, 2014 at 10:00 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> The sample positions are read from a constant buffer.
FWIW I had to do the same thing in both nv50 and nvc0. I had proposed
that this should actually be done directly by the state tracker, but I
think claims were made to
On 05/07/2014 01:33 AM, Michel Dänzer wrote:
On 05.05.2014 22:39, Brian Paul wrote:
On 05/03/2014 07:43 AM, Michel Dänzer wrote:
On 03.05.2014 22:29, Brian Paul wrote:
The enum numbers were just cruft.
I disagree. Nothing's changed about the reason I added them in the first
place: When a dri
On 08.05.2014 00:02, Brian Paul wrote:
> On 05/07/2014 01:33 AM, Michel Dänzer wrote:
>> On 05.05.2014 22:39, Brian Paul wrote:
>>> On 05/03/2014 07:43 AM, Michel Dänzer wrote:
On 03.05.2014 22:29, Brian Paul wrote:
> The enum numbers were just cruft.
I disagree. Nothing's change
I could enable interpolation of gl_FragCoord at the sample instead of
centroid and do:
gl_SamplePos = fract(gl_FragCoord.xy);
gl_FragCoord.xy = floor(gl_FragCoord.xy) + vec2(0.5); // center
However, I wouldn't be able to get gl_FragCoord at the centroid.
I'm also not sure how gl_FragCoord should
On Wed, May 7, 2014 at 11:56 AM, Marek Olšák wrote:
> I could enable interpolation of gl_FragCoord at the sample instead of
> centroid and do:
>
> gl_SamplePos = fract(gl_FragCoord.xy);
Is that legal? I didn't think that sample position could be an output,
at least not with ARB_sample_shading (an
It's a pseudo-code that would be inserted at the beginning of the
shader by the shader compiler. gl_SamplePos is always read-only from a
user's point of view.
Marek
On Wed, May 7, 2014 at 6:02 PM, Ilia Mirkin wrote:
> On Wed, May 7, 2014 at 11:56 AM, Marek Olšák wrote:
>> I could enable interpo
https://bugs.freedesktop.org/show_bug.cgi?id=78258
Ian Romanick changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
From: Roland Scheidegger
1c73e919a4b4dd79166d0633075990056f27fd28 made it possible to not allocate
the tgsi machine if llvm was used. However, draw_get_option_use_llvm() is
not reliable after draw context creation, since drivers can explicitly
request a non-llvm draw context even if draw_get_opti
On 05/07/2014 11:08 AM, srol...@vmware.com wrote:
From: Roland Scheidegger
1c73e919a4b4dd79166d0633075990056f27fd28 made it possible to not allocate
the tgsi machine if llvm was used. However, draw_get_option_use_llvm() is
not reliable after draw context creation, since drivers can explicitly
r
Am 07.05.2014 17:56, schrieb Marek Olšák:
> I could enable interpolation of gl_FragCoord at the sample instead of
> centroid and do:
>
> gl_SamplePos = fract(gl_FragCoord.xy);
> gl_FragCoord.xy = floor(gl_FragCoord.xy) + vec2(0.5); // center
>
> However, I wouldn't be able to get gl_FragCoord at
On 05/06/2014 02:33 AM, Ilia Mirkin wrote:
This only matters for TextureView where the texObj's target has not been
set yet, in all other instances, texObj->target should be the same as
the passed-in target parameter.
Signed-off-by: Ilia Mirkin
---
I ran into an assert in mesa/st when choosing
On Wed, May 7, 2014 at 10:00 AM, Marek Olšák wrote:
> This series adds support for ARB_sample_shading.
>
> The problem is that enabling the SAMPLEMASK fragment shader output by setting
> DB_SHADER_CONTROL.MASK_EXPORT_ENABLE hangs the GPU. The output is enabled in
> the same way as the depth and
On Tue, May 6, 2014 at 1:36 PM, Ilia Mirkin wrote:
> On Tue, May 6, 2014 at 1:29 PM, Roland Scheidegger wrote:
>> Am 06.05.2014 17:03, schrieb Ilia Mirkin:
>>> On Tue, May 6, 2014 at 10:48 AM, Roland Scheidegger
>>> wrote:
Looks good to me.
>>>
>>> Thanks!
>>>
Does that mean if also t
Matt Turner writes:
> The docs say that flipping this bit on for shaders that don't do SIMD
> branching (i.e., non-uniform control flow) will save us some power.
>
> An easy first step is turning this on when we don't see control flow.
>
> In the future with more infrastructure in place, we can d
https://bugs.freedesktop.org/show_bug.cgi?id=78403
Priority: medium
Bug ID: 78403
Keywords: regression
CC: emil.l.veli...@gmail.com, i...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: query_renderer_implementa
Sarah Sharp writes:
> Chromium defined a new GL extension (that isn't registered with Khronos).
> We need to add an EGL extension for it, so we can migrate ChromeOS on
> Intel systems to use EGL instead of GLX.
>
> http://git.chromium.org/gitweb/?p=chromium/src/third_party/khronos.git;a=commitdif
Am 07.05.2014 20:33, schrieb Ilia Mirkin:
> On Tue, May 6, 2014 at 1:36 PM, Ilia Mirkin wrote:
>> On Tue, May 6, 2014 at 1:29 PM, Roland Scheidegger
>> wrote:
>>> Am 06.05.2014 17:03, schrieb Ilia Mirkin:
On Tue, May 6, 2014 at 10:48 AM, Roland Scheidegger
wrote:
> Looks good to
1D array targets store the number of slices in the Height field.
Cc: "10.2 10.1 10.0"
Signed-off-by: Kenneth Graunke
---
src/mesa/main/fbobject.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index ca16ae1..97538bc 100644
--- a/src/mes
1D array targets store the number of slices in the Height field.
Fixes Piglit's spec/!OpenGL 3.2/layered-rendering/clear-color-all-types
1d_array single_level, at least when used with Meta clears.
Cc: "10.2 10.1 10.0"
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_wm_surface
https://bugs.freedesktop.org/show_bug.cgi?id=78403
--- Comment #1 from Emil Velikov ---
Created attachment 98641
--> https://bugs.freedesktop.org/attachment.cgi?id=98641&action=edit
glx/tests: Partially revert commit 51e3569573a7b3f8da0df093836761003fcdc414
Vinson, did you receive the email wi
On 8 May 2014 04:33, Ilia Mirkin wrote:
> On Tue, May 6, 2014 at 1:36 PM, Ilia Mirkin wrote:
>> On Tue, May 6, 2014 at 1:29 PM, Roland Scheidegger
>> wrote:
>>> Am 06.05.2014 17:03, schrieb Ilia Mirkin:
On Tue, May 6, 2014 at 10:48 AM, Roland Scheidegger
wrote:
> Looks good to m
>>>
>> Getting back on topic... what should I do? :) Check this in with the
>> new cap? Or just make it the default behaviour and let drivers that
>> can't handle it do the lowering in the driver? FWIW, I believe Dave
>> Airlie was against that, but that might have been because he was
>> implementi
On 05/07/2014 03:35 PM, Kenneth Graunke wrote:
1D array targets store the number of slices in the Height field.
Cc: "10.2 10.1 10.0"
Signed-off-by: Kenneth Graunke
---
src/mesa/main/fbobject.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbo
Reviewed-by: Marek Olšák
Marek
On Wed, May 7, 2014 at 11:35 PM, Kenneth Graunke wrote:
> 1D array targets store the number of slices in the Height field.
>
> Cc: "10.2 10.1 10.0"
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/main/fbobject.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> d
Series
Reviewed-by: Jordan Justen
On Wed, May 7, 2014 at 3:22 PM, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Wed, May 7, 2014 at 11:35 PM, Kenneth Graunke
> wrote:
>> 1D array targets store the number of slices in the Height field.
>>
>> Cc: "10.2 10.1 10.0"
>> Signed-off
On Wed, May 7, 2014 at 9:57 AM, Ilia Mirkin wrote:
> Should fix SGE/SSG instructions, which were previously getting integer
> 0/-1 values.
I hit the same issue on Maxwell. Soo...
>
> Signed-off-by: Ilia Mirkin
Reviewed-by: Ben Skeggs
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_g
Signed-off-by: Darren Salt
---
src/gallium/drivers/radeon/r600_buffer_common.c | 2 +-
src/gallium/drivers/radeon/r600_texture.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
This applies to master, 10.1, 10.2, probably older versions.
diff --git a/src/gallium/drivers/radeon/r6
So... this shader (from
generated_tests/spec/glsl-1.10/execution/built-in-functions/fs-op-eq-mat2-mat2.shader_test):
uniform mat2 arg0;
uniform mat2 arg1;
void main()
{
bool result = (arg0 == arg1);
gl_FragColor = vec4(result, 0.0, 0.0, 0.0);
}
Which becomes the following IR:
(
(declare (sh
Signed-off-by: Ilia Mirkin
---
src/gallium/auxiliary/tgsi/tgsi_text.c | 53 ++
1 file changed, 48 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c
b/src/gallium/auxiliary/tgsi/tgsi_text.c
index 2b2e7d5..7e50d8d 100644
--- a/src/ga
https://bugs.freedesktop.org/show_bug.cgi?id=78393
--- Comment #1 from Michel Dänzer ---
You mentioned on the xorg mailing list that this worked properly two months
ago, so there seems to have been a regression. Can you try bisecting, or at
least determining which versions of Mesa are broken / wo
On Wed, May 7, 2014 at 8:38 PM, Ilia Mirkin wrote:
> So... this shader (from
> generated_tests/spec/glsl-1.10/execution/built-in-functions/fs-op-eq-mat2-mat2.shader_test):
>
> uniform mat2 arg0;
> uniform mat2 arg1;
>
> void main()
> {
> bool result = (arg0 == arg1);
> gl_FragColor = vec4(resu
There were a few problems here, which mostly just broke layered
rendering into a view:
- Render target view extent was always set to be == depth. This is
benign for non-layered-rendering, but allows writes off the end of the
render target for layered rendering, which ends badly.
- Layered rend
Same issues as the previous commit fixed for Gen7:
- Bogus physical->logical layer conversion; depth/stencil surfaces
are still IMS layout on Gen8.
- mt_layer ignored in layered rendering case, which breaks handling
of views with MinLayer.
- Render target array extent not set correctly for arra
Here's a bunch of fixes for issues I noticed in color renderbuffer and
depthbuffer setup while reviewing Ken's patch to enable views on Gen8.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Fixing the same issues the previous commit does for Gen7.
Note that I can't test this one, since I don't have a Broadwell.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/src/mesa
Again, a few problems:
- Layered attachments did not honor MinLayer.
- Non-layered MSAA attachments rendered to the wrong layer due to
dividing by the layer count. All depth buffers use the IMS layout, so
the physical layer count == logical layer count.
- Layered attachments were not limited to
72 matches
Mail list logo
