On 01/20/2013 02:59 PM, Eric Anholt wrote:
Before, we were keeping a CPU-only buffer to accumulate the batchbuffer in,
which was an improvement over mapping the batch through the GTT directly
(since any readback or other failure to stream through write combining
correctly would hurt). However, o
https://bugs.freedesktop.org/show_bug.cgi?id=59835
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=59835
Priority: medium
Bug ID: 59835
Keywords: regression
CC: chad.vers...@linux.intel.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: ir_constant_expression.cpp:156: undefined r
https://bugs.freedesktop.org/show_bug.cgi?id=59833
Priority: medium
Bug ID: 59833
Keywords: regression
CC: cwo...@cworth.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] piglit glx-swap-pixmap regression
S
On Sat, Dec 15, 2012 at 7:02 AM, Stéphane Marchesin
wrote:
> On Fri, Dec 14, 2012 at 12:52 PM, Frank Henigman
> wrote:
>> No piglet regressions and now passes glsl-uniform-out-of-bounds-2.
>>
>>
Should this have gone into the stable 9.0 branch?
Dave.
___
---
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index e3917fa..810495a 100755
--- a/src/mesa/drivers/dri/intel/intel_extensions.
---
.../dri/i965/brw_fs_channel_expressions.cpp|4
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |4
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |4
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_chann
---
src/mesa/drivers/dri/i965/brw_shader.cpp |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 1c02c87..da101a1 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mes
Lower them to arithmetic and bit manipulation expressions.
---
src/glsl/ir_optimization.h |6 +
src/glsl/lower_packing_builtins.cpp | 279 +++
2 files changed, 285 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_opt
That is, evaluate constant expressions for the following functions:
packSnorm4x8, unpackSnorm4x8
packUnorm4x8, unpackUnorm4x8
---
src/glsl/ir_constant_expression.cpp | 162 +++
1 files changed, 162 insertions(+), 0 deletions(-)
diff --git a/src/glsl/ir_constan
For each function {pack,unpack}{Snorm,Unorm}4x8, add a corresponding
opcode to enum ir_expression_operation. Validate the new opcodes in
ir_validate.cpp.
---
src/glsl/ir.cpp | 11 +++
src/glsl/ir.h |4
src/glsl/ir_validate.cpp| 12
---
src/glsl/builtins/ir/packSnorm4x8.ir |6 ++
src/glsl/builtins/ir/packUnorm4x8.ir |6 ++
src/glsl/builtins/ir/unpackSnorm4x8.ir |6 ++
src/glsl/builtins/ir/unpackUnorm4x8.ir |6 ++
.../profiles/ARB_shading_langu
---
src/glsl/builtins/tools/generate_builtins.py |1 +
src/glsl/glcpp/glcpp-parse.y |3 +++
src/glsl/glsl_parser_extras.cpp |1 +
src/glsl/glsl_parser_extras.h|2 ++
src/glsl/standalone_scaffolding.cpp |1 +
src/mesa/main/ex
Following this email are eight patches that add the 4x8 pack/unpack
operations that are the difference between what GLSL ES 3.0 and
ARB_shading_language_packing require.
They require Chad's gles3-glsl-packing series and are available at
http://cgit.freedesktop.org/~mattst88/mesa/log/?h=ARB_shading
While most of our development and testing is on x86-64, some of our
major consumers of the driver are on i386 still. This meant they aren't
taking advantage of SSE for floating point math or cmov instructions,
unless the user went out of their way to choose a -march flag
(unlikely). Given that th
https://bugs.freedesktop.org/show_bug.cgi?id=59831
Priority: medium
Bug ID: 59831
Assignee: mesa-dev@lists.freedesktop.org
Summary: undefined symbol _ZN4llvm19createGlobalDCEPassEv in
r600g
Severity: normal
Classification
Only drivers supporting DRI2 version >=4 support GLX_INTEL_swap_event.
So lets mark it as such otherwise applications which use this extension
(i.e. everything based on Clutter, e.g. gnome-shell) break horribly on
drivers supporting DRI2 versions only up to 3.
Note: This is a candidate for the 9.0
On 01/22/2013 12:52 AM, Ian Romanick wrote:
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/glsl/glsl_types.cpp | 12 +++-
src/glsl/glsl_types.h| 6 ++
src/glsl/link_uniforms.cpp | 14 --
src/glsl/lower_ubo_reference.cpp | 19
On 01/24/2013 04:54 PM, Paul Berry wrote:
When possible, glCopyTexSubImage calls are performed using the
hardware blitter. However, according to the Ivy Bridge PRM, Vol1
Part4, section 1.2.1.2 (Graphics Data Size Limitations):
The BLT engine is capable of transferring very large quantities
On 01/23/2013 02:01 PM, Paul Berry wrote:
> On 22 January 2013 00:51, Ian Romanick wrote:
>
>> From: Ian Romanick
>>
>> This will soon also be used for processing interface block fields.
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/glsl/ast_to_hir.cpp | 42 +-
When possible, glCopyTexSubImage calls are performed using the
hardware blitter. However, according to the Ivy Bridge PRM, Vol1
Part4, section 1.2.1.2 (Graphics Data Size Limitations):
The BLT engine is capable of transferring very large quantities of
graphics data. Any graphics data read
On 01/23/2013 01:54 PM, Paul Berry wrote:
> On 22 January 2013 00:51, Ian Romanick wrote:
>
>> From: Ian Romanick
>>
>> For now, just drop the value on the floor.
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/glsl/ast.h | 12 ++-
>> src/glsl/glsl_parser.yy | 55
>> ++
On 01/23/2013 01:43 PM, Paul Berry wrote:
> On 22 January 2013 00:51, Ian Romanick wrote:
>
>> From: Kenneth Graunke
>>
>> In GLSL ES 3.00 (and GLSL 1.50), uniform blocks can have an associated
>> "instance name", which essentially namespaces the variables inside.
>>
>> This patch adds basic par
Patches 1-4 are
Reviewed-by: Chad Versace
I'm still working through the others.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
According to KMail this went out as replay to all. Strange.
Am Donnerstag, 24. Januar 2013 schrieb Martin Steigerwald:
> Am Sonntag, 20. Januar 2013 schrieb Paul Berry:
> > > ---
> > >
> > > src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 106
> > >
> > > +++
> > >
> > >
Chad Versace writes:
> FIXME: This patch emits VS code that violates documented hardware restrictions
> and then relies on undocumented behavior that results from that violation.
> This patch passes all tests, but should be fixed ASAP to conform to the
> hardware documentation.
> + case ir_uno
Reviewed-by: Jordan Justen
On Mon, Jan 21, 2013 at 2:16 PM, Paul Berry wrote:
> This patch series adds support for varying structs, which are a
> required part of GLSL ES 3.00 and GLSL 1.50.
>
> I can see two principal ways to implement this feature: a "flattening"
> approach, and a "packing" ap
Note: This is a candidate for the 9.0 branch.
---
src/mesa/vbo/vbo_exec_api.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 985f220..353f8cf 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vb
Check the return value of calls to u_upload_alloc() and
u_upload_data() and return early if needed.
Since we don't have a way to propagate errors all the way up to
Mesa through pipe_context::draw_vbo(), call debug_warn_once() so
the user might have some clue about OOM errors.
---
src/gallium/auxi
Patches 1-9, 11-22, and 32 are:
Reviewed-by: Kenneth Graunke
I haven't read the others yet. No objections, just...haven't gotten to
them.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 01/23/2013 07:53 PM, Paul Berry wrote:
On 22 January 2013 00:52, Ian Romanick mailto:i...@freedesktop.org>> wrote:
From: Ian Romanick mailto:ian.d.roman...@intel.com>>
Signed-off-by: Ian Romanick mailto:ian.d.roman...@intel.com>>
---
src/glsl/ast_to_hir.cpp | 17 +++
Am Sonntag, 20. Januar 2013 schrieb Paul Berry:
> > ---
> >
> > src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 106
> >
> > +++
> >
> > src/mesa/drivers/dri/i965/brw_context.h | 8 ++
> > src/mesa/drivers/dri/intel/intel_tex_copy.c | 32 ++--
> > 3 files change
We weren't properly checking the return value of these calls (and
calls to u_upload_data()) to detect OOM errors.
---
src/mesa/state_tracker/st_cb_bitmap.c |5 ++---
src/mesa/state_tracker/st_cb_clear.c |5 ++---
src/mesa/state_tracker/st_cb_drawpixels.c |5 ++---
src/mesa/sta
Some callers of this function were checking the 'ptr' result to see if
the function failed. But the correct way is to check the regular
return value for PIPE_ERROR_x. Now we initialize all the returned
values at the top of the function in case we do hit an error (like OOM).
Callers are more like
v2: Remove lewd comment. [for idr]
v3: - Optimize away tmp register for packHalf2x16. [for anholt, paul]
- Improve comments. [for anholt, paul]
- Reduce near-duplicate code by removing vec4_visitor emit_pack/unpack
methods. [for chadv]
v4: Factor our UD/W register conversion into help
FIXME: This patch emits VS code that violates documented hardware restrictions
and then relies on undocumented behavior that results from that violation.
This patch passes all tests, but should be fixed ASAP to conform to the
hardware documentation.
v2: Explain undocumented hardware behavior. Impr
Paul Berry writes:
> Yeah, you're right. I was being lazy. How's this:
> * Furthermore, intelEmitCopyBlit (which is called by
> * intel_miptree_map_blit) uses a signed 16-bit integer to represent
> buffer
> * pitch, so it can only handle buffer pitches < 32k.
> *
> * As a r
On 01/23/2013 07:18 PM, Eric Anholt wrote:
> Chad Versace writes:
>> +void
>> +vec4_visitor::emit_unpack_half_2x16(dst_reg dst, src_reg src0)
>> +{
>> + if (intel->gen < 7)
>> + assert(!"ir_unop_unpack_half_2x16 should be lowered");
>> +
>> + assert(dst.type == BRW_REGISTER_TYPE_F);
>> +
On 01/24/2013 02:10 PM, Paul Berry wrote:
When possible, glReadPixels calls are performed using the hardware
blitter. However, according to the Ivy Bridge PRM, Vol1 Part4,
section 1.2.1.2 (Graphics Data Size Limitations):
The BLT engine is capable of transferring very large quantities of
On Thu, Jan 24, 2013 at 7:31 PM, Chad Versace
wrote:
> FYI,
>
> The enum is defined in mesa iteself at
> #MESA_SOURCE/include/GL/internal/dri_interface.h. Your
> problem was independent of dri2proto, kernel, drm, etc. I expect
> your build environment was accidentally #including the header located
https://bugs.freedesktop.org/show_bug.cgi?id=59187
pira...@gmail.com changed:
What|Removed |Added
CC||pira...@gmail.com
--
You are receivi
On 01/23/2013 12:16 PM, Brian Paul wrote:
Note, we could alternately implement this in terms of glsl_strtod()
with a (float) cast.
Series is
Reviewed-by: Ian Romanick
---
src/glsl/strtod.c | 22 ++
src/glsl/strtod.h |3 +++
2 files changed, 25 insertions(+), 0
Paul Berry writes:
> When possible, glReadPixels calls are performed using the hardware
> blitter. However, according to the Ivy Bridge PRM, Vol1 Part4,
> section 1.2.1.2 (Graphics Data Size Limitations):
>
> The BLT engine is capable of transferring very large quantities of
> graphics d
Yeah, you're right. I was being lazy. How's this:
/* According to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2 (Graphics
* Data Size Limitations):
*
*The BLT engine is capable of transferring very large quantities of
*graphics data. Any graphics data read from and w
On Thu, Jan 24, 2013 at 2:10 PM, Paul Berry wrote:
> When possible, glReadPixels calls are performed using the hardware
> blitter. However, according to the Ivy Bridge PRM, Vol1 Part4,
> section 1.2.1.2 (Graphics Data Size Limitations):
>
> The BLT engine is capable of transferring very large
When possible, glReadPixels calls are performed using the hardware
blitter. However, according to the Ivy Bridge PRM, Vol1 Part4,
section 1.2.1.2 (Graphics Data Size Limitations):
The BLT engine is capable of transferring very large quantities of
graphics data. Any graphics data read from
Kenneth Graunke writes:
> On 01/23/2013 10:28 PM, Ian Romanick wrote:
>> On 01/23/2013 06:27 PM, Kenneth Graunke wrote:
>>> Khronos has apparently decided that depth textures with sized formats
>>> (allowed with ARB_internalformat_query or ES 3.0) should be treated as
>>> GL_RED, while unsized fo
FYI,
The enum is defined in mesa iteself at
#MESA_SOURCE/include/GL/internal/dri_interface.h. Your
problem was independent of dri2proto, kernel, drm, etc. I expect
your build environment was accidentally #including the header located
in /usr/include/GL/internal rather than the one in the mesa sour
On Wed, Jan 23, 2013 at 8:36 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> I believe that the size used to vary, so the dynamic allocation is
> necessary.
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/dri/intel/intel_context.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 delet
https://bugs.freedesktop.org/show_bug.cgi?id=59238
Fabio Pedretti changed:
What|Removed |Added
Summary|many new symbols after |many new symbols in
|
https://bugs.freedesktop.org/show_bug.cgi?id=59304
Bug 59304 depends on bug 59334, which changed state.
Bug 59334 Summary: Automake Regression - Clover: Assertion failures when
loading pipe_r600.so driver
https://bugs.freedesktop.org/show_bug.cgi?id=59334
What|Removed
https://bugs.freedesktop.org/show_bug.cgi?id=59334
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=59304
Bug 59304 depends on bug 59534, which changed state.
Bug 59534 Summary: Automake Regression: Erroneous errors messages printed when
using clover
https://bugs.freedesktop.org/show_bug.cgi?id=59534
What|Removed
https://bugs.freedesktop.org/show_bug.cgi?id=59534
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Vincent,
For bug fixes, the Mesa convention is to use a normal commit message describing
what the change does and then put a link to the bug at the end of the
message. See for example:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=728bf86a23f6de137c0871ea87b09e75e55468a9
On Thu, Jan 24, 2
On Thu, Jan 24, 2013 at 01:16:35AM +0100, Vincent Lejeune wrote:
> ---
> lib/Target/R600/AMDGPUTargetMachine.cpp | 2 +-
> lib/Target/R600/R600LowerConstCopy.cpp | 167
> +---
> 2 files changed, 157 insertions(+), 12 deletions(-)
>
> diff --git a/lib/Target/R600/AM
---
src/gallium/drivers/r600/r600_llvm.c | 38 ++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 32b8e56..d28182b 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+
On Thu, Jan 24, 2013 at 01:15:19AM +0100, Vincent Lejeune wrote:
Reviewed-by: Tom Stellard
> ---
> lib/Target/R600/AMDILISelDAGToDAG.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/Target/R600/AMDILISelDAGToDAG.cpp
> b/lib/Target/R600/AMDILISelDAGToDAG.cpp
>
Hmm, switching to Ubuntu's distro-kernel, removing /opt/xorg and
building the XORG stuff from scratch...
1. libdrm-git
2. mesa-git
3. xf86-video-intel-git
...makes the errors go away.
OK, I had in my 3.8-rc4 kernel drm-intel-nightly integrated, but no
linux-headers package of this kernel install
Hi Ian,
due to the changes in...
e90c08e dri: Define enum __DRI_API_GLES3
...I get this breakage with mesa-gles3-git6f3caaf:
make[7]: Entering directory
`/home/wearefam/src/mesa/mesa-git/src/mesa/drivers/dri/common'
CC utils.lo
CC dri_util.lo
CC libdri_test_stubs_la-dri_test.l
From: Christian König
The loop handling in the CFG structurizer incorrectly assumed
that only BasicBlock nodes can have a back edge, but that is
also possible for the exit edges of subregions.
Fixing 4 more piglit tests on radeonsi.
Signed-off-by: Christian König
---
lib/Target/R600/AMDGPUStr
Hi Tom,
the following patches should fix the known issues with the structurizer and
also optimize it a bit more.
The first two are already tested by Michel. I tested the last one with radeonsi
and it doesn't seem to regress anything and actually fixes four more piglit
tests.
Please apply to y
v2: don't mess up other loops
Signed-off-by: Christian König
Tested-by: Michel Dänzer
---
lib/Target/R600/AMDGPUStructurizeCFG.cpp | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/Target/R600/AMDGPUStructurizeCFG.cpp
b/lib/Target/R600/AMDGPUStructurizeCFG.c
From: Christian König
Signed-off-by: Christian König
Tested-by: Michel Dänzer
---
lib/Target/R600/AMDGPUStructurizeCFG.cpp | 71 +++---
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/lib/Target/R600/AMDGPUStructurizeCFG.cpp
b/lib/Target/R600/AMDGPUSt
On 01/23/2013 11:17 AM, Eric Anholt wrote:
Dereffing all the values in the two callers was just pointless, and
the function isn't inlined so there was actual code impact.
It makes sense not to inline it, since it's pretty big and there are
already two callers (and my Gen8 branch adds two more)
On 01/23/2013 11:17 AM, Eric Anholt wrote:
The core Mesa code has just one more case than this (GL_BITMAP), so I
don't see any cause to special-case it.
It also doesn't have the packed format support, but I guess that isn't
relevant for index buffers (only vertex data). Might be worth a note,
On 01/10/2013 01:35 PM, Eric Anholt wrote:
This is the same logic from _mesa_map_function_array().
---
src/mesa/main/remap.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/remap.c b/src/mesa/main/remap.c
index c89fba4..a098705 100644
--- a/src/mesa/m
https://bugs.freedesktop.org/show_bug.cgi?id=31598
LoneVVolf changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On 01/23/2013 10:28 PM, Ian Romanick wrote:
On 01/23/2013 06:27 PM, Kenneth Graunke wrote:
Khronos has apparently decided that depth textures with sized formats
(allowed with ARB_internalformat_query or ES 3.0) should be treated as
GL_RED, while unsized formats (an existing feature) should be tr
69 matches
Mail list logo
