On Fri, May 17, 2013 at 07:11:36PM -0700, Jordan Justen wrote:
> Set the renderbuffer's Depth field to match the texture's
> Depth when rendering to a texture.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/intel/intel_fbo.c |9 ++---
> 1 file changed, 6 insertions(+), 3 d
Hi Jose,
Thanks for the review.
Jose Fonseca writes:
> - Original Message -
>> From: Richard Sandiford
>>
>> RGBA has R at byte 0 and A at byte 3, regardless of platform
>> endianness.
>
> Maybe I'm missing something, but this naming convention seems to me
> the exact opposite of w
On Tue, May 21, 2013 at 5:08 AM, Paul Berry wrote:
> On 17 May 2013 21:44, Chia-I Wu wrote:
>>
>> On Sat, May 18, 2013 at 10:11 AM, Jordan Justen
>> wrote:
>> > Rather than pointing the surface_state directly at a single
>> > sub-image of the texture for rendering, we now point the
>> > surface_
On 05/20/2013 04:19 PM, Brian Paul wrote:
On 05/13/2013 05:10 AM, Chris Forbes wrote:
Signed-off-by: Chris Forbes
---
src/mesa/main/get.c | 6 +-
src/mesa/main/get_hash_params.py | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/get.c b/src
Hi Brian,
Are you sure NVIDIA's behavior here is correct? The spec says ref is
clamped for queries:
>From the GL 4.3 spec, 17.3.5:
"Stencil comparison operations and queries of clamp its value
to the range [0, 2^s-1], where is the number of bits in the
stencil buffer attached to the
On 05/11/2013 02:38 PM, Stéphane Marchesin wrote:
The coordinates need to be inverted between glX and gallium.
---
src/gallium/state_trackers/glx/xlib/xm_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.c
b/src/gallium/state_
On 05/13/2013 05:10 AM, Chris Forbes wrote:
Signed-off-by: Chris Forbes
---
src/mesa/main/get.c | 6 +-
src/mesa/main/get_hash_params.py | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index f498118..593c75b 100
Anyone wants to look at those 2? I realize it's not a super common
combination (copysubbuffers + client-side glx) but still :)
Stéphane
On Sat, May 11, 2013 at 1:38 PM, Stéphane Marchesin
wrote:
> The coordinates need to be inverted between glX and gallium.
> ---
> src/gallium/state_trackers/g
https://bugs.freedesktop.org/show_bug.cgi?id=64649
romula...@gmail.com changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #13 from romula...@gmail.com ---
(In reply to comment #12)
> Same problem here, game crashes after intro, which I can watch.
> Dmesg output here is:
>
> traps: Renderer[1375] trap divide error ip:f4fedce4 sp:f09fee30 error:0 in
> r600
https://bugs.freedesktop.org/show_bug.cgi?id=64745
--- Comment #1 from Brian Paul ---
Looks like glxinfo failed to create a context and we're not checking for a null
pointer.
I'll post patches both for Mesa and glxinfo to be more resilient.
--
You are receiving this mail because:
You are the a
Most of the work in BeginTransformFeedback is only necessary on Gen6.
We may as well just skip it on Gen7+.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Paul Berry
---
src/mesa/drivers/dri/i965/brw_context.c| 8 +++---
src/mesa/drivers/dri/i965/brw_context.h| 3 +++
src/mesa/dr
Now that we have hardware contexts, we don't need to continually
reprogram the GS_SVBI_INDEX registers. They're automatically saved and
restored with the context, so they can just increment over time. We
only need to reset them when starting transform feedback.
There's also no reason to delay un
EXT_transform_feedback isn't yet supported on Gen4-5, so none of this
query code is actually used. This also means we can remove some of the
surrounding support code.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Paul Berry
---
src/mesa/drivers/dri/i965/brw_context.h | 4 --
s
This was only used for the the non-hardware context code.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Paul Berry
---
src/mesa/drivers/dri/i965/brw_context.h | 1 -
src/mesa/drivers/dri/i965/brw_vtbl.c| 6 --
src/mesa/drivers/dri/i965/gen6_sol.c| 1 -
3 files changed, 8 delet
We can just do it ourselves with MI_LOAD_REGISTER_IMM.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Paul Berry
---
src/mesa/drivers/dri/i965/gen6_sol.c | 13 -
src/mesa/drivers/dri/intel/intel_batchbuffer.c | 4
src/mesa/drivers/dri/intel/intel_context.h |
Failing to get a hardware context now means failing to load the driver,
so this code will never get hit.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Paul Berry
---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/src/mesa/dri
Using a function-like macro makes it easy to loop over all four streams.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Paul Berry
---
src/mesa/drivers/dri/intel/intel_reg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_reg.h
b/src/mesa/drivers/dri
This series deletes all the software primitive counting used to compute
transform feedback buffer offsets, and generally cleans up all of that
code. Now that we require hardware contexts on Gen6+, we can just
initialize the counters to 0 and let the hardware do the counting for us.
This means tha
On 05/17/2013 07:33 AM, jfons...@vmware.com wrote:
From: José Fonseca
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64745
Note: This is a candidate for the stable branches.
---
src/mesa/drivers/x11/fakeglx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/x11/fakeglx.c b/src/mesa/drivers/x11/fakeglx.c
index daed4f4
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64745
Note: This is a candidate for the stable branches.
---
src/gallium/state_trackers/glx/xlib/glx_api.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c
b/src/gallium
On 17 May 2013 21:44, Chia-I Wu wrote:
> On Sat, May 18, 2013 at 10:11 AM, Jordan Justen
> wrote:
> > Rather than pointing the surface_state directly at a single
> > sub-image of the texture for rendering, we now point the
> > surface_state at the top level of the texture, and configure
> > the
https://bugs.freedesktop.org/show_bug.cgi?id=64649
Mathias Anselmann changed:
What|Removed |Added
CC||mathias.anselm...@linux.com
--- Comm
On 05/20/2013 10:31 AM, Paul Berry wrote:
On 17 May 2013 10:17, Kenneth Graunke wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 2f5fedb..beade5c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/dri
On 17 May 2013 10:17, Kenneth Graunke wrote:
> Hello!
>
> This patch series bumps the kernel requirement to 3.6 for Gen6+,
> meaning that we actually get to rely on hardware context support.
> That's a little painful, but even Debian ships 3.8 now, and this
> isn't going to make it into an actual
On 17 May 2013 10:18, Kenneth Graunke wrote:
> Now that we have hardware contexts and can use MI_STORE_REGISTER_MEM,
> we can use the GPU's pipeline statistics counters rather than going out
> of our way to count primitives in software.
>
> Aside from being simpler, this also paves the way for Ge
On 17 May 2013 10:18, Kenneth Graunke wrote:
> This has more of a negative impact than the previous patch, as on Gen6
> passing primitives through to the clipper means we actually have to make
> the GS thread write them to the URB.
>
> I don't see another good solution though, and rasterizer disc
On 17 May 2013 10:17, Kenneth Graunke wrote:
> Hardware contexts greatly simplify the query object code. The pipeline
> statistics counters get saved and restored with the context, which means
> that we don't need to worry about other workloads polluting them.
>
> This means that we can simply w
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #11 from Jordan Justen ---
(In reply to comment #2)
> It then closes. It won't run without that extention, switched to GLX instead
> of a driver specific component.
The game runs for me with i965 on gen7.
--
You are receiving this
On 20 May 2013 09:47, Paul Berry wrote:
> On 17 May 2013 10:17, Kenneth Graunke wrote:
>
>> Kernel 3.3 introduced the SOL reset execbuf parameter, needed for GL 3.0
>> on Ivybridge. Bumping the requirement will give an obvious error
>> message rather than simply reporting GL 2.1.
>>
>> Signed-o
On 17 May 2013 10:17, Kenneth Graunke wrote:
> Hardware contexts are necessary to reasonably support OpenGL 3.2.
> In particular, we currently maintain software counters for transform
> feedback buffer offsets and counters, which relies on knowing the number
> of primitives generated. Geometry s
On 17 May 2013 10:17, Kenneth Graunke wrote:
> Kernel 3.3 introduced the SOL reset execbuf parameter, needed for GL 3.0
> on Ivybridge. Bumping the requirement will give an obvious error
> message rather than simply reporting GL 2.1.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/
On Mon, May 20, 2013 at 04:49:19PM +0200, Vincent Lejeune wrote:
> ---
For the series:
Reviewed-by: Tom Stellard
> src/gallium/drivers/r600/r600_llvm.c | 51
> +---
> 1 file changed, 24 insertions(+), 27 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #10 from Kai ---
Created attachment 79573
--> https://bugs.freedesktop.org/attachment.cgi?id=79573&action=edit
Full GDB backtrace for Anomaly 2
Yes, took two attempts, but attaching GDB while the intro is playing works
(GAME_DEBUGG
---
src/gallium/drivers/r600/r600_llvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 3d2c492..c1809b3 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -46
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 0629b89..3f7e79f 100644
--- a/src/gallium/drivers/radeon/radeon_setup_tgsi
---
src/gallium/drivers/r600/r600_llvm.c | 51 +---
1 file changed, 24 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index c6c9123..26d40a2 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
---
src/gallium/drivers/r600/r600_llvm.c | 15 +++
src/gallium/drivers/r600/r600_shader.c | 1 +
src/gallium/drivers/radeon/radeon_llvm.h | 1 +
3 files changed, 17 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index 26
---
src/gallium/drivers/r600/r600_llvm.c | 51 +---
1 file changed, 24 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index c6c9123..26d40a2 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
https://bugs.freedesktop.org/show_bug.cgi?id=64791
Priority: medium
Bug ID: 64791
Assignee: mesa-dev@lists.freedesktop.org
Summary: swrast crashes with compiz
Severity: normal
Classification: Unclassified
OS: All
Re
On Mon, May 20, 2013 at 5:13 AM, Vadim Girlin wrote:
> On 05/20/2013 11:27 AM, Dragomir Ivanov wrote:
>>
>> 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0,
>> surf=0x88d848,
>> level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0)
>>
>> It looks like division by 0. tile_sp
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #9 from Alex Deucher ---
(In reply to comment #8)
> Hm, doesn't really look graceful to me, I see:
> > traps: Renderer[14746] trap divide error ip:f5eea6aa sp:f03fedd0 error:0 in
> > r600_dri.so[f5b82000+585000]
> in dmesg output (no
https://bugs.freedesktop.org/show_bug.cgi?id=64649
--- Comment #8 from Kai ---
Hm, doesn't really look graceful to me, I see:
> traps: Renderer[14746] trap divide error ip:f5eea6aa sp:f03fedd0 error:0 in
> r600_dri.so[f5b82000+585000]
in dmesg output (nothing else) and "Floating point exception"
On 05/20/2013 11:27 AM, Dragomir Ivanov wrote:
0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, surf=0x88d848,
level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0)
It looks like division by 0. tile_split=0 from the call site.
Yes, I'm just not sure why tile_split is 0
0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, surf=0x88d848,
level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0)
It looks like division by 0. tile_split=0 from the call site.
On Mon, May 20, 2013 at 4:11 AM, Vadim Girlin wrote:
> Reduced test app attached and below
46 matches
Mail list logo