- Original Message -
> Fixes piglit texture-packed-formats regression. We need to implement
> more XBGR formats here eventually, but many are UINT/SINT formats
> which swrast doesn't handle yet anyway (integer textures).
>
> Bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=64935
>
My other sw info:
Running Ubuntu 13.04 64bit, with xorg edgers ppa, so my base
installation is mesa e54c924a0e9b9a504eae1eb68daaf51f21689629
currently and when I'm testing the new mesa I'm setting
LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH to my $HOME/src/mesa/lib (I do
this before I run glxgears for
On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Graunke wrote:
>
> Vedran,
>
> Can you try this patch and see if it solves your GPU hang issues? I still
> haven't been able to reproduce it, but I believe I may just be getting lucky.
>
Nope, with this one it's even worse.
Before after the initial hang
Am 11.06.2013 02:41, schrieb Marek Olšák:
> On Mon, Jun 10, 2013 at 3:25 PM, Grigori Goronzy wrote:
>> Allows MSAA colorbuffers, which have a CMASK automatically and don't
>> need any further special handling, to be fast cleared. Instead
>> of clearing the buffer, set the clear color and the CMASK
On Mon, Jun 10, 2013 at 3:25 PM, Grigori Goronzy wrote:
> Allows MSAA colorbuffers, which have a CMASK automatically and don't
> need any further special handling, to be fast cleared. Instead
> of clearing the buffer, set the clear color and the CMASK to the
> cleared state.
>
> Fast clear is used
Fabian Bieler writes:
> Hello!
>
> I'm obviously no expert for this code but as far as I understand it
> this was supposed to resize the zero length built-in arrays when they
> are not redeclared by the user (and only indexed with constant
> expressions).
>
> However, the later commit
> 6f53921 l
Hello!
I'm obviously no expert for this code but as far as I understand it this was
supposed to resize the zero length built-in arrays when they are not redeclared
by the user (and only indexed with constant expressions).
However, the later commit
6f53921 linker: Ensure that unsized arrays have
As of commit 6c966ccf07bcaf64fba1a9b699440c30dc96e732, we disable these
stages once on start up and never have to do it again.
Furthermore, redundant disabling is harmful: emitting multiple
3DSTATE_CONSTANT_* packets without an intervening 3DPRIMITIVE is
illegal. If the first operation that occur
On Monday 10 June 2013, Brian Paul wrote:
> On 06/10/2013 11:52 AM, Ian Romanick wrote:
> > From: Ian Romanick
> >
> > Previously we would generate uniform locations as (slot << 16) +
> > array_index. We do this two handle applications that assume the
to handle
> > location of a[2] will be +1 f
On Mon, Jun 10, 2013 at 11:55 PM, Alex Deucher wrote:
> On Mon, Jun 10, 2013 at 5:36 PM, Marek Olšák wrote:
>> Reviewed-by: Marek Olšák
>>
>> FYI, Cayman works for me as I said in
>> https://bugs.freedesktop.org/show_bug.cgi?id=62959 . I don't remember
>> if the issue has been fixed upstream.
>
The full commit message is this:
commit 586b4b500fed64fb724beb3753bc190cd1c676e0
Author: Eric Anholt
Date: Tue Sep 28 14:32:16 2010 -0700
glsl: Also update implicit sizes of varyings at link time.
Otherwise, we'll often end up with gl_TexCoord being 0 length, for
example. With ir
On Mon, Jun 10, 2013 at 5:36 PM, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> FYI, Cayman works for me as I said in
> https://bugs.freedesktop.org/show_bug.cgi?id=62959 . I don't remember
> if the issue has been fixed upstream.
Yes, the fixes should be upstream, however, Tom has had some st
Am 10.06.2013 22:34, schrieb Adam Jackson:
> Calling this two+ times per tile command is not especially fast. We
> already had a slot for this in the scene, but we were only filling it in
> for the z/s buffer. Fill it in consistently and use that instead of
> util_format_get_blocksize() when comp
Reviewed-by: Marek Olšák
FYI, Cayman works for me as I said in
https://bugs.freedesktop.org/show_bug.cgi?id=62959 . I don't remember
if the issue has been fixed upstream.
Marek
On Mon, Jun 10, 2013 at 10:34 PM, wrote:
> From: Alex Deucher
>
> Set env var RADEON_VA=0 to disable VM on Cayman/T
On Mon, Jun 10, 2013 at 04:34:09PM -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> Set env var RADEON_VA=0 to disable VM on Cayman/Trinity.
> Useful for debugging.
>
> Note: this is a candidate for the 9.1 branch.
>
> Signed-off-by: Alex Deucher
Thanks for doing this.
Reviewed-b
> And just any old GL application hangs it? Nothing specific?
>
Yes, i tried some glretraces, shader toy in chrome (webgl). Hangs on both.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 06/10/2013 01:46 PM, Vedran Rodic wrote:
This is my CPU:
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
stepping : 9
microcode : 0x12
Yikes. I definitely tested this on my HD 4000. What kernel are you using
(uname -a)?
Linux 3.9.
>> This is my CPU:
>> vendor_id : GenuineIntel
>> cpu family : 6
>> model : 58
>> model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
>> stepping : 9
>> microcode : 0x12
>
>
> Yikes. I definitely tested this on my HD 4000. What kernel are you using
> (uname -a)?
Linux 3.9.4
___
From: Alex Deucher
Set env var RADEON_VA=0 to disable VM on Cayman/Trinity.
Useful for debugging.
Note: this is a candidate for the 9.1 branch.
Signed-off-by: Alex Deucher
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff -
Calling this two+ times per tile command is not especially fast. We
already had a slot for this in the scene, but we were only filling it in
for the z/s buffer. Fill it in consistently and use that instead of
util_format_get_blocksize() when computing tile addresses.
Signed-off-by: Adam Jackson
On 06/10/2013 12:50 PM, Vedran Rodic wrote:
Hi,
This patch makes my Ivy Bridge hang when starting an OpenGL application:
[ 30.835248] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung
[ 30.835255] [drm] capturing error event; look for more information
in/sys/kernel...
T
On Fri, 2013-06-07 at 08:34 -0700, Jose Fonseca wrote:
> Looks good to me.
Pushed (along with some other fixes of Richard's that were still
pending), thanks.
- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/m
Previously, we would:
1. Emit the new indirect state.
2. Flag CACHE_NEW_BLEND_STATE.
3. Rely on later state atoms to notice CACHE_NEW_BLEND_STATE and emit a
pointer to the new indirect state.
This is rather cumbersome: it requires two state atoms instead of one,
and there's a strict ordering de
See two commits ago for the rationale. This allows us to delete the
whole gen7_cc_state.c file.
This does move these commands before the depth stall flushes from
brw_emit_depthbuffer, which may be a problem. The documentation for
3DSTATE_DEPTH_BUFFER mentions that depth stall flushes are require
See the previous commit for the rationale.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 2 --
src/mesa/drivers/dri/i965/brw_state.h| 1 -
src/mesa/drivers/dri/i965/brw_state_upload.c | 2 --
src/mesa/drivers/dri/i965/gen6_cc.c | 23 +++
Hi,
This patch makes my Ivy Bridge hang when starting an OpenGL application:
[ 30.835248] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung
[ 30.835255] [drm] capturing error event; look for more information
in/sys/kernel...
This is my CPU:
vendor_id : GenuineIntel
cpu fa
On 06/10/2013 11:21 AM, Brian Paul wrote:
On 06/10/2013 11:52 AM, Ian Romanick wrote:
From: Ian Romanick
Previously we would generate uniform locations as (slot << 16) +
array_index. We do this two handle applications that assume the
location of a[2] will be +1 from the location of a[1]. Thi
On 06/10/2013 11:52 AM, Ian Romanick wrote:
From: Ian Romanick
Previously we would generate uniform locations as (slot << 16) +
array_index. We do this two handle applications that assume the
location of a[2] will be +1 from the location of a[1]. This resulted in
every uniform location being
From: Ian Romanick
Previously we would generate uniform locations as (slot << 16) +
array_index. We do this two handle applications that assume the
location of a[2] will be +1 from the location of a[1]. This resulted in
every uniform location being at least 0x1. We've now encountered
two a
From: Ian Romanick
This will be used in the next commit.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Ian Romanick
---
src/mesa/main/uniform_query.cpp| 2 +-
src/mesa/main/uniforms.c | 2 +-
src/mesa/main/uniforms.h | 6
From: Ian Romanick
This is used by _mesa_uniform_merge_location_offset and
_mesa_uniform_split_location_offset to determine how the base and offset
are packed. Previously, this value was hard coded as (1U<<16) in those
functions via the shift and mask contained therein. The value is still
(1U<<
Kenneth Graunke writes:
> Signed-off-by: Kenneth Graunke
This series is:
Reviewed-by: Eric Anholt
pgpvYfmaTr2aA.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/m
Only just compile tested, as I don't have the "hardware" for it..
Signed-off-by: Rob Clark
---
configure.ac | 2 +-
vmwgfx/vmwgfx_dri2.c | 5 +++--
vmwgfx/vmwgfx_driver.c| 3 ++-
vmwgfx/vmwgfx_saa.c | 20 ++--
vmwgfx/vmwgfx_tex_video.c | 5 +++--
5
From: Rob Clark
Signed-off-by: Rob Clark
---
configure.ac | 4 +-
src/gallium/targets/Makefile.am | 3 ++
src/gallium/targets/xa-freedreno/Makefile.am | 65
src/gallium/targets/xa-freedreno/fd_target.c | 20 +
s
From: Jerome Glisse
This make ddx life easier.
Signed-off-by: Jerome Glisse
Signed-off-by: Rob Clark
---
src/gallium/state_trackers/xa/xa_priv.h| 1 +
src/gallium/state_trackers/xa/xa_tracker.c | 16 +++-
src/gallium/state_trackers/xa/xa_tracker.h | 3 ++-
3 files changed, 1
From: Rob Clark
Bump major version, as the change to require explicit
xa_context_flush(), the addition of the handle-type parameter to
xa_surface_handle(), and change of surface to ref/unref will require a
minor change in DDX.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
src/gallium/state_trackers/xa/xa_composite.c | 1 -
src/gallium/state_trackers/xa/xa_context.c | 10 ++
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_composite.c
b/src/gallium/stat
From: Jerome Glisse
pipe_transfer_map already offset the surface properly so using the offset
again with util_copy_rect might lead to read/write outside the surface.
Signed-off-by: Jerome Glisse
---
src/gallium/state_trackers/xa/xa_context.c | 5 ++---
1 file changed, 2 insertions(+), 3 deleti
From: Jerome Glisse
First step before moving flushing inside the ddx.
Signed-off-by: Jerome Glisse
---
src/gallium/state_trackers/xa/xa_composite.c | 2 +-
src/gallium/state_trackers/xa/xa_context.c | 17 +++--
src/gallium/state_trackers/xa/xa_context.h | 2 ++
src/gallium/st
From: Jerome Glisse
Allow to retrieve non shared handle.
Signed-off-by: Jerome Glisse
---
src/gallium/state_trackers/xa/xa_tracker.c | 11 ++-
src/gallium/state_trackers/xa/xa_tracker.h | 9 -
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_tr
From: Rob Clark
For freedreno DDX, we have to create the scanout GEM bo in a special way
(until we have our own KMS/DRM kernel driver.. and even then for
phones/tablets you probably need to use the android drivers if you don't
want to port the lcd panel driver support). The easiest way to handle
From: Rob Clark
The newer snapdragon devices (at least, the one I have in nexus4) no
longer has a dedicated 2D core. For these devices, DDX needs to use
the 3D core. I've implemented support to use XA in the DDX, but it
requires some changes which break the current API in XA.
In particular, mo
On Sam, 2013-06-08 at 20:08 -0400, Tom Stellard wrote:
> On Fri, Jun 07, 2013 at 05:48:05PM -0700, Tom Stellard wrote:
> > On Fri, Jun 07, 2013 at 05:24:42PM +0200, Michel Dänzer wrote:
> > >
> > > @@ -1544,6 +1562,26 @@ def : Pat <
> > > sub3)
> > > >;
> > >
> > > +class DD
Fixes piglit texture-packed-formats regression. We need to implement
more XBGR formats here eventually, but many are UINT/SINT formats
which swrast doesn't handle yet anyway (integer textures).
Bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=64935
---
src/mesa/swrast/s_texfetch.c | 1
Works similarly to clip distance. If the cull distance is negative
for all vertices against a specific plane then the primitive
is culled.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_context.c | 17
src/gallium/auxiliary/draw/draw_gs.c|6 ++
src/gal
Draw depended on clip_plane_enable being set in the rasterizer
to use clipdistance registers for clipping. That's really
unfriendly because it requires that rasterizer state to have
variants for every shader out there. Instead of depending on
the rasterizer lets extract the info from the available
cull distance is analogous to clip distance. If a register is
given this semantic, then the values in it are assumed to be a
float32 distance to a plane. Primitives will be completely
discarded if the plane distance for all of the vertices in
the primitive are < 0.
Signed-off-by: Zack Rusin
---
We need to figure out the number of invocations of the clipper
before the emit, because in the emit we are after clipping
where the number of primitives will be equal to number of clipper
invocations minus the clipped primitives. So our computations
were always off by the number of clipped primitiv
we were always fetching the info from the vertex shader, but if
geometry shader is present it should be used as the source of
that info.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_cliptest_tmp.h |3 ++-
src/gallium/auxiliary/draw/draw_context.c | 11 +++
src
Allows MSAA colorbuffers, which have a CMASK automatically and don't
need any further special handling, to be fast cleared. Instead
of clearing the buffer, set the clear color and the CMASK to the
cleared state.
Fast clear is used only when all bound colorbuffers fulfill certain
conditions: a CMAS
Am 10.06.2013 00:23, schrieb Dave Witbrodt:
> I updated Mesa last night from my previous version (from git master on
> May 31, commit 869c5d43) to the latest HEAD (commit 213c207b of Jun 8).
> The result was a huge boost to the performance of my system, based on a
> Radeon HD 5750.
>
> After peru
https://bugs.freedesktop.org/show_bug.cgi?id=65514
Rob Clark changed:
What|Removed |Added
CC||robcl...@freedesktop.org
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=65514
--- Comment #4 from Grigori Goronzy ---
To be more accurate, Google Maps attaches a depth and stencil buffer with 4
samples and a colorbuffer with 0 (1) samples. That's clearly not supposed to
work. I do not believe this is a bug in Mesa.
--
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=65514
--- Comment #3 from Nicholas Miell ---
(In reply to comment #2)
> does it work with R600_LLVM=0 ?
No.
Quoting the Mozilla bug:
"A GL_INVALID_FRAMEBUFFER_OPERATION error is generated in
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT|GL_STENCIL_
https://bugs.freedesktop.org/show_bug.cgi?id=65514
--- Comment #2 from Marc Dietrich ---
does it work with R600_LLVM=0 ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
55 matches
Mail list logo
