https://bugs.freedesktop.org/show_bug.cgi?id=59187
Fabian Henze flyse...@gmx.de changed:
What|Removed |Added
CC||flyse...@gmx.de
--
You
Sounds good to me. It matches the SM3 semantics
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172934(v=vs.85).aspx
It may expose driver bugs on handling saturate, but such bugs should be fixed
regardless.
Jose
- Original Message -
v2: change the requirement from GLSL
On 04.02.2013 08:27, Michel Dänzer wrote:
On Fre, 2013-02-01 at 22:50 +0100, Christoph Bumiller wrote:
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index d0f0070..7ae9dd6 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60212
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
On Mon, Feb 4, 2013 at 4:30 AM, Abdiel Janulgue
abdiel.janul...@linux.intel.com wrote:
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60212
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_screen.c |1 +
1 file changed, 1
From: Christian König christian.koe...@amd.com
Intersecting loop handling was wrong.
Signed-off-by: Christian König christian.koe...@amd.com
Tested-by: Michel Dänzer michel.daen...@amd.com
---
lib/Target/R600/AMDGPUStructurizeCFG.cpp | 296 ++
1 file changed, 183
From: Christian König christian.koe...@amd.com
Otherwise we sometimes produce invalid code.
Signed-off-by: Christian König christian.koe...@amd.com
Tested-by: Michel Dänzer michel.daen...@amd.com
---
lib/Target/R600/AMDGPUStructurizeCFG.cpp | 146 +-
1 file changed,
From: Christian König christian.koe...@amd.com
This fixes a couple of bugs and incorrect assumptions,
in total four more piglit tests now pass.
v2: fix small bug in the dominator updating
Signed-off-by: Christian König christian.koe...@amd.com
---
lib/Target/R600/AMDGPUStructurizeCFG.cpp |
From: Michel Dänzer michel.daen...@amd.com
22 more little piglits with radeonsi.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
lib/Target/R600/SIInstructions.td |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/Target/R600/SIInstructions.td
On 02/02/2013 12:41 AM, Vinson Lee wrote:
Fixes uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Leev...@freedesktop.org
---
src/glsl/ast.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index
On Fri, Feb 01, 2013 at 04:39:42PM +0100, Michel Dänzer wrote:
This series and the corresponding radeonsi series get shadow samplers and
texture arrays mostly working and fix a bunch of other piglit failures,
gaining just shy of 100 piglits.
[PATCH 1/4] R600: Consolidate sub register
- Original Message -
On 02/01/2013 12:39 PM, srol...@vmware.com wrote:
From: Roland Scheideggersrol...@vmware.com
They are similar to old-style tex opcodes but with separate sampler
and
texture units (and other arguments in different places).
Also adjust the debug tgsi dump
From: Christian König christian.koe...@amd.com
The _SGPR variants where wrong.
Signed-off-by: Christian König christian.koe...@amd.com
---
lib/Target/R600/AMDGPUCodeEmitter.h|4 -
lib/Target/R600/AMDILISelDAGToDAG.cpp | 53
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
lib/Target/R600/SIInstrInfo.td | 10 ++
lib/Target/R600/SIInstructions.td | 19 ---
lib/Target/R600/SILowerLiteralConstants.cpp |1 -
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c |9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
From: Christian König christian.koe...@amd.com
Seems to work fine now.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c |6 --
1 file changed, 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
On Mon, 2013-02-04 at 17:54 +0100, Christian König wrote:
+// i64 immediates aren't supported in hardware, split it into two 32bit
values
+def : Pat
+ (i64 imm:$imm),
+ (INSERT_SUBREG (INSERT_SUBREG (i64 (IMPLICIT_DEF)),
+(S_MOV_IMM_I32 (LO32 imm:$imm)), low),
+(S_MOV_IMM_I32
On Sun, Feb 03, 2013 at 06:22:42PM +0100, Marek Olšák wrote:
---
Hi Marek,
If you are interested in expanding the propagation of _SAT to instructions
besides MOV, you can look at peephole_mul_omod() as an example of how to
do this.
Anyway, these patches look good.
For the series:
Reviewed-by:
https://bugs.freedesktop.org/show_bug.cgi?id=59737
Matt Turner matts...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Thu, Jan 31, 2013 at 4:34 PM, Paul Berry stereotype...@gmail.com wrote:
Since transform feedback needs to be able to access individual fields
of varying structs, we can no longer match up the arguments to
glTransformFeedbackVaryings() with variables in the vertex shader.
Instead, we build
If you look up a level that isn't in the miptree, you crash.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 ++-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git
On 02/04/2013 09:42 AM, Eric Anholt wrote:
If you look up a level that isn't in the miptree, you crash.
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
From: Michel Dänzer michel.daen...@amd.com
20 more little piglits with radeonsi.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
lib/Target/R600/SIInstructions.td |4
1 file changed, 4 insertions(+)
diff --git a/lib/Target/R600/SIInstructions.td
Abdiel,
This patch has my r-b. I'll add the Tested-by's given in the bug report
and commit.
On 02/04/2013 03:30 AM, Abdiel Janulgue wrote:
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60212
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=60216
--- Comment #1 from Matt Turner matts...@gmail.com ---
Where is HAVE_WINSYS_XLIB defined? I don't think it ever is, which makes the
existing check to use it wrong.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=60197
--- Comment #3 from Matt Turner matts...@gmail.com ---
The wayland patch is totally believable. I can reproduce that and I'll commit
it.
What flags do you have to build with to reproduce the problem the first problem
fixes?
--
You are
On Don, 2013-01-31 at 07:18 -0800, Jose Fonseca wrote:
- Original Message -
On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote:
- Original Message -
On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
- Original Message -
Is this feasible, or
On 02/01/2013 04:39 AM, Andreas Boll wrote:
Building OpenGL ES1 and/or ES2 without OpenGL is not supported on mesa
9.0.x
Mesa shouldn't allow users to shoot themselves in the foot so easily.
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
___
https://bugs.freedesktop.org/show_bug.cgi?id=59967
--- Comment #12 from Fabio Pedretti fabio@libero.it ---
I suggest to remove this configure check since it prevents building on an
otherwise working setup. Better risking of failing during make rather than
during configure if the make would
On 29 January 2013 00:36, Kenneth Graunke kenn...@whitecape.org wrote:
The BLT engine has many limitations. Currently, it can only blit
X-tiled buffers (since we don't have a kernel API to whack the BLT
tiling mode register), which means all depth/stencil operations get
punted to meta code,
On 01/28/2013 09:00 PM, Eric Anholt wrote:
Part of my motivation here was the number of cache misses we have in the first
reference of a region after referencing the miptree wrapping it, for things
that should all live in the first cacheline of one struct.
I think I've made it as far into
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/2013 09:00 PM, Eric Anholt wrote:
It's now always called from the same file. ---
src/mesa/drivers/dri/i915/i830_vtbl.c | 17 +++--
src/mesa/drivers/dri/i915/i915_vtbl.c | 17 +++--
On 01/28/2013 09:00 PM, Eric Anholt wrote:
This is similar code to intel_miptree_copy_slice, but the knobs
are all set differently.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c | 18 ++---
src/mesa/drivers/dri/intel/intel_regions.c| 34
-
https://bugs.freedesktop.org/show_bug.cgi?id=59876
--- Comment #1 from Stefan Brüns stefan.bru...@rwth-aachen.de ---
Created attachment 74192
-- https://bugs.freedesktop.org/attachment.cgi?id=74192action=edit
proposed patch
The libxcb XXX_data_length(reply) function does *not* return the
https://bugs.freedesktop.org/show_bug.cgi?id=44743
--- Comment #8 from Vasily Khoruzhick anars...@gmail.com ---
Still happens with llvmpipe, but system has changed,
now it's Core i5-3320M and 64-bit OS (still Archlinux), earlier it was
Core 2 Duo T5500 with 32-bit OS
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=44743
--- Comment #9 from Vasily Khoruzhick anars...@gmail.com ---
Created attachment 74194
-- https://bugs.freedesktop.org/attachment.cgi?id=74194action=edit
cpuinfo
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=59876
Matt Turner matts...@gmail.com changed:
What|Removed |Added
CC||i...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=60294
Priority: medium
Bug ID: 60294
Assignee: mesa-dev@lists.freedesktop.org
Summary: Flashplayer cracshing
Severity: normal
Classification: Unclassified
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=60294
René Blokland pe1...@gmail.com changed:
What|Removed |Added
Version|unspecified |git
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=60294
René Blokland pe1...@gmail.com changed:
What|Removed |Added
Summary|Flashplayer cracshing |Flashplayer crashing
--
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #2 from Alex Deucher ag...@yahoo.com ---
Please attach your xorg log and dmesg output. Is this a self built mesa? A
disto package?
--
You are receiving this mail because:
You are the assignee for the bug.
Chad Versace chad.vers...@linux.intel.com writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/2013 09:00 PM, Eric Anholt wrote:
It's now always called from the same file. ---
src/mesa/drivers/dri/i915/i830_vtbl.c | 17 +++--
On 02/04/2013 02:11 PM, Eric Anholt wrote:
Chad Versace chad.vers...@linux.intel.com writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/2013 09:00 PM, Eric Anholt wrote:
It's now always called from the same file. ---
src/mesa/drivers/dri/i915/i830_vtbl.c | 17
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #3 from René Blokland pe1...@gmail.com ---
It is self built
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #4 from René Blokland pe1...@gmail.com ---
Created attachment 74198
-- https://bugs.freedesktop.org/attachment.cgi?id=74198action=edit
Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #5 from René Blokland pe1...@gmail.com ---
bugzilla donẗ let me add dmesg (submit does nothing)
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #6 from René Blokland pe1...@gmail.com ---
Created attachment 74206
-- https://bugs.freedesktop.org/attachment.cgi?id=74206action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #7 from René Blokland pe1...@gmail.com ---
(In reply to comment #5)
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=60298
Priority: medium
Bug ID: 60298
Keywords: regression
CC: i...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit arb_uniform_buffer_object-row-major
The current gen_matypes logic assumes that the host compiler will produce
information that is useful for the target compiler. Unfortunately, this
is not the case whenever cross-compiling.
When we detect that we're cross-compiling and using GCC, use the target
compiler to produce assembly from
Jordan Justen jljus...@gmail.com writes:
On Fri, Feb 1, 2013 at 1:34 PM, Eric Anholt e...@anholt.net wrote:
Otherwise, the stderr and stdout debug end up interleaved wrong
when I pipe them to a file.
Shouldn't we convert dlist.c to _mesa_debug instead? It doesn't seem
right for mesa to use
These have been wrong since f428255bde93a452a7cdd48fba21839c99beb6cb
back in 2009!
---
src/mesa/drivers/dri/i965/brw_curbe.c|6 --
src/mesa/drivers/dri/i965/brw_state_upload.c |6 --
2 files changed, 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
There's some weird text I'd never noticed in the VBO spec suggesting
that we don't need to deal with misaligned data within buffers at all,
but I imagine apps all over the place would fail if we started relying
on that text. Just warn the developer when they stumble over this.
---
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index ed3b378..e7f45ad 100644
---
We used to have clip planes optionally included in the push constants,
resulting in a variable amount of data uploaded, but no more. This also
means less wasted space in the batch for our push constants.
---
src/mesa/drivers/dri/i965/gen6_vs_state.c |8 +++-
1 file changed, 3
It doesn't matter with our current implementation of MapBufferRange,
but it was wrong -- the result pointer is read by intel_upload_data().
---
src/mesa/drivers/dri/i965/brw_draw_upload.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=60294
--- Comment #8 from Armin K kre...@email.com ---
It's not that I am a dev or something, but you should first consider upgrading
the kernel. Releases from 3.8-rc2 to 3.8-rc6 include lot of fixes and maybe it
could solve your problems.
--
You are
V2: - Remove spurious duplicate prototypes in teximage.h
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/multisample.c | 15 +++
src/mesa/main/multisample.h | 5 +
src/mesa/main/teximage.c| 20
src/mesa/main/teximage.h| 10 ++
This series adds the core mesa bits and i965 driver support for
ARB_texture_multisample.
Big changes from V1:
- Generally cleaner
- GLSL texelFetch() with a multisample sampler is converted to
a new ir_txf_ms opcode in the GLSL IR, which makes the driver side
a lot tidier.
-
V2: - Drop placeholder
- Align enum values
- Remove explicit exec=mesa; it *is* the dispatch flavor we want,
but it's also the default. I misunderstood how this worked before;
after actually reading the generator it makes good sense.
Signed-off-by: Chris Forbes
V2: - reorder after introducing stubs
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/tests/dispatch_sanity.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index
Adds the new texture targets, and per-image state for GL_TEXTURE_SAMPLES
and GL_TEXTURE_FIXED_SAMPLE_LOCATIONS.
V2: - Allow multisample texture targets in glInvalidateTexSubImage too.
This was already partly there, but I missed it the first time around
since the interaction is defined
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/tests/enum_strings.cpp | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/mesa/main/tests/enum_strings.cpp
b/src/mesa/main/tests/enum_strings.cpp
index 5d70007..1dae60f 100644
---
V2: - emit `sample` parameter properly for multisample texelFetch()
V3: - fix spurious whitespace change
- introduce a new opcode ir_txf_ms rather than overloading the
existing ir_txf further. This makes doing the right thing in
the driver somewhat simpler.
Signed-off-by: Chris
Actual sample locations deferred to a driverfunc since only the driver
really knows where they will be.
V2: - pass the draw buffer to the driverfunc; don't fallback to pixel
center if driverfunc is missing.
- rename GetSampleLocation to GetSamplePosition
- invert y sample position
V2: For now, only expose a depth sample count of 1, since there are
unresolved interactions with W-tiling for stencil textures and possibly
also HiZ for depth textures.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_context.c | 12 ++--
1 file changed, 10
V2: - fix multiline comment style
- stop using ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH since that
doesn't exist anymore.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/enable.c | 15 +++
src/mesa/main/get.c | 9 +
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_context.h| 2 +-
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/gen6_multisample_state.c | 19 +--
src/mesa/drivers/dri/i965/gen7_blorp.cpp
Moves the definition of the sample positions out of
gen6_emit_3dstate_multisample, and unpacks them in
gen6_get_sample_position.
V2: Be consistent about `sample position` rather than `location`.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_context.c
- sample count must be the same on all attachments
- fixedsamplepositions must be the same on all attachments
(renderbuffers have fixedsamplepositions=true implicitly; only
multisample textures can choose to have it false)
- stencil-only formats become legal.
V2: - fix wrapping to 80 columns,
GL_TEXTURE_2D_MULTISAMPLE and GL_TEXTURE_2D_MULTISAMPLE_ARRAY targets
don't allow filtering state to be set, but the default state fails the
completeness check for integer formats.
We still care about other reasons the texture might be considered
incomplete though, so can't skip this entirely
V2: - fix formatting issues
- generate GL_OUT_OF_MEMORY if teximage cannot be allocated
- fix for state moving from texobj to image
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/main/teximage.c | 153 +--
1 file changed, 149
V2: - Fix for state moving from texobj to image
- Rebased onto Paul's logical/physical cleanup
- Fixed missing quantization of sample count
- Fold in IMS renderbuffer wrapper fixes from later in the series
- Use correct physical slice offset for UMS/CMS surfaces on Gen7
The surface_state setup for renderbuffers already worked; only the
texturing side needed work. BLORP does something similar, but does its
own surface_state setup.
On Gen6, we just need to set the correct sample count.
On Gen7: - set the correct sample count
- set the correct layout mode
Gen7 has an erratum affecting the ld_mcs message, making it unsafe to
use when the surface doesn't have an associated MCS.
To allow the shader to treat all surfaces uniformly, force UMS if the
surface is to be used as a multisample texture, even if CMS would have
been possible.
Signed-off-by:
This is very similar to the TXF opcode, but lowers to `ld2dms` rather
than `ld` on Gen7.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/brw_fs.cpp| 1 +
src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 7 +++
On Gen6, lower this to `ld` with lod=0 and an extra sample_index
parameter.
On Gen7, use `ld2dms`. This takes an additional MCS parameter to support
compressed multisample surfaces, but we're not enabling them for
multisample textures for now, so it's always zero and can be safely
omitted.
V2:
On Gen6, lower this to `ld` with lod=0 and an extra sample_index
parameter.
On Gen7, use `ld2dms`. We don't support CMS yet for multisample
textures, so we use MCS=0, which does the right thing for both IMS and
UMS surfaces.
Note: If we do end up emitting specialized shaders based on the MSAA
78 matches
Mail list logo
