On Mon, Aug 11, 2014 at 11:18:36PM -0700, Ben Widawsky wrote:
> On Mon, Aug 11, 2014 at 10:40:25PM -0700, Kenneth Graunke wrote:
> > On Monday, August 11, 2014 07:53:11 PM Ben Widawsky wrote:
> > > On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
> > [snip]
> > > > diff --git a/sr
On Mon, Aug 11, 2014 at 10:40:25PM -0700, Kenneth Graunke wrote:
> On Monday, August 11, 2014 07:53:11 PM Ben Widawsky wrote:
> > On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
> [snip]
> > > diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c
> > > b/src/mesa/drivers/dri/i9
On Mon, Aug 11, 2014 at 10:48:49PM -0700, Kenneth Graunke wrote:
> On Monday, August 11, 2014 05:29:31 PM Kristian Høgsberg wrote:
> > Right now we decide which kernels to use and the GRF start offsets in
> > one place and emit the kernel pointers later. The logic of how to map
> > 8, 16 and 32 ke
On Monday, August 11, 2014 05:29:38 PM Kristian Høgsberg wrote:
> This matches the name of the dd hook. Also convert a couple of nearby
> dd implementations to lowercase + underscore as is now the standard.
>
> Signed-off-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 1
On Monday, August 11, 2014 05:29:31 PM Kristian Høgsberg wrote:
> Right now we decide which kernels to use and the GRF start offsets in
> one place and emit the kernel pointers later. The logic of how to map
> 8, 16 and 32 kernels to kernel start pointers follows the same logic as which
> GRF star
On Mon, Aug 11, 2014 at 08:46:23PM -0400, Ilia Mirkin wrote:
> On Mon, Aug 11, 2014 at 8:29 PM, Kristian Høgsberg wrote:
> > diff --git a/src/mesa/drivers/dri/i965/intel_tex_copy.c
> > b/src/mesa/drivers/dri/i965/intel_tex_copy.c
> > index 97f1569..2456080 100644
> > --- a/src/mesa/drivers/dri/i9
On Mon, Aug 11, 2014 at 08:21:29PM -0700, Ben Widawsky wrote:
> On Mon, Aug 11, 2014 at 05:29:34PM -0700, Kristian Høgsberg wrote:
> > The brw_draw_prims() function is the draw entry point into the driver,
> > and takes struct _mesa_prim for input. We want to be able to feed
> > native primitives
On Monday, August 11, 2014 07:53:11 PM Ben Widawsky wrote:
> On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
[snip]
> > diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c
> > b/src/mesa/drivers/dri/i965/gen8_ps_state.c
> > index 3d6d7f0..f58d49c 100644
> > --- a/src/mesa/dri
On Mon, Aug 11, 2014 at 08:08:33PM -0700, Ben Widawsky wrote:
> On Mon, Aug 11, 2014 at 05:29:32PM -0700, Kristian Høgsberg wrote:
> > For now, this can only be triggered with a new 'no8' INTEL_DEBUG option
> > and a new context flag. We'll use the context flag later, but introducing
> > it now le
On Monday, August 11, 2014 11:22:22 AM Matt Turner wrote:
> Comparing ~0u with a packed enum (i.e., 1 byte) always evaluates to
> false. Shouldn't gcc warn about this?
>
> Reported-by: Connor Abbott
Looks good to me.
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally
On Mon, Aug 11, 2014 at 07:53:11PM -0700, Ben Widawsky wrote:
> On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
> > Right now we decide which kernels to use and the GRF start offsets in
> > one place and emit the kernel pointers later. The logic of how to map
> > 8, 16 and 32 ke
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 --
src/mesa/drivers/dri/i965/brw_vec4.cpp| 12 +++-
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 12 +++-
3 files changed, 10 insertions(+), 28 deletions(-)
d
According to the documentation, we need to set the source 0 register
type to IMM for flow control instructinos that have both JIP and UIP.
Out of paranoia, just make all flow control instructions use IMM;
there's no benefit to using ARF anyway, and it could trouble that's
difficult to diagnose.
Se
Kind of a moot point since we're deleting Gen8 code generation, but
this at least helps make it match the Gen4-7 code. It's probably more
reasonable than using float.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 6 --
src/mesa/drivers/dri/i965/gen8_
On Haswell, we implement "discard" via predicated SEND messages, using
f0.1 instead of f0.0. To accomplish this, we set inst->flag_subreg to 1
on the FS_OPCODE_FB_WRITE.
Most instructions using fs_inst::flag_subreg expand to a single assembly
instruction. However, FS_OPCODE_FB_WRITE can generate
When we combine the Gen4-7 and Gen8+ generators, we'll need to handle
half float packing/unpacking functions somehow. The Gen8+ generator
code today just emulates the behavior of the Gen7 F32TO16/F16TO32
instructions, including the align16 mode bugs.
Rather than messing with fs_generator/vec4_gen
Everything should be in place to unify code generation between Gen4-7
and Gen8+. We should be able to drop the Gen8 generators at this point.
However, leave them hooked up for a brief moment, for testing and
comparison purposes. Set GEN8=1 to use the old Gen8+ code generator
paths.
Signed-off-b
g0.5 has nothing of value to contribute to m0.5. In both the VS and GS
payload, g0.5 contains the scratch space pointer - which is definitely
not of any use. The GS payload also contains FFTID, but the URB write
message header doesn't want FFTID.
The only reason I used OR was because Eric origin
Signed-off-by: Kenneth Graunke
Cc: "10.2"
---
src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
index db66d68..bf904c6 100644
--- a/src/mesa/
Hello,
This series finishes getting Broadwell to use brw_eu_emit.c, and finally
kills off gen8_*_generator.* and gen8_instruction.*. The diffstat is
quite encouraging:
16 files changed, 147 insertions(+), 4152 deletions(-)
While doing this work, I've been diffing the assembly generated via b
This improves performance in Trine 2 at 1280x720 (windowed) on "Very
High" settings by 30% (in the interactive menu) to 45% (in the forest
by the giant frog) on Haswell GT3e.
It also now generates the same assembly on Gen7 as it does on Gen8,
which always used the sampler for both types.
Signed-o
Broadwell requires the number of vertices written by the geometry shader
to be specified in a separate register, as part of the terminating
message's payload.
This also means GS_OPCODE_THREAD_END needs to increment mlen.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_gene
Either should work.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
index bf904c6
We're going to add a Gen8+ case shortly, which would need to duplicate
this code again. Instead, share it.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drive
I don't see any reason for this to exist.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index c56f479..c63
Signed-off-by: Kenneth Graunke
Cc: "10.2"
---
src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp
index 6951f88..db66d68 100
On Mon, Aug 11, 2014 at 7:39 PM, Anuj Phogat wrote:
> Matt, should I consider both of these r-b you?
Yes.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Aug 11, 2014 at 05:29:34PM -0700, Kristian Høgsberg wrote:
> The brw_draw_prims() function is the draw entry point into the driver,
> and takes struct _mesa_prim for input. We want to be able to feed
> native primitives into the driver, and to that end we introduce
> BRW_PRIM_OFFSET, which
On Mon, Aug 11, 2014 at 05:29:32PM -0700, Kristian Høgsberg wrote:
> For now, this can only be triggered with a new 'no8' INTEL_DEBUG option
> and a new context flag. We'll use the context flag later, but introducing
> it now lets us bisect to this commit if it breaks something.
>
> Signed-off-by
On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
> Right now we decide which kernels to use and the GRF start offsets in
> one place and emit the kernel pointers later. The logic of how to map
> 8, 16 and 32 kernels to kernel start pointers follows the same logic as which
> GRF s
On Tue, Jul 29, 2014 at 3:08 PM, Anuj Phogat wrote:
> On Tue, Jul 29, 2014 at 7:18 AM, Matt Turner wrote:
> >
> > On Mon, Jul 28, 2014 at 8:47 PM, Anuj Phogat
> wrote:
> > > Fixes Khronos GLES3 CTS test:
> > > dynamic_expression_array_access_vertex
> > >
> > > Cc:
> > > Signed-off-by: Anuj Pho
I agree. I just sent this patch to focus attention on this issue (Bug 82463).
- Pavel
-Original Message-
From: Kenneth Graunke [mailto:kenn...@whitecape.org]
Sent: Monday, August 11, 2014 11:32 PM
To: mesa-dev@lists.freedesktop.org
Cc: Popov, Pavel E
Subject: Re: [Mesa-dev] [PATCH] i965:
On Mon, Aug 11, 2014 at 4:32 PM, Eric Anholt wrote:
> Connor Abbott writes:
>
>> On Wed, Aug 6, 2014 at 6:29 PM, Marek Olšák wrote:
>>> What IR? A flatland GLSL IR? A replacement for Mesa IR? Something else?
>>
>> It's a flatland IR, similar to TGSI/Direct3D style with enough GLSL
>> IR-like stu
https://bugs.freedesktop.org/show_bug.cgi?id=81680
Michel Dänzer changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 47
src/mesa/drivers/dri/i965/brw_shader.h | 5
2 files changed, 52 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 53545de..3de7ad9 100644
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 46
src/mesa/drivers/dri/i965/brw_shader.h | 4 +++
2 files changed, 50 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 0deb090..53545de 100644
On Mon, Aug 11, 2014 at 8:29 PM, Kristian Høgsberg wrote:
> diff --git a/src/mesa/drivers/dri/i965/intel_tex_copy.c
> b/src/mesa/drivers/dri/i965/intel_tex_copy.c
> index 97f1569..2456080 100644
> --- a/src/mesa/drivers/dri/i965/intel_tex_copy.c
> +++ b/src/mesa/drivers/dri/i965/intel_tex_copy.c
No functional change except for glBegin/glEnd style rendering, where we now
do the resolves at glBegin time instead of FLUSH_VERTICES time. This is also
the reason for this change, so that when we later switch fast clear resolve to
use meta, we won't be doing meta operations in the middle of a beg
This lets us disable the viewport transform, which will be useful for
emitting 3DPRIM_RECTLIST.
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/gen6_sf_state.c | 5 +++--
src/mesa/dri
We'll use this in the i965 fast clear implementation.
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/common/meta.c | 6 +++---
src/mesa/drivers/common/meta.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/me
GetTexParamterfv() doesnt change texture state, so instead of
_mesa_lock_texture() we can use _mesa_lock_context_textures(),
which doesn't increase the texture stamp. With this change,
_mesa_update_state_locked() is now only called from under
_mesa_lock_context_textures(), which is right thing to
This patch uses the infrastructure put in place by previous patches
to implement fast color clears and replicated color clears in terms of
meta operations.
This works all the way back to gen7 where fast clear was introduced and
adds support for fast clear on gen8. It replaces the blorp path
compl
GEN7+ has the fast clear functionality, which lets us clear the color
buffers using the MCS and a scaled down rectangle. To enable this
we have to set the appropriate bits in the 3DSTATE_PS package.
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/d
The clipper doesn't support clipping 3DPRIM_RECTLIST primitives and must
be turned off when we use them.
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/i965/gen6_clip_state.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_clip
The brw_draw_prims() function is the draw entry point into the driver,
and takes struct _mesa_prim for input. We want to be able to feed
native primitives into the driver, and to that end we introduce
BRW_PRIM_OFFSET, which lets use describe geometry using the native
GEN primitive types.
Signed-o
Right now we decide which kernels to use and the GRF start offsets in
one place and emit the kernel pointers later. The logic of how to map
8, 16 and 32 kernels to kernel start pointers follows the same logic as which
GRF start offsets to use, so lets figure out these two things in one place.
Sig
The data port has a SIMD16 'replicate data' message, which lets us write
the same color for all 16 pixels by sending the four floats in the
lower half of a register instead of sending 4 times 16 identical
component values in 8 registers.
The message comes with a lot of restrictions and could be ma
This matches the name of the dd hook. Also convert a couple of nearby
dd implementations to lowercase + underscore as is now the standard.
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/i965/brw_context.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
This patch series implements the fast clear feature using meta operations.
This series consists of a series of patches that add bits and pieces of
infrastructure to control the custom state and the final patch uses all those
to implement color fast clear and resolve.
The big ugly problem with doin
For now, this can only be triggered with a new 'no8' INTEL_DEBUG option
and a new context flag. We'll use the context flag later, but introducing
it now lets us bisect to this commit if it breaks something.
Signed-off-by: Kristian Høgsberg
---
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
Connor Abbott writes:
> On Wed, Aug 6, 2014 at 6:29 PM, Marek Olšák wrote:
>> What IR? A flatland GLSL IR? A replacement for Mesa IR? Something else?
>
> It's a flatland IR, similar to TGSI/Direct3D style with enough GLSL
> IR-like stuff to get existing things working now and enable us to
> even
On Monday 11 August 2014, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of
> GL4.5?
>
> docs/GL3.txt | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> in
On 11/08/14 06:56 PM, Brian Paul wrote:
On 08/11/2014 04:51 PM, Nathan Kidd wrote:
Previously we'd get a GLXBadPixmap error.
Signed-off-by: Nathan Kidd
---
src/xdemos/glxgears_pixmap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/xdemos/glxgears_pixmap.c b/src/
On 08/11/2014 04:51 PM, Nathan Kidd wrote:
Previously we'd get a GLXBadPixmap error.
Signed-off-by: Nathan Kidd
---
src/xdemos/glxgears_pixmap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/xdemos/glxgears_pixmap.c b/src/xdemos/glxgears_pixmap.c
index f2bb013..a
Previously we'd get a GLXBadPixmap error.
Signed-off-by: Nathan Kidd
---
src/xdemos/glxgears_pixmap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/xdemos/glxgears_pixmap.c b/src/xdemos/glxgears_pixmap.c
index f2bb013..afd5828 100644
--- a/src/xdemos/glxgears_pixmap
https://bugs.freedesktop.org/show_bug.cgi?id=82483
Priority: medium
Bug ID: 82483
Keywords: regression
CC: ja...@jlekstrand.net
Assignee: mesa-dev@lists.freedesktop.org
Summary: format_srgb.h:145: undefined reference to
I've just made my pass over the stable queue and pushed out a new
candidate branch for the upcoming 10.2.6 release. You can see the 25
patches included (and the 42 still awaiting review) here:
http://cworth.org/~cworth/mesa-stable-queue/
As usual, I plan to make the next stable release on
https://bugs.freedesktop.org/show_bug.cgi?id=82475
Jason Ekstrand changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Am 11.08.2014 22:56, schrieb Ilia Mirkin:
> On Mon, Aug 11, 2014 at 4:34 PM, Roland Scheidegger
> wrote:
>> Am 11.08.2014 21:07, schrieb Ilia Mirkin:
>>> Signed-off-by: Ilia Mirkin
>>> ---
>>>
>>> Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of
>>> GL4.5?
>> Well thi
https://bugs.freedesktop.org/show_bug.cgi?id=82477
--- Comment #1 from Marek Olšák ---
The Mesa IR optimizer creates a lot of immediates when it evaluates constant
expressions, but doesn't eliminate them. You can easily get hundreds of unused
immediates, which is what is happening with fp-long-al
https://bugs.freedesktop.org/show_bug.cgi?id=82477
Priority: medium
Bug ID: 82477
Keywords: bisected, have-backtrace, regression
CC: e...@anholt.net, kenn...@whitecape.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpi
https://bugs.freedesktop.org/show_bug.cgi?id=68296
U. Artie Eoff changed:
What|Removed |Added
Attachment #104458|modified weston-simple-egl |modified weston-simple-egl
descri
https://bugs.freedesktop.org/show_bug.cgi?id=68296
U. Artie Eoff changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |wayland-bugs@lists.freedesk
On Mon, Aug 11, 2014 at 1:31 PM, Marek Olšák wrote:
> On Sat, Aug 9, 2014 at 5:24 AM, Connor Abbott wrote:
>> On Wed, Aug 6, 2014 at 6:29 PM, Marek Olšák wrote:
>>> What IR? A flatland GLSL IR? A replacement for Mesa IR? Something else?
>>
>> It's a flatland IR, similar to TGSI/Direct3D style wi
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #14 from U. Artie Eoff ---
Created attachment 104458
--> https://bugs.freedesktop.org/attachment.cgi?id=104458&action=edit
modified weston-simple-egl to trigger the issue too
--
You are receiving this mail because:
You are the ass
On Mon, Aug 11, 2014 at 4:34 PM, Roland Scheidegger wrote:
> Am 11.08.2014 21:07, schrieb Ilia Mirkin:
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of
>> GL4.5?
> Well this is mostly the same as ARB_robust_buffer_access_behav
From: Marek Olšák
Somebody forgot to do this. It was uncovered by recent st/mesa changes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82139
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/r600_shader.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium
From: Marek Olšák
This fixes piglit spec/ARB_texture_buffer_object/data-sync.
---
src/gallium/drivers/r600/evergreen_state.c| 9 +--
src/gallium/drivers/r600/r600_pipe.h | 1 +
src/gallium/drivers/r600/r600_state_common.c | 39 ---
src/gallium/drivers/
From: Marek Olšák
This maintains a list of all TBOs in a pipe_context.
---
src/gallium/drivers/radeonsi/si_descriptors.c | 13 -
src/gallium/drivers/radeonsi/si_pipe.h| 1 +
src/gallium/drivers/radeonsi/si_state.c | 10 --
3 files changed, 17 insertions(+), 7 d
From: Marek Olšák
---
src/gallium/drivers/r600/evergreen_state.c | 104 ++---
src/gallium/drivers/r600/evergreend.h | 1 +
src/gallium/drivers/r600/r600_state.c | 31 -
3 files changed, 49 insertions(+), 87 deletions(-)
diff --git a/src/gallium/drive
Am 11.08.2014 21:07, schrieb Ilia Mirkin:
> Signed-off-by: Ilia Mirkin
> ---
>
> Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of
> GL4.5?
Well this is mostly the same as ARB_robust_buffer_access_behavior which
is core in 4.3. Except ARB_robust_buffer_access_behavior i
From: Marek Olšák
---
src/gallium/drivers/r600/evergreen_state.c | 2 --
src/gallium/drivers/r600/r600_pipe.h | 2 +-
src/gallium/drivers/r600/r600_state_common.c | 21 +
src/gallium/drivers/r600/r600d.h | 11 +++
4 files changed, 33 insertions
From: Marek Olšák
These are recommended values. Some additional tweeks will be needed
for tessellation.
---
src/gallium/drivers/radeonsi/si_state.c | 6 -
src/gallium/drivers/radeonsi/si_state_draw.c | 33
2 files changed, 19 insertions(+), 20 deletions(-)
This extension is identical to NV_texture_barrier. Alias
glTextureBarrier to the existing glTextureBarrierNV and use the existing
NV_texture_barrier extension bit.
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- Add the actual extension string
- Remove separate (and missing dlist bits) TextureBarri
https://bugs.freedesktop.org/show_bug.cgi?id=82475
Priority: medium
Bug ID: 82475
Keywords: bisected, regression
CC: bri...@vmware.com, ja...@jlekstrand.net
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] [softpipe]
On Mon, Aug 11, 2014 at 3:07 PM, Ilia Mirkin wrote:
> The extension is identical to NV_texture_barrier except for the function
> name.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> I know these are normally split up a bit more, but here the implementation is
> *trivial*.
Err I realized that I for
https://bugs.freedesktop.org/show_bug.cgi?id=82472
Priority: medium
Bug ID: 82472
Keywords: bisected, regression
CC: cwo...@cworth.org, i...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit 16385-consecuti
On Wed, Aug 6, 2014 at 6:06 AM, Pohjolainen, Topi
wrote:
> On Thu, Jul 24, 2014 at 07:54:18PM -0700, Matt Turner wrote:
>> ---
>> src/mesa/drivers/dri/i965/brw_shader.cpp | 80
>>
>> src/mesa/drivers/dri/i965/brw_shader.h | 5 ++
>> 2 files changed, 85 inserti
The extension is identical to NV_texture_barrier except for the function
name.
Signed-off-by: Ilia Mirkin
---
I know these are normally split up a bit more, but here the implementation is
*trivial*.
src/mapi/glapi/gen/ARB_texture_barrier.xml | 13 +
src/mapi/glapi/gen/Makefile.am
Signed-off-by: Ilia Mirkin
---
Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of
GL4.5?
docs/GL3.txt | 16
1 file changed, 16 insertions(+)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 7f18cd7..f204652 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@
The sorting is different with LC_ALL=C. To avoid different people's
locale settings from fighting, force it to the one that was used to
generate the current file.
Signed-off-by: Ilia Mirkin
---
Not sure if there's a better way of doing it... perhaps forcing to C and just
regenerating with that m
This includes GL 4.5, which is necessary to support the new extensions.
Signed-off-by: Ilia Mirkin
---
include/GL/glext.h | 380 +++-
include/GL/glxext.h | 11 +-
include/GL/wglext.h | 11 +-
3 files changed, 396 insertions(+), 6 deletions(-)
d
Signed-off-by: Ilia Mirkin
---
include/GL/gl_mangle.h | 139 +
1 file changed, 139 insertions(+)
diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h
index b3a9c88..e04cf66 100644
--- a/include/GL/gl_mangle.h
+++ b/include/GL/gl_mangle.h
@@
https://bugs.freedesktop.org/show_bug.cgi?id=82471
Priority: medium
Bug ID: 82471
Keywords: bisected, regression
CC: e...@anholt.net, kenn...@whitecape.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] piglit fp-cond
On Thu, Aug 7, 2014 at 7:55 AM, Pohjolainen, Topi
wrote:
> On Thu, Jul 24, 2014 at 07:54:20PM -0700, Matt Turner wrote:
>> To avoid invalidating and recreating the control flow graph. Also stop
>> invalidating the CFG in places we didn't add or remove an instruction.
>>
>> cfg calculations: 20
https://bugs.freedesktop.org/show_bug.cgi?id=72572
Roland Scheidegger changed:
What|Removed |Added
Component|Other |Mesa core
--- Comment #1 from Rolan
On Tue, Aug 5, 2014 at 10:31 AM, Pohjolainen, Topi
wrote:
> On Thu, Jul 24, 2014 at 07:54:17PM -0700, Matt Turner wrote:
>> ---
>> src/mesa/drivers/dri/i965/brw_cfg.h | 1 +
>> src/mesa/drivers/dri/i965/brw_shader.cpp | 32
>>
>> src/mesa/drivers/dri/i965/b
On Mon, Aug 4, 2014 at 6:08 AM, Pohjolainen, Topi
wrote:
> Line overflowing here also.
Fixed all of these locally.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Neil,
Thanks for reviewing. Pushed.
--Jason
On Mon, Aug 11, 2014 at 10:59 AM, Neil Roberts wrote:
> Jason Ekstrand writes:
>
> > + /* If we are on the same miptree, same level, and same slice, then
> > +* intel_miptree_map won't let us map it twice. We have to do
> things a
> > +*
https://bugs.freedesktop.org/show_bug.cgi?id=79039
Bug 79039 depends on bug 65224, which changed state.
Bug 65224 Summary: piglit arb_uniform_buffer_object-maxuniformblocksize fs
regression
https://bugs.freedesktop.org/show_bug.cgi?id=65224
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=65224
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Comparing ~0u with a packed enum (i.e., 1 byte) always evaluates to
false. Shouldn't gcc warn about this?
Reported-by: Connor Abbott
---
src/mesa/drivers/dri/i965/brw_eu.c | 2 +-
src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_v
https://bugs.freedesktop.org/show_bug.cgi?id=58326
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=52209
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=77023
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=41162
--- Comment #2 from Roland Scheidegger ---
Is this still happening with recent mesa?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.
Jason Ekstrand writes:
> + /* If we are on the same miptree, same level, and same slice, then
> +* intel_miptree_map won't let us map it twice. We have to do things a
> +* big differently. In particular, we do a single map large
There's a small typo here.
Otherwise looks great to me
https://bugs.freedesktop.org/show_bug.cgi?id=53608
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Am 11.08.2014 00:51, schrieb Brian Paul:
> On 08/08/2014 07:43 PM, Roland Scheidegger wrote:
>> Am 08.08.2014 23:20, schrieb Brian Paul:
>>> Fixes failed assertion when _mesa_update_draw_buffers() was called
>>> with GL_DRAW_BUFFER == GL_FRONT_AND_BACK. The piglit gl30basic hit
>>> this.
>>>
>>> C
On Sat, Aug 9, 2014 at 5:24 AM, Connor Abbott wrote:
> On Wed, Aug 6, 2014 at 6:29 PM, Marek Olšák wrote:
>> What IR? A flatland GLSL IR? A replacement for Mesa IR? Something else?
>
> It's a flatland IR, similar to TGSI/Direct3D style with enough GLSL
> IR-like stuff to get existing things worki
1 - 100 of 126 matches
Mail list logo
