Re: [Mesa-dev] [PATCH 2/5] intel_fbo: set gl_renderbuffer Depth field
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 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
> b/src/mesa/drivers/dri/intel/intel_fbo.c
> index a8a7ab3..243c00a 100644
> --- a/src/mesa/drivers/dri/intel/intel_fbo.c
> +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
> @@ -482,14 +482,17 @@ intel_framebuffer_renderbuffer(struct gl_context * ctx,
> static bool
> intel_renderbuffer_update_wrapper(struct intel_context *intel,
>struct intel_renderbuffer *irb,
> - struct gl_texture_image *image,
> - uint32_t layer)
> + struct gl_texture_image *image,
> + uint32_t layer,
> + bool layered)
This belongs to the next patch in the series, right?
> {
> struct gl_renderbuffer *rb = &irb->Base.Base;
> struct intel_texture_image *intel_image = intel_texture_image(image);
> struct intel_mipmap_tree *mt = intel_image->mt;
> int level = image->Level;
>
> + rb->Depth = image->Depth;
> +
> rb->AllocStorage = intel_nop_alloc_storage;
>
> intel_miptree_check_level_layer(mt, level, layer);
> @@ -598,7 +601,7 @@ intel_render_texture(struct gl_context * ctx,
>
> intel_miptree_check_level_layer(mt, att->TextureLevel, layer);
>
> - if (!intel_renderbuffer_update_wrapper(intel, irb, image, layer)) {
> + if (!intel_renderbuffer_update_wrapper(intel, irb, image, layer,
> att->Layered)) {
> _swrast_render_texture(ctx, fb, att);
> return;
> }
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/13] gallium: Introduce 32-bit bytewise format names
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 what was decided [1], which is:
>
> - R at byte 0, ..., and A at byte 3, regardless of platform endianness would
> be called "R8G8B8A8"
>
> - R at bit 0, ..., A at bit 24, encoded as integers that match the platform
> endianness would be called "RGBA"
>
> which would be consistent with (as in a superset of) D3D10 format
> naming.
Yeah, it's supposed to be that way round in the patches. RGBA is a
32-bit int with R in the high 8 bits and A in the low 8 bits. R8G8B8A8 is
an array of 4 bytes in the order { R, G, B, A }. I think it was just
the comment in the covering note that had it the wrong way around --
sorry about that.
Thanks,
Richard
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] i965 gen7: add support for layered color renderbuffers
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_state at the top level of the texture, and configure
>> > the surface_state as needed based on this.
>> >
>> > We now also need to stop setting the FORCE_ZERO_RTAINDEX bit
>> > in the clip date so render target array values other than zero
>> > will be used.
>> >
>> > Signed-off-by: Jordan Justen
>> > ---
>> > src/mesa/drivers/dri/i965/brw_defines.h |2 +
>> > src/mesa/drivers/dri/i965/gen7_clip_state.c |3 +-
>> > src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 63
>> > +++--
>> > 3 files changed, 48 insertions(+), 20 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
>> > b/src/mesa/drivers/dri/i965/brw_defines.h
>> > index fedd78c..d61151f 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_defines.h
>> > +++ b/src/mesa/drivers/dri/i965/brw_defines.h
>> > @@ -539,6 +539,8 @@
>> > #define GEN7_SURFACE_MULTISAMPLECOUNT_8 (3 << 3)
>> > #define GEN7_SURFACE_MSFMT_MSS (0 << 6)
>> > #define GEN7_SURFACE_MSFMT_DEPTH_STENCIL(1 << 6)
>> > +#define GEN7_SURFACE_MIN_ARRAY_ELEMENT_SHIFT 18
>> > +#define GEN7_SURFACE_RENDER_TARGET_VIEW_EXTENT_SHIFT 7
>> >
>> > /* Surface state DW5 */
>> > #define BRW_SURFACE_X_OFFSET_SHIFT 25
>> > diff --git a/src/mesa/drivers/dri/i965/gen7_clip_state.c
>> > b/src/mesa/drivers/dri/i965/gen7_clip_state.c
>> > index 29a5ed5..1256f32 100644
>> > --- a/src/mesa/drivers/dri/i965/gen7_clip_state.c
>> > +++ b/src/mesa/drivers/dri/i965/gen7_clip_state.c
>> > @@ -107,8 +107,7 @@ upload_clip_state(struct brw_context *brw)
>> > GEN6_CLIP_XY_TEST |
>> > dw2);
>> > OUT_BATCH(U_FIXED(0.125, 3) << GEN6_CLIP_MIN_POINT_WIDTH_SHIFT |
>> > - U_FIXED(255.875, 3) << GEN6_CLIP_MAX_POINT_WIDTH_SHIFT |
>> > - GEN6_CLIP_FORCE_ZERO_RTAINDEX);
>> > + U_FIXED(255.875, 3) << GEN6_CLIP_MAX_POINT_WIDTH_SHIFT);
>> > ADVANCE_BATCH();
>> > }
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> > b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> > index 6c01545..5f15eff 100644
>> > --- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> > +++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> > @@ -23,6 +23,7 @@
>> > #include "main/mtypes.h"
>> > #include "main/blend.h"
>> > #include "main/samplerobj.h"
>> > +#include "main/texformat.h"
>> > #include "program/prog_parameter.h"
>> >
>> > #include "intel_mipmap_tree.h"
>> > @@ -529,12 +530,13 @@ gen7_update_renderbuffer_surface(struct
>> > brw_context *brw,
>> > struct gl_context *ctx = &intel->ctx;
>> > struct intel_renderbuffer *irb = intel_renderbuffer(rb);
>> > struct intel_region *region = irb->mt->region;
>> > - uint32_t tile_x, tile_y;
>> > uint32_t format;
>> > /* _NEW_BUFFERS */
>> > gl_format rb_format = _mesa_get_render_format(ctx,
>> > intel_rb_format(irb));
>> > -
>> > - assert(!layered);
>> > + uint32_t surftype;
>> > + bool is_array = false;
>> > + int depth = rb->Depth > 0 ? rb->Depth - 1 : 0;
>> > + int min_array_element = 0;
>> >
>> > uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
>> > 8 * 4, 32,
>> > &brw->wm.surf_offset[unit]);
>> > @@ -550,7 +552,23 @@ gen7_update_renderbuffer_surface(struct brw_context
>> > *brw,
>> > __FUNCTION__, _mesa_get_format_name(rb_format));
>> > }
>> >
>> > - surf[0] = BRW_SURFACE_2D << BRW_SURFACE_TYPE_SHIFT |
>> > + if (rb->TexImage) {
>> > + surftype = translate_tex_target(rb->TexImage->TexObject->Target);
>> > + is_array =
>> > _mesa_tex_target_is_array(rb->TexImage->TexObject->Target);
>> > + if (rb->TexImage->TexObject->Target == GL_TEXTURE_CUBE_MAP_ARRAY)
>> > {
>> > + assert(rb->Depth > 0);
>> > + surftype = BRW_SURFACE_2D;
>> > + depth = (6 * (depth + 1)) - 1;
>> > + } else if (rb->TexImage->TexObject->Target ==
>> > GL_TEXTURE_CUBE_MAP) {
>> > + surftype = BRW_SURFACE_2D;
>> > + depth = 5;
>> > + is_array = true;
>> > + }
>> > + } else {
>> > + surftype = BRW_SURFACE_2D;
>> > + }
>> > +
>> > + surf[0] = surftype << BRW_SURFACE_TYPE_SHIFT |
>> > format << BRW_SURFACE_FORMAT_SHIFT |
>> > (irb->mt->array_spacing_lod0 ? GEN7_SURFACE_ARYSPC_LOD0
>> >: GEN7_SURFACE_ARYSPC_FULL) |
>> > @@ -561,24 +579,33 @@ gen7_update_renderbuffer_surface(struct
>> > brw_context *brw,
>> > if (irb->mt->align_w == 8)
>> >surf[0] |= GEN7_SURFACE_HALIGN_8;
>> >
>> > - /* reloc */
>> > - surf[1] = intel_renderbuffer_tile_offse
Re: [Mesa-dev] [PATCH 2/8] mesa: Use accessor for stencil reference values in glGet
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/mesa/main/get.c index f498118..593c75b 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -36,6 +36,7 @@ #include "texcompress.h" #include "framebuffer.h" #include "samplerobj.h" +#include "stencil.h" /* This is a table driven implemetation of the glGet*v() functions. * The basic idea is that most getters just look up an int somewhere @@ -675,7 +676,10 @@ find_custom_value(struct gl_context *ctx, const struct value_desc *d, union valu v->value_enum = ctx->Stencil.ZPassFunc[ctx->Stencil.ActiveFace]; break; case GL_STENCIL_REF: - v->value_int = ctx->Stencil.Ref[ctx->Stencil.ActiveFace]; + v->value_int = _mesa_get_stencil_ref(ctx, ctx->Stencil.ActiveFace); I think this is incorrect. I tested with NVIDIA's driver and it returns the user's originally-specified value without any sort of masking. Can you revert this chunk? Sorry I missed this earlier, I was on vacation. -Brian Chris did notice that, but I think nVidia's implementation is incorrect. The specification is pretty clear that it should be clamped. It might be worth trying AMD. If both return the unclamped value, we might want to file a spec bug. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/8] mesa: Use accessor for stencil reference values in glGet
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 draw framebuffer." -- Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/xlib: Fix upside down coordinates for CopySubBuffer
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_trackers/glx/xlib/xm_api.c
index e426192..4f10b84 100644
--- a/src/gallium/state_trackers/glx/xlib/xm_api.c
+++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
@@ -1256,7 +1256,7 @@ void XMesaCopySubBuffer( XMesaBuffer b, int x, int y, int
width, int height )
{
xmesa_copy_st_framebuffer(b->stfb,
ST_ATTACHMENT_BACK_LEFT, ST_ATTACHMENT_FRONT_LEFT,
- x, y, width, height);
+ x, b->height - y - height, width, height);
}
For both, Reviewed-by: Brian Paul
Mark as candidates for the stable branches?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/8] mesa: Use accessor for stencil reference values in glGet
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 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -36,6 +36,7 @@ #include "texcompress.h" #include "framebuffer.h" #include "samplerobj.h" +#include "stencil.h" /* This is a table driven implemetation of the glGet*v() functions. * The basic idea is that most getters just look up an int somewhere @@ -675,7 +676,10 @@ find_custom_value(struct gl_context *ctx, const struct value_desc *d, union valu v->value_enum = ctx->Stencil.ZPassFunc[ctx->Stencil.ActiveFace]; break; case GL_STENCIL_REF: - v->value_int = ctx->Stencil.Ref[ctx->Stencil.ActiveFace]; + v->value_int = _mesa_get_stencil_ref(ctx, ctx->Stencil.ActiveFace); I think this is incorrect. I tested with NVIDIA's driver and it returns the user's originally-specified value without any sort of masking. Can you revert this chunk? Sorry I missed this earlier, I was on vacation. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/xlib: Fix upside down coordinates for CopySubBuffer
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/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_trackers/glx/xlib/xm_api.c
> index e426192..4f10b84 100644
> --- a/src/gallium/state_trackers/glx/xlib/xm_api.c
> +++ b/src/gallium/state_trackers/glx/xlib/xm_api.c
> @@ -1256,7 +1256,7 @@ void XMesaCopySubBuffer( XMesaBuffer b, int x, int y,
> int width, int height )
> {
> xmesa_copy_st_framebuffer(b->stfb,
> ST_ATTACHMENT_BACK_LEFT, ST_ATTACHMENT_FRONT_LEFT,
> - x, y, width, height);
> + x, b->height - y - height, width, height);
> }
>
>
> --
> 1.8.2.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync
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 |org |.org Component|GLX |Drivers/Gallium/r600 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync
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_dri.so[f4b61000+1512000] > > I'm using mesa 9.1.2 and kernel 3.9.3 (up to date arch system). Same issue in git: traps: Renderer[7610] trap divide error ip:f5eb56ba sp:f07fedd0 error:0 in r600_dri.so[f5b3e000+5f5000 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 64745] [llvmpipe] SIGSEGV src/gallium/state_trackers/glx/xlib/glx_api.c:1374
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 assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] i965: Split BeginTransformFeedback hook into Gen6 and Gen7+ variants.
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/drivers/dri/i965/gen6_sol.c | 41 +++---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 17 +
4 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 405580f..56c42ba 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -94,12 +94,14 @@ static void brwInitDriverFunctions(struct intel_screen
*screen,
gen4_init_queryobj_functions(functions);
functions->QuerySamplesForFormat = brw_query_samples_for_format;
- functions->BeginTransformFeedback = brw_begin_transform_feedback;
- if (screen->gen >= 7)
+ if (screen->gen >= 7) {
+ functions->BeginTransformFeedback = gen7_begin_transform_feedback;
functions->EndTransformFeedback = gen7_end_transform_feedback;
- else
+ } else {
+ functions->BeginTransformFeedback = brw_begin_transform_feedback;
functions->EndTransformFeedback = brw_end_transform_feedback;
+ }
if (screen->gen >= 6)
functions->GetSamplePosition = gen6_get_sample_position;
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index be49078..60b713d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1228,6 +1228,9 @@ brw_end_transform_feedback(struct gl_context *ctx,
/* gen7_sol_state.c */
void
+gen7_begin_transform_feedback(struct gl_context *ctx, GLenum mode,
+ struct gl_transform_feedback_object *obj);
+void
gen7_end_transform_feedback(struct gl_context *ctx,
struct gl_transform_feedback_object *obj);
diff --git a/src/mesa/drivers/dri/i965/gen6_sol.c
b/src/mesa/drivers/dri/i965/gen6_sol.c
index cdd6e74..8e197a1 100644
--- a/src/mesa/drivers/dri/i965/gen6_sol.c
+++ b/src/mesa/drivers/dri/i965/gen6_sol.c
@@ -152,36 +152,25 @@ brw_begin_transform_feedback(struct gl_context *ctx,
GLenum mode,
= _mesa_compute_max_transform_feedback_vertices(xfb_obj,
linked_xfb_info);
- if (intel->gen == 6) {
- /* Initialize the SVBI 0 register to zero and set the maximum index. */
+ /* Initialize the SVBI 0 register to zero and set the maximum index. */
+ BEGIN_BATCH(4);
+ OUT_BATCH(_3DSTATE_GS_SVB_INDEX << 16 | (4 - 2));
+ OUT_BATCH(0); /* SVBI 0 */
+ OUT_BATCH(0); /* starting index */
+ OUT_BATCH(max_index);
+ ADVANCE_BATCH();
+
+ /* Initialize the rest of the unused streams to sane values. Otherwise,
+* they may indicate that there is no room to write data and prevent
+* anything from happening at all.
+*/
+ for (int i = 1; i < 4; i++) {
BEGIN_BATCH(4);
OUT_BATCH(_3DSTATE_GS_SVB_INDEX << 16 | (4 - 2));
- OUT_BATCH(0); /* SVBI 0 */
+ OUT_BATCH(i << SVB_INDEX_SHIFT);
OUT_BATCH(0); /* starting index */
- OUT_BATCH(max_index);
+ OUT_BATCH(0x);
ADVANCE_BATCH();
-
- /* Initialize the rest of the unused streams to sane values. Otherwise,
- * they may indicate that there is no room to write data and prevent
- * anything from happening at all.
- */
- for (int i = 1; i < 4; i++) {
- BEGIN_BATCH(4);
- OUT_BATCH(_3DSTATE_GS_SVB_INDEX << 16 | (4 - 2));
- OUT_BATCH(i << SVB_INDEX_SHIFT);
- OUT_BATCH(0); /* starting index */
- OUT_BATCH(0x);
- ADVANCE_BATCH();
- }
- } else if (intel->gen >= 7) {
- /* Reset the SOL buffer offset register. */
- for (int i = 0; i < 4; i++) {
- BEGIN_BATCH(3);
- OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
- OUT_BATCH(GEN7_SO_WRITE_OFFSET(i));
- OUT_BATCH(0);
- ADVANCE_BATCH();
- }
}
}
diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
b/src/mesa/drivers/dri/i965/gen7_sol_state.c
index 2c4b7f9..8dfac01 100644
--- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
@@ -254,6 +254,23 @@ const struct brw_tracked_state gen7_sol_state = {
};
void
+gen7_begin_transform_feedback(struct gl_context *ctx, GLenum mode,
+ struct gl_transform_feedback_object *obj)
+{
+ struct brw_context *brw = brw_context(ctx);
+ struct intel_context *intel = &brw->intel;
+
+ /* Reset the SOL buffer offset register. */
+ for (int i = 0; i < 4; i++) {
+ BEGIN_BATCH(3);
+ OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
+ OUT_BATCH(GEN7_SO_WRITE_OFFSET(i));
+ OUT_BATCH(0);
+ ADVANCE_BATCH();
+ }
+}
+
+void
gen7_end_transform_fee
[Mesa-dev] [PATCH 6/7] i965: Kill software primitive counting entirely.
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 until the next drawing operation; we can
just emit the packet immediately. However, this means we must drop the
initialization in brw_invariant_state, as BeginTransformFeedback may
occur before the first drawing in a context.
Signed-off-by: Kenneth Graunke
Cc: Eric Anholt
Cc: Paul Berry
---
src/mesa/drivers/dri/i965/brw_context.h | 7
src/mesa/drivers/dri/i965/brw_draw.c | 54
src/mesa/drivers/dri/i965/brw_misc_state.c | 13 ---
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_sol.c | 53 ---
6 files changed, 22 insertions(+), 108 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 97caccd..be49078 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -148,7 +148,6 @@ enum brw_state_id {
BRW_STATE_VS_CONSTBUF,
BRW_STATE_PROGRAM_CACHE,
BRW_STATE_STATE_BASE_ADDRESS,
- BRW_STATE_SOL_INDICES,
BRW_STATE_VUE_MAP_GEOM_OUT,
BRW_STATE_TRANSFORM_FEEDBACK,
BRW_STATE_RASTERIZER_DISCARD,
@@ -181,7 +180,6 @@ enum brw_state_id {
#define BRW_NEW_VS_CONSTBUF(1 << BRW_STATE_VS_CONSTBUF)
#define BRW_NEW_PROGRAM_CACHE (1 << BRW_STATE_PROGRAM_CACHE)
#define BRW_NEW_STATE_BASE_ADDRESS (1 << BRW_STATE_STATE_BASE_ADDRESS)
-#define BRW_NEW_SOL_INDICES(1 << BRW_STATE_SOL_INDICES)
#define BRW_NEW_VUE_MAP_GEOM_OUT (1 << BRW_STATE_VUE_MAP_GEOM_OUT)
#define BRW_NEW_TRANSFORM_FEEDBACK (1 << BRW_STATE_TRANSFORM_FEEDBACK)
#define BRW_NEW_RASTERIZER_DISCARD (1 << BRW_STATE_RASTERIZER_DISCARD)
@@ -1085,11 +1083,6 @@ struct brw_context
} *state_batch_list;
int state_batch_count;
- struct brw_sol_state {
- uint32_t svbi_0_starting_index;
- uint32_t svbi_0_max_index;
- } sol;
-
uint32_t render_target_format[MESA_FORMAT_COUNT];
bool format_supported_as_render_target[MESA_FORMAT_COUNT];
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 4dd185e..657d6ee 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -351,57 +351,6 @@ static void brw_postdraw_set_buffers_need_resolve(struct
brw_context *brw)
intel_renderbuffer_set_needs_depth_resolve(depth_irb);
}
-static int
-verts_per_prim(GLenum mode)
-{
- switch (mode) {
- case GL_POINTS:
- return 1;
- case GL_LINE_STRIP:
- case GL_LINE_LOOP:
- case GL_LINES:
- return 2;
- case GL_TRIANGLE_STRIP:
- case GL_TRIANGLE_FAN:
- case GL_POLYGON:
- case GL_TRIANGLES:
- case GL_QUADS:
- case GL_QUAD_STRIP:
- return 3;
- default:
- _mesa_problem(NULL,
- "unknown prim type in transform feedback primitive count");
- return 0;
- }
-}
-
-/**
- * Update internal counters based on the the drawing operation described in
- * prim.
- */
-static void
-brw_update_primitive_count(struct brw_context *brw,
- const struct _mesa_prim *prim)
-{
- uint32_t count
- = vbo_count_tessellated_primitives(prim->mode, prim->count,
- prim->num_instances);
- if (_mesa_is_xfb_active_and_unpaused(&brw->intel.ctx)) {
- /* Update brw->sol.svbi_0_max_index to reflect the amount by which the
- * hardware is going to increment SVBI 0 when this drawing operation
- * occurs. This is necessary because the kernel does not (yet) save and
- * restore GPU registers when context switching, so we'll need to be
- * able to reload SVBI 0 with the correct value in case we have to start
- * a new batch buffer.
- */
- unsigned verts = verts_per_prim(prim->mode);
- uint32_t space_avail =
- (brw->sol.svbi_0_max_index - brw->sol.svbi_0_starting_index) / verts;
- uint32_t primitives_written = MIN2 (space_avail, count);
- brw->sol.svbi_0_starting_index += verts * primitives_written;
- }
-}
-
/* May fail if out of video memory for texture or vbo upload, or on
* fallback conditions.
*/
@@ -524,9 +473,6 @@ retry:
}
}
}
-
- if (!_mesa_meta_in_progress(ctx))
- brw_update_primitive_count(brw, &prim[i]);
}
if (intel->always_flush_batch)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 6b61929..8162eeb 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -999,19 +999,6 @@ static void upload_invariant_stat
[Mesa-dev] [PATCH 5/7] i965: Remove software geometry query code.
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 --
src/mesa/drivers/dri/i965/brw_draw.c | 4 --
src/mesa/drivers/dri/i965/brw_primitive_restart.c | 11 -
src/mesa/drivers/dri/i965/brw_queryobj.c | 52 ---
4 files changed, 71 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 8587dd0..97caccd 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1088,10 +1088,6 @@ struct brw_context
struct brw_sol_state {
uint32_t svbi_0_starting_index;
uint32_t svbi_0_max_index;
- uint32_t primitives_generated;
- uint32_t primitives_written;
- bool counting_primitives_generated;
- bool counting_primitives_written;
} sol;
uint32_t render_target_format[MESA_FORMAT_COUNT];
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 8c37e0b..4dd185e 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -386,7 +386,6 @@ brw_update_primitive_count(struct brw_context *brw,
uint32_t count
= vbo_count_tessellated_primitives(prim->mode, prim->count,
prim->num_instances);
- brw->sol.primitives_generated += count;
if (_mesa_is_xfb_active_and_unpaused(&brw->intel.ctx)) {
/* Update brw->sol.svbi_0_max_index to reflect the amount by which the
* hardware is going to increment SVBI 0 when this drawing operation
@@ -400,9 +399,6 @@ brw_update_primitive_count(struct brw_context *brw,
(brw->sol.svbi_0_max_index - brw->sol.svbi_0_starting_index) / verts;
uint32_t primitives_written = MIN2 (space_avail, count);
brw->sol.svbi_0_starting_index += verts * primitives_written;
-
- /* And update the TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN query. */
- brw->sol.primitives_written += primitives_written;
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
index 10581b3..f824915 100644
--- a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
+++ b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
@@ -73,17 +73,6 @@ can_cut_index_handle_prims(struct gl_context *ctx,
const struct _mesa_index_buffer *ib)
{
struct intel_context *intel = intel_context(ctx);
- struct brw_context *brw = brw_context(ctx);
-
- if (brw->sol.counting_primitives_generated ||
- brw->sol.counting_primitives_written) {
- /* Counting primitives generated in hardware is not currently
- * supported, so take the software path. We need to investigate
- * the *_PRIMITIVES_COUNT registers to allow this to be handled
- * entirely in hardware.
- */
- return false;
- }
/* Otherwise Haswell can do it all. */
if (intel->is_haswell)
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index 8579993..985dbed 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -187,14 +187,6 @@ brw_queryobj_get_results(struct gl_context *ctx,
}
break;
- case GL_PRIMITIVES_GENERATED:
- case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
- /* We don't actually query the hardware for this value, so query->bo
- * should always be NULL and execution should never reach here.
- */
- assert(!"Unreachable");
- break;
-
default:
assert(!"Unrecognized query target in brw_queryobj_get_results()");
break;
@@ -305,22 +297,6 @@ brw_begin_query(struct gl_context *ctx, struct
gl_query_object *q)
brw->state.dirty.brw |= BRW_NEW_STATS_WM;
break;
- case GL_PRIMITIVES_GENERATED:
- /* We don't actually query the hardware for this value; we keep track of
- * it a software counter. So just reset the counter.
- */
- brw->sol.primitives_generated = 0;
- brw->sol.counting_primitives_generated = true;
- break;
-
- case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
- /* We don't actually query the hardware for this value; we keep track of
- * it a software counter. So just reset the counter.
- */
- brw->sol.primitives_written = 0;
- brw->sol.counting_primitives_written = true;
- break;
-
default:
assert(!"Unrecognized query target in brw_begin_query()");
break;
@@ -380,34 +356,6 @@ brw_end_query(struct gl_context *ctx, struct
gl_query_object *q)
brw->state.dirty.brw |= BRW_NEW_STATS_WM;
break;
- case GL_PRIMITIVES_GENERATED:
- /* We don't actually query the hardware for this value;
[Mesa-dev] [PATCH 4/7] i965: Delete unused brw->sol.offset_0_batch_start field.
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 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index fbff10b..8587dd0 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1088,7 +1088,6 @@ struct brw_context
struct brw_sol_state {
uint32_t svbi_0_starting_index;
uint32_t svbi_0_max_index;
- uint32_t offset_0_batch_start;
uint32_t primitives_generated;
uint32_t primitives_written;
bool counting_primitives_generated;
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
b/src/mesa/drivers/dri/i965/brw_vtbl.c
index 4ca83e4..96a6cd5 100644
--- a/src/mesa/drivers/dri/i965/brw_vtbl.c
+++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
@@ -197,12 +197,6 @@ static void brw_new_batch( struct intel_context *intel )
brw->state_batch_count = 0;
- /* Gen7 needs to track what the real transform feedback vertex count was at
-* the start of the batch, since the kernel will be resetting the offset to
-* 0.
-*/
- brw->sol.offset_0_batch_start = brw->sol.svbi_0_starting_index;
-
brw->ib.type = -1;
/* Mark that the current program cache BO has been used by the GPU.
diff --git a/src/mesa/drivers/dri/i965/gen6_sol.c
b/src/mesa/drivers/dri/i965/gen6_sol.c
index bb2dd12..668a99e 100644
--- a/src/mesa/drivers/dri/i965/gen6_sol.c
+++ b/src/mesa/drivers/dri/i965/gen6_sol.c
@@ -181,7 +181,6 @@ brw_begin_transform_feedback(struct gl_context *ctx, GLenum
mode,
brw->state.dirty.brw |= BRW_NEW_SOL_INDICES;
brw->sol.svbi_0_starting_index = 0;
brw->sol.svbi_0_max_index = max_index;
- brw->sol.offset_0_batch_start = 0;
if (intel->gen >= 7) {
/* Reset the SOL buffer offset register. */
--
1.8.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] i965: Stop using the kernel SOL reset feature.
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 | 1 -
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_sol.c
b/src/mesa/drivers/dri/i965/gen6_sol.c
index 3cbf28e..bb2dd12 100644
--- a/src/mesa/drivers/dri/i965/gen6_sol.c
+++ b/src/mesa/drivers/dri/i965/gen6_sol.c
@@ -184,11 +184,14 @@ brw_begin_transform_feedback(struct gl_context *ctx,
GLenum mode,
brw->sol.offset_0_batch_start = 0;
if (intel->gen >= 7) {
- /* Ask the kernel to reset the SO offsets for any previous transform
- * feedback, so we start at the start of the user's buffer. (note: these
- * are not the query counters)
- */
- intel->batch.needs_sol_reset = true;
+ /* Reset the SOL buffer offset register. */
+ for (int i = 0; i < 4; i++) {
+ BEGIN_BATCH(3);
+ OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
+ OUT_BATCH(GEN7_SO_WRITE_OFFSET(i));
+ OUT_BATCH(0);
+ ADVANCE_BATCH();
+ }
}
}
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index 8c6524e..c7f6d56 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -96,7 +96,6 @@ intel_batchbuffer_reset(struct intel_context *intel)
intel->batch.reserved_space = BATCH_RESERVED;
intel->batch.state_batch_offset = intel->batch.bo->size;
intel->batch.used = 0;
- intel->batch.needs_sol_reset = false;
}
void
@@ -199,9 +198,6 @@ do_flush_locked(struct intel_context *intel)
flags = I915_EXEC_BLT;
}
- if (batch->needs_sol_reset)
-flags |= I915_EXEC_GEN7_SOL_RESET;
-
if (ret == 0) {
if (unlikely(INTEL_DEBUG & DEBUG_AUB) && intel->vtbl.annotate_aub)
intel->vtbl.annotate_aub(intel);
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index c0f07ff..8c50e6e 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -135,7 +135,6 @@ struct intel_batchbuffer {
uint32_t state_batch_offset;
bool is_blit;
- bool needs_sol_reset;
struct {
uint16_t used;
--
1.8.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] i965: Remove dead code for Gen7 SOL without hardware contexts.
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/drivers/dri/i965/gen7_sol_state.c
b/src/mesa/drivers/dri/i965/gen7_sol_state.c
index 1e484dc..2c4b7f9 100644
--- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
@@ -82,15 +82,6 @@ upload_3dstate_so_buffers(struct brw_context *brw)
end = ALIGN(start + xfb_obj->Size[i], 4);
assert(end <= bo->size);
- /* If we don't have hardware contexts, then we reset our offsets at the
- * start of every batch, so we track the number of vertices written in
- * software and increment our pointers by that many.
- */
- if (!intel->hw_ctx) {
- start += brw->sol.offset_0_batch_start * stride;
- assert(start <= end);
- }
-
BEGIN_BATCH(4);
OUT_BATCH(_3DSTATE_SO_BUFFER << 16 | (4 - 2));
OUT_BATCH((i << SO_BUFFER_INDEX_SHIFT) | stride);
@@ -241,12 +232,6 @@ upload_sol_state(struct brw_context *brw)
upload_3dstate_so_buffers(brw);
/* BRW_NEW_VUE_MAP_GEOM_OUT */
upload_3dstate_so_decl_list(brw, &brw->vue_map_geom_out);
-
- /* If we don't have hardware contexts, then some other client may have
- * changed the SO write offsets, and we need to rewrite them.
- */
- if (!intel->hw_ctx)
- intel->batch.needs_sol_reset = true;
}
/* Finally, set up the SOL stage. This command must always follow updates
to
--
1.8.2.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] i965: Add a macro for accessing the SO_WRITE_OFFSET[0-3] registers.
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/intel/intel_reg.h index 1cfb464..dd91a15 100644 --- a/src/mesa/drivers/dri/intel/intel_reg.h +++ b/src/mesa/drivers/dri/intel/intel_reg.h @@ -291,6 +291,8 @@ #define SO_NUM_PRIMS_WRITTEN2_IVB 0x5210 #define SO_NUM_PRIMS_WRITTEN3_IVB 0x5218 +#define GEN7_SO_WRITE_OFFSET(n) (0x5280 + (n) * 4) + #define TIMESTAMP 0x2358 #define BCS_SWCTRL 0x22200 -- 1.8.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Gen6+ transform feedback fully in hardware
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 that we get hardware primitive restart in the majority of cases, which should be a lot more efficient. It also means we're prepared for geometry shaders. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Don't force stabs debug format for Mingw.
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
[Mesa-dev] [PATCH 2/2] xlib: check for null ctx pointer in glXIsDirect()
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..c7fb327 100644
--- a/src/mesa/drivers/x11/fakeglx.c
+++ b/src/mesa/drivers/x11/fakeglx.c
@@ -1551,7 +1551,7 @@ Fake_glXIsDirect( Display *dpy, GLXContext ctx )
{
struct fake_glx_context *glxCtx = (struct fake_glx_context *) ctx;
(void) dpy;
- return glxCtx->xmesaContext->direct;
+ return glxCtx ? glxCtx->xmesaContext->direct : False;
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/glx/xlib: check for null ctx pointer in glXIsDirect()
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/state_trackers/glx/xlib/glx_api.c
index 88f5886..a66ebc8 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -1369,9 +1369,7 @@ glXDestroyContext( Display *dpy, GLXContext ctx )
PUBLIC Bool
glXIsDirect( Display *dpy, GLXContext ctx )
{
- GLXContext glxCtx = ctx;
- (void) ctx;
- return glxCtx->isDirect;
+ return ctx ? ctx->isDirect : False;
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] i965 gen7: add support for layered color renderbuffers
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 surface_state as needed based on this.
> >
> > We now also need to stop setting the FORCE_ZERO_RTAINDEX bit
> > in the clip date so render target array values other than zero
> > will be used.
> >
> > Signed-off-by: Jordan Justen
> > ---
> > src/mesa/drivers/dri/i965/brw_defines.h |2 +
> > src/mesa/drivers/dri/i965/gen7_clip_state.c |3 +-
> > src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 63
> +++--
> > 3 files changed, 48 insertions(+), 20 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> b/src/mesa/drivers/dri/i965/brw_defines.h
> > index fedd78c..d61151f 100644
> > --- a/src/mesa/drivers/dri/i965/brw_defines.h
> > +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> > @@ -539,6 +539,8 @@
> > #define GEN7_SURFACE_MULTISAMPLECOUNT_8 (3 << 3)
> > #define GEN7_SURFACE_MSFMT_MSS (0 << 6)
> > #define GEN7_SURFACE_MSFMT_DEPTH_STENCIL(1 << 6)
> > +#define GEN7_SURFACE_MIN_ARRAY_ELEMENT_SHIFT 18
> > +#define GEN7_SURFACE_RENDER_TARGET_VIEW_EXTENT_SHIFT 7
> >
> > /* Surface state DW5 */
> > #define BRW_SURFACE_X_OFFSET_SHIFT 25
> > diff --git a/src/mesa/drivers/dri/i965/gen7_clip_state.c
> b/src/mesa/drivers/dri/i965/gen7_clip_state.c
> > index 29a5ed5..1256f32 100644
> > --- a/src/mesa/drivers/dri/i965/gen7_clip_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen7_clip_state.c
> > @@ -107,8 +107,7 @@ upload_clip_state(struct brw_context *brw)
> > GEN6_CLIP_XY_TEST |
> > dw2);
> > OUT_BATCH(U_FIXED(0.125, 3) << GEN6_CLIP_MIN_POINT_WIDTH_SHIFT |
> > - U_FIXED(255.875, 3) << GEN6_CLIP_MAX_POINT_WIDTH_SHIFT |
> > - GEN6_CLIP_FORCE_ZERO_RTAINDEX);
> > + U_FIXED(255.875, 3) << GEN6_CLIP_MAX_POINT_WIDTH_SHIFT);
> > ADVANCE_BATCH();
> > }
> >
> > diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> > index 6c01545..5f15eff 100644
> > --- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> > @@ -23,6 +23,7 @@
> > #include "main/mtypes.h"
> > #include "main/blend.h"
> > #include "main/samplerobj.h"
> > +#include "main/texformat.h"
> > #include "program/prog_parameter.h"
> >
> > #include "intel_mipmap_tree.h"
> > @@ -529,12 +530,13 @@ gen7_update_renderbuffer_surface(struct
> brw_context *brw,
> > struct gl_context *ctx = &intel->ctx;
> > struct intel_renderbuffer *irb = intel_renderbuffer(rb);
> > struct intel_region *region = irb->mt->region;
> > - uint32_t tile_x, tile_y;
> > uint32_t format;
> > /* _NEW_BUFFERS */
> > gl_format rb_format = _mesa_get_render_format(ctx,
> intel_rb_format(irb));
> > -
> > - assert(!layered);
> > + uint32_t surftype;
> > + bool is_array = false;
> > + int depth = rb->Depth > 0 ? rb->Depth - 1 : 0;
> > + int min_array_element = 0;
> >
> > uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
> > 8 * 4, 32,
> &brw->wm.surf_offset[unit]);
> > @@ -550,7 +552,23 @@ gen7_update_renderbuffer_surface(struct brw_context
> *brw,
> > __FUNCTION__, _mesa_get_format_name(rb_format));
> > }
> >
> > - surf[0] = BRW_SURFACE_2D << BRW_SURFACE_TYPE_SHIFT |
> > + if (rb->TexImage) {
> > + surftype = translate_tex_target(rb->TexImage->TexObject->Target);
> > + is_array =
> _mesa_tex_target_is_array(rb->TexImage->TexObject->Target);
> > + if (rb->TexImage->TexObject->Target == GL_TEXTURE_CUBE_MAP_ARRAY)
> {
> > + assert(rb->Depth > 0);
> > + surftype = BRW_SURFACE_2D;
> > + depth = (6 * (depth + 1)) - 1;
> > + } else if (rb->TexImage->TexObject->Target ==
> GL_TEXTURE_CUBE_MAP) {
> > + surftype = BRW_SURFACE_2D;
> > + depth = 5;
> > + is_array = true;
> > + }
> > + } else {
> > + surftype = BRW_SURFACE_2D;
> > + }
> > +
> > + surf[0] = surftype << BRW_SURFACE_TYPE_SHIFT |
> > format << BRW_SURFACE_FORMAT_SHIFT |
> > (irb->mt->array_spacing_lod0 ? GEN7_SURFACE_ARYSPC_LOD0
> >: GEN7_SURFACE_ARYSPC_FULL) |
> > @@ -561,24 +579,33 @@ gen7_update_renderbuffer_surface(struct
> brw_context *brw,
> > if (irb->mt->align_w == 8)
> >surf[0] |= GEN7_SURFACE_HALIGN_8;
> >
> > - /* reloc */
> > - surf[1] = intel_renderbuffer_tile_offsets(irb, &tile_x, &tile_y) +
> > - region->bo->offset; /* reloc */
> > + if (is_array) {
> > + surf[0] |= GEN7_SURFACE_IS_ARRAY;
> > + }
> > +
> > + if (!layered) {
> > +
[Mesa-dev] [Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync
https://bugs.freedesktop.org/show_bug.cgi?id=64649 Mathias Anselmann changed: What|Removed |Added CC||mathias.anselm...@linux.com --- Comment #12 from Mathias Anselmann --- 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_dri.so[f4b61000+1512000] I'm using mesa 9.1.2 and kernel 3.9.3 (up to date arch system). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/10] i965: Rely on hardware contexts for query objects on Gen6+.
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/drivers/dri/i965/brw_context.c @@ -88,6 +88,8 @@ static void brwInitDriverFunctions(struct intel_screen *screen, brwInitFragProgFuncs( functions ); brw_init_queryobj_functions(functions); + if (screen->gen >= 6) + gen6_reinit_queryobj_functions(functions); I find it confusing that we initialize the queryobj function pointers to the pre-gen6 functions and then immediately override some of them to gen6+ versions. How about splitting brw_init_queryobj_functions() into brw_init_common_queryobj_functions() and brw_init_pre_gen6_queryobj_functions(), and renaming gen6_reinit_queryobj_functions() to just gen6_init_queryobj_functions()? Then this code would change to: brw_init_common_queryobj_functions() if (screen->gen < 6) brw_init_pre_gen6_queryobj_functions() else gen6_init_queryobj_functions() Sure. I've done that for v2. functions->QuerySamplesForFormat = brw_query_samples_for_format; functions->BeginTransformFeedback = brw_begin_transform_feedback; diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index 9baf57b..9ef6aca 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -1164,6 +1164,9 @@ void brw_init_queryobj_functions(struct dd_function_table *functions); void brw_emit_query_begin(struct brw_context *brw); void brw_emit_query_end(struct brw_context *brw); +/** gen6_queryobj.c */ +void gen6_reinit_queryobj_functions(struct dd_function_table *functions); + /*== * brw_state_dump.c */ diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c b/src/mesa/drivers/dri/i965/brw_queryobj.c index 40f926b..1c1e0b4 100644 --- a/src/mesa/drivers/dri/i965/brw_queryobj.c +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c So is brw_queryobj.c now for pre-Gen6 only? If so, can we please add a comment to that effect at the top of the file, and remove the remaining intel->gen checks (e.g. in write_timestamp())? If not, can we somehow document which functions are Pre-gen6 and which aren't (e.g. with "assert(intel->gen < 6);" at the top of the pre-gen6 functions)? As it stands this patch leaves the file in a condition where it's hard to tell without a deep understanding of the driver which functions are for which chip generations. Not completely. The timer query functions are still shared, as are the new/delete hooks. I've added a bunch of assertions and comments to clarify. [snip] case GL_SAMPLES_PASSED_ARB: Below this code, in the GL_PRIMITIVES_GENERATED and GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN cases, can we change the comment so that instead of saying "We don't actually query the hardware for this value, so query->bo should always be NULL and execution should never reach here." it says something like "Transform feedback isn't supported pre-gen6"? Similarly, there's code in brw_begin_query() and brw_end_query() for handling GL_PRIMITIVES_GENERATED and GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN that is now unreachable because we don't support transform feedback prior to Gen6. I think we should replace it with a comment to that affect and an assertion. I've done basically just that in a follow-up patch which reworks a bunch of the transform feedback stuff. Unless it's a big deal, I'll just plan on keeping it as a follow-up. @@ -545,6 +502,9 @@ brw_emit_query_begin(struct brw_context *brw) struct gl_context *ctx = &intel->ctx; struct brw_query_object *query = brw->query.obj; + if (intel->hw_ctx) + return; + The comment above brw_emit_query_begin() says that we record PS_DEPTH_COUNT at the beginning and end of each batch, regardless of whether hardware contexts are in use. Can we please change the comment to reflect the new behavioukr? Done. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gen6+ hardware contexts & query object improvements
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 release for several more > months. > > It then splits our query code into Gen4-5 and Gen6+ versions. The new > Gen6+ version is a lot simpler since hardware contexts guarantee that > our statistics registers don't get polluted with data from other > programs running on the system. It should be more efficient, which > may help games like Minecraft (though I haven't measured). > > Finally, it implements the GL_PRIMITIVES_GENERATED and > GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries via hardware counters > rather than manually counting on the CPU. This paves the way for > geometry shader support (which can output multiple primitives, breaking > our CPU-side tracking), and should allow us to enable hardware primitive > restart in a few more cases once a few more things are tidied. > > The next step is to eliminate the use of SOL reset and save/restore the > transform feedback offsets directly. Then we can turn on hardware > primitive restart more aggressively and implement a few more transform > feedback extensions. > > Thanks in advance for the review. > > --Ken > I made comments on patches 1, 2, 5, 9, and 10. I agree with Eric's comments on patch 7. The remaining patches are: Reviewed-by: Paul Berry > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] i965: Implement transform feedback query support in hardware on Gen6+.
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 Geometry Shaders,
> which can output an arbitrary number of primitives on the GPU.
>
While you're giving rationales, another justification is that this will let
us use hardware primitive restart support when transform feedback and/or
primitive counting is in use.
>
> The GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN query is easy: it
> corresponds to the SO_NUM_PRIMS_WRITTEN/SO_NUM_PRIMS_WRITTEN0_IVB
> counters.
>
> The GL_PRIMITIVES_GENERATED query is trickier. Gen provides several
> statistics registers which /almost/ match the semantics required:
> - IA_PRIMITIVES_COUNT
> The number of primitives fetched by the VF or IA (input assembler).
> This undercounts when GS is enabled, as it can output many primitives.
> - GS_PRIMITIVES_COUNT
> The number of primitives output by the GS. Unfortunately, this
> doesn't increment unless the GS unit is actually enabled, and it
> usually isn't.
> - SO_PRIM_STORAGE_NEEDED*_IVB
> The amount of space needed to write primitives output by transform
> feedback. These naturally only work when transform feedback is on.
> We'd also have to add the counters for all four streams.
> - CL_INVOCATION_COUNT
> The number of primitives processed by the clipper. This doesn't work
> if the GS or SOL throw away primitives for rasterizer discard.
> However, it does increment even if the clipper is in REJECT_ALL mode.
>
> Dynamically switching between counters would be painfully complicated,
> especially since GS, rasterizer discard, and transform feedback can all
> be switched on and off repeatedly during a single query.
>
> The most usable counter is CL_INVOCATION_COUNT. The previous two
> patches reworked rasterizer discard support so that all primitives hit
> the clipper, making this work.
>
> Cc: Eric Anholt
> Cc: Paul Berry
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/gen6_queryobj.c | 105
> +++---
> 1 file changed, 66 insertions(+), 39 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c
> b/src/mesa/drivers/dri/i965/gen6_queryobj.c
> index 28af8d7..a032227 100644
> --- a/src/mesa/drivers/dri/i965/gen6_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/gen6_queryobj.c
> @@ -94,6 +94,57 @@ write_depth_count(struct intel_context *intel,
> drm_intel_bo *query_bo, int idx)
> ADVANCE_BATCH();
> }
>
> +/*
> + * Write an arbitrary 64-bit register to a buffer via
> MI_STORE_REGISTER_MEM.
> + *
> + * Only TIMESTAMP and PS_DEPTH_COUNT have special PIPE_CONTROL support;
> other
> + * counters have to be read via the generic MI_STORE_REGISTER_MEM. This
> + * function also performs a pipeline flush for proper synchronization.
> + */
> +static void
> +write_reg(struct intel_context *intel,
> + drm_intel_bo *query_bo, uint32_t reg, int idx)
> +{
> + assert(intel->gen >= 6);
> +
> + intel_batchbuffer_emit_mi_flush(intel);
> +
> + /* MI_STORE_REGISTER_MEM only stores a single 32-bit value, so to
> +* read a full 64-bit register, we need to do two of them.
> +*/
> + BEGIN_BATCH(3);
> + OUT_BATCH(MI_STORE_REGISTER_MEM | (3 - 2));
> + OUT_BATCH(reg);
> + OUT_RELOC(query_bo, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
> + idx * sizeof(uint64_t));
> + ADVANCE_BATCH();
> +
> + BEGIN_BATCH(3);
> + OUT_BATCH(MI_STORE_REGISTER_MEM | (3 - 2));
> + OUT_BATCH(reg + sizeof(uint32_t));
> + OUT_RELOC(query_bo, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
> + sizeof(uint32_t) + idx * sizeof(uint64_t));
> + ADVANCE_BATCH();
> +}
> +
> +static void
> +write_primitives_generated(struct intel_context *intel,
> + drm_intel_bo *query_bo, int idx)
> +{
> + write_reg(intel, query_bo, CL_INVOCATION_COUNT, idx);
> +}
> +
> +static void
> +write_xfb_primitives_written(struct intel_context *intel,
> + drm_intel_bo *query_bo, int idx)
> +{
> + if (intel->gen >= 7) {
> + write_reg(intel, query_bo, SO_NUM_PRIMS_WRITTEN0_IVB, idx);
> + } else {
> + write_reg(intel, query_bo, SO_NUM_PRIMS_WRITTEN, idx);
> + }
> +}
> +
> /**
> * Wait on the query object's BO and calculate the final result.
> */
> @@ -152,21 +203,20 @@ gen6_queryobj_get_results(struct gl_context *ctx,
>query->Base.Result &= (1ull << 36) - 1;
>break;
>
> - case GL_SAMPLES_PASSED_ARB:
> - query->Base.Result += results[1] - results[0];
> - break;
> -
> case GL_ANY_SAMPLES_PASSED:
> case GL_ANY_SAMPLES_PASSED_CONSERVATIVE:
> - query->Base.Result = results[0] != results[1];
> + if (results[0] != results[1])
> + query->Base.Result = true;
>
This looks like it got squashed into the wrong
Re: [Mesa-dev] [PATCH 09/10] i965: Handle rasterizer discard in the clipper rather than GS on Gen6.
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 discard is not
> the most common of cases, so hopefully it won't be too terrible.
>
> Cc: Eric Anholt
> Cc: Paul Berry
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_gs.c | 9 +
> src/mesa/drivers/dri/i965/brw_gs_emit.c | 30
> -
> src/mesa/drivers/dri/i965/gen6_clip_state.c | 6 +-
> 3 files changed, 6 insertions(+), 39 deletions(-)
>
> This patch prevents breakage in patch 10. See patch 10 for the rationale.
>
This patch removes the last use of brw_gs_prog_key::rasterizer_discard.
Let's remove that unused field to avoid future confusion.
With that change, this patch is:
Reviewed-by: Paul Berry
>
> diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
> b/src/mesa/drivers/dri/i965/brw_gs.c
> index a432b76..f354dd9 100644
> --- a/src/mesa/drivers/dri/i965/brw_gs.c
> +++ b/src/mesa/drivers/dri/i965/brw_gs.c
> @@ -214,12 +214,6 @@ static void populate_key( struct brw_context *brw,
>
> swizzle_for_offset[linked_xfb_info->Outputs[i].ComponentOffset];
> }
>}
> - /* On Gen6, GS is also used for rasterizer discard. */
> - /* BRW_NEW_RASTERIZER_DISCARD */
> - if (ctx->RasterDiscard) {
> - key->need_gs_prog = true;
> - key->rasterizer_discard = true;
> - }
> } else {
>/* Pre-gen6, GS is used to transform QUADLIST, QUADSTRIP, and
> LINELOOP
> * into simpler primitives.
> @@ -259,8 +253,7 @@ const struct brw_tracked_state brw_gs_prog = {
> .dirty = {
>.mesa = (_NEW_LIGHT),
>.brw = (BRW_NEW_PRIMITIVE |
> -BRW_NEW_TRANSFORM_FEEDBACK |
> -BRW_NEW_RASTERIZER_DISCARD),
> +BRW_NEW_TRANSFORM_FEEDBACK),
>.cache = CACHE_NEW_VS_PROG
> },
> .emit = brw_upload_gs_prog
> diff --git a/src/mesa/drivers/dri/i965/brw_gs_emit.c
> b/src/mesa/drivers/dri/i965/brw_gs_emit.c
> index 87ff9f0..cbfc6aa 100644
> --- a/src/mesa/drivers/dri/i965/brw_gs_emit.c
> +++ b/src/mesa/drivers/dri/i965/brw_gs_emit.c
> @@ -201,28 +201,6 @@ static void brw_gs_emit_vue(struct brw_gs_compile *c,
> }
>
> /**
> - * De-allocate the URB entry that was previously allocated to this thread
> - * (without writing any vertex data to it), and terminate the thread.
> This is
> - * used to implement RASTERIZER_DISCARD functionality.
> - */
> -static void brw_gs_terminate(struct brw_gs_compile *c)
> -{
> - struct brw_compile *p = &c->func;
> - brw_urb_WRITE(p,
> - retype(brw_null_reg(), BRW_REGISTER_TYPE_UD), /* dest */
> - 0, /* msg_reg_nr */
> - c->reg.header, /* src0 */
> - false, /* allocate */
> - false, /* used */
> - 1, /* msg_length */
> - 0, /* response_length */
> - true, /* eot */
> - true, /* writes_complete */
> - 0, /* offset */
> - BRW_URB_SWIZZLE_NONE);
> -}
> -
> -/**
> * Send an FF_SYNC message to ensure that all previously spawned GS
> threads
> * have finished sending primitives down the pipeline, and to allocate a
> URB
> * entry for the first output vertex. Only needed when
> intel->needs_ff_sync
> @@ -484,14 +462,6 @@ gen6_sol_program(struct brw_gs_compile *c, struct
> brw_gs_prog_key *key,
>
> brw_gs_ff_sync(c, 1);
>
> - /* If RASTERIZER_DISCARD is enabled, we have nothing further to do, so
> -* release the URB that was just allocated, and terminate the thread.
> -*/
> - if (key->rasterizer_discard) {
> - brw_gs_terminate(c);
> - return;
> - }
> -
> brw_gs_overwrite_header_dw2_from_r0(c);
> switch (num_verts) {
> case 1:
> diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
> b/src/mesa/drivers/dri/i965/gen6_clip_state.c
> index 1811a3f..b5e22dc 100644
> --- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
> @@ -77,6 +77,10 @@ upload_clip_state(struct brw_context *brw)
>dw2 |= GEN6_CLIP_GB_TEST;
> }
>
> + /* BRW_NEW_RASTERIZER_DISCARD */
> + if (ctx->RasterDiscard)
> + dw2 |= GEN6_CLIP_MODE_REJECT_ALL;
> +
> BEGIN_BATCH(4);
> OUT_BATCH(_3DSTATE_CLIP << 16 | (4 - 2));
> OUT_BATCH(dw1);
> @@ -94,7 +98,7 @@ upload_clip_state(struct brw_context *brw)
> const struct brw_tracked_state gen6_clip_state = {
> .dirty = {
>.mesa = _NEW_TRANSFORM | _NEW_LIGHT | _NEW_BUFFERS,
> - .brw = (BRW_NEW_CONTEXT),
> + .brw = BRW_NEW_CONTEXT | BRW_NEW_RASTERIZER_DISCARD,
>.cache = CACHE_NEW_WM_PROG
> },
> .emit = upload_clip_state,
> --
> 1.8.2.3
>
>
Re: [Mesa-dev] [PATCH 05/10] i965: Rely on hardware contexts for query objects on Gen6+.
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 write a single pair of values (one at
> BeginQuery and one at EndQuery) rather than a series of pairs. This
> also means we don't need to worry about the BO getting full. We also
> don't need to delay BO allocation and starting snapshot until the first
> draw.
>
> The generation split here is a little off: technically, Ironlake can also
> support hardware contexts. However, the kernel currently doesn't, and
> even if it were to do so someday, we'd need to wait a while before
> bumping the kernel requirement to take advantage of it.
>
> Cc: Eric Anholt
> Cc: Paul Berry
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/Makefile.sources | 1 +
> src/mesa/drivers/dri/i965/brw_context.c| 2 +
> src/mesa/drivers/dri/i965/brw_context.h| 3 +
> src/mesa/drivers/dri/i965/brw_queryobj.c | 83 ++-
> src/mesa/drivers/dri/i965/gen6_queryobj.c | 354
> +
> 5 files changed, 383 insertions(+), 60 deletions(-)
> create mode 100644 src/mesa/drivers/dri/i965/gen6_queryobj.c
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index a0ffd3a..d67a5a4 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -104,6 +104,7 @@ i965_FILES = \
> gen6_depthstencil.c \
> gen6_gs_state.c \
> gen6_multisample_state.c \
> + gen6_queryobj.c \
> gen6_sampler_state.c \
> gen6_scissor_state.c \
> gen6_sf_state.c \
> 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/drivers/dri/i965/brw_context.c
> @@ -88,6 +88,8 @@ static void brwInitDriverFunctions(struct intel_screen
> *screen,
>
> brwInitFragProgFuncs( functions );
> brw_init_queryobj_functions(functions);
> + if (screen->gen >= 6)
> + gen6_reinit_queryobj_functions(functions);
>
I find it confusing that we initialize the queryobj function pointers to
the pre-gen6 functions and then immediately override some of them to gen6+
versions.
How about splitting brw_init_queryobj_functions() into
brw_init_common_queryobj_functions() and
brw_init_pre_gen6_queryobj_functions(), and renaming
gen6_reinit_queryobj_functions() to just gen6_init_queryobj_functions()?
Then this code would change to:
brw_init_common_queryobj_functions()
if (screen->gen < 6)
brw_init_pre_gen6_queryobj_functions()
else
gen6_init_queryobj_functions()
>
> functions->QuerySamplesForFormat = brw_query_samples_for_format;
> functions->BeginTransformFeedback = brw_begin_transform_feedback;
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 9baf57b..9ef6aca 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1164,6 +1164,9 @@ void brw_init_queryobj_functions(struct
> dd_function_table *functions);
> void brw_emit_query_begin(struct brw_context *brw);
> void brw_emit_query_end(struct brw_context *brw);
>
> +/** gen6_queryobj.c */
> +void gen6_reinit_queryobj_functions(struct dd_function_table *functions);
> +
> /*==
> * brw_state_dump.c
> */
> diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
> b/src/mesa/drivers/dri/i965/brw_queryobj.c
> index 40f926b..1c1e0b4 100644
> --- a/src/mesa/drivers/dri/i965/brw_queryobj.c
> +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
>
So is brw_queryobj.c now for pre-Gen6 only? If so, can we please add a
comment to that effect at the top of the file, and remove the remaining
intel->gen checks (e.g. in write_timestamp())? If not, can we somehow
document which functions are Pre-gen6 and which aren't (e.g. with
"assert(intel->gen < 6);" at the top of the pre-gen6 functions)? As it
stands this patch leaves the file in a condition where it's hard to tell
without a deep understanding of the driver which functions are for which
chip generations.
> @@ -94,40 +94,21 @@ write_timestamp(struct intel_context *intel,
> drm_intel_bo *query_bo, int idx)
> static void
> write_depth_count(struct intel_context *intel, drm_intel_bo *query_bo,
> int idx)
> {
>
- if (intel->gen >= 6) {
> - /* Emit Sandybridge workaround flush: */
> - if (intel->gen == 6)
> - intel_emit_post_sync_nonzero_flush(intel);
> -
> - BEGIN_BATCH(5);
> - OUT_BATCH(_3DSTATE_PIPE_CONTROL | (5 - 2));
> - OUT_BATCH(PIPE_CONTROL_DEPTH_STALL |
> -PIPE_CONTROL_WRITE_DEPTH_COUNT);
> - OUT_RELOC(qu
[Mesa-dev] [Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync
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 mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] i965: Bump kernel requirement to 3.3 on Ivybridge.
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-off-by: Kenneth Graunke
>> ---
>> src/mesa/drivers/dri/intel/intel_extensions.c | 5 +
>> src/mesa/drivers/dri/intel/intel_screen.c | 26
>> +++---
>> src/mesa/drivers/dri/intel/intel_screen.h | 2 --
>> 3 files changed, 12 insertions(+), 21 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
>> b/src/mesa/drivers/dri/intel/intel_extensions.c
>> index 8d8e325..5cb2fa3 100644
>> --- a/src/mesa/drivers/dri/intel/intel_extensions.c
>> +++ b/src/mesa/drivers/dri/intel/intel_extensions.c
>> @@ -91,12 +91,9 @@ intelInitExtensions(struct gl_context *ctx)
>>ctx->Const.GLSLVersion = 120;
>> _mesa_override_glsl_version(ctx);
>>
>> - if (intel->gen == 6 ||
>> - (intel->gen == 7 &&
>> intel->intelScreen->kernel_has_gen7_sol_reset))
>> - ctx->Extensions.EXT_transform_feedback = true;
>> -
>> if (intel->gen >= 6) {
>>ctx->Extensions.EXT_framebuffer_multisample = true;
>> + ctx->Extensions.EXT_transform_feedback = true;
>>ctx->Extensions.ARB_blend_func_extended =
>> !driQueryOptionb(&intel->optionCache, "disable_blend_func_extended");
>>ctx->Extensions.ARB_draw_buffers_blend = true;
>>ctx->Extensions.ARB_ES3_compatibility = true;
>> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
>> b/src/mesa/drivers/dri/intel/intel_screen.c
>> index ad1b351..f3dc908 100644
>> --- a/src/mesa/drivers/dri/intel/intel_screen.c
>> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
>> @@ -1195,17 +1195,10 @@ set_max_gl_versions(struct intel_screen *screen)
>>
>> switch (screen->gen) {
>> case 7:
>> - if (screen->kernel_has_gen7_sol_reset) {
>> - screen->max_gl_core_version = 31;
>> - screen->max_gl_compat_version = 30;
>> - screen->max_gl_es1_version = 11;
>> - screen->max_gl_es2_version = 30;
>> - } else {
>> - screen->max_gl_core_version = 0;
>> - screen->max_gl_compat_version = 21;
>> - screen->max_gl_es1_version = 11;
>> - screen->max_gl_es2_version = 20;
>> - }
>> + screen->max_gl_core_version = 31;
>> + screen->max_gl_compat_version = 30;
>> + screen->max_gl_es1_version = 11;
>> + screen->max_gl_es2_version = 30;
>>break;
>> case 6:
>>screen->max_gl_core_version = 31;
>> @@ -1293,10 +1286,6 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
>>
>> intelScreen->deviceID =
>> drm_intel_bufmgr_gem_get_devid(intelScreen->bufmgr);
>>
>> - intelScreen->kernel_has_gen7_sol_reset =
>> - intel_get_boolean(intelScreen->driScrnPriv,
>> - I915_PARAM_HAS_GEN7_SOL_RESET);
>> -
>> if (IS_GEN7(intelScreen->deviceID)) {
>>intelScreen->gen = 7;
>> } else if (IS_GEN6(intelScreen->deviceID)) {
>> @@ -1311,6 +1300,13 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
>>intelScreen->gen = 2;
>> }
>>
>> + if (intelScreen->gen == 7 &&
>>
>
> For future-proofing sake can we make this "intelScreen->gen >= 7"?
>
> With that change, this patch is:
>
> Reviewed-by: Paul Berry
>
Never mind. I just noticed that this code goes away again in patch 3/10.
In light of that, this patch gets my R-b with or without the change.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/10] i965: Require hardware contexts (and thus Kernel 3.6) on Gen6+.
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 shaders violate that assumption.
>
> At the time of writing, Debian has moved to Kernel 3.8, which means most
> people probably have a newer kernel by now. It's also worth noting that
> this patch won't land until Mesa 10 which is currently targeted for
> September. By that point, even more people will have a newer kernel.
>
> This patch leaves the code for flagging BRW_NEW_CONTEXT on new
> batchbuffers if hw_ctx == NULL since that still occurs pre-Gen6.
>
There's a slight change here that I'd like to see documented more clearly
in the commit message:
Previously, Mesa would *try* to allocate a hardware context regardless of
intel->gen. That would always fail for gen<6 (since the kernel doesn't
support hardware contexts prior to gen6), and would sometimes fail and
sometimes succeed on gen6+, depending on kernel version. Now, Mesa doesn't
even try to allocate a hardware context if gen<6.
With that changed, this is:
Reviewed-by: Paul Berry
>
> Cc: Eric Anholt
> Cc: Paul Berry
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 69b7e4d..2f5fedb 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -143,6 +143,23 @@ brwCreateContext(int api,
>return false;
> }
>
> + if (intel->gen >= 6) {
> + /* Create a new hardware context. Using a hardware context means
> that
> + * our GPU state will be saved/restored on context switch, allowing
> us
> + * to assume that the GPU is in the same state we left it in.
> + *
> + * This is required for transform feedback buffer offsets, query
> objects,
> + * and also allows us to reduce how much state we have to emit.
> + */
> + intel->hw_ctx = drm_intel_gem_context_create(intel->bufmgr);
> +
> + if (!intel->hw_ctx) {
> + fprintf(stderr, "Gen6+ requires Kernel 3.6 or later.\n");
> + ralloc_free(brw);
> + return false;
> + }
> + }
> +
> brw_init_surface_formats(brw);
>
> /* Initialize swrast, tnl driver tables: */
> @@ -374,7 +391,6 @@ brwCreateContext(int api,
>
> brw->prim_restart.in_progress = false;
> brw->prim_restart.enable_cut_index = false;
> - intel->hw_ctx = drm_intel_gem_context_create(intel->bufmgr);
>
> brw_init_state( brw );
>
> --
> 1.8.2.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] i965: Bump kernel requirement to 3.3 on Ivybridge.
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/dri/intel/intel_extensions.c | 5 +
> src/mesa/drivers/dri/intel/intel_screen.c | 26
> +++---
> src/mesa/drivers/dri/intel/intel_screen.h | 2 --
> 3 files changed, 12 insertions(+), 21 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
> b/src/mesa/drivers/dri/intel/intel_extensions.c
> index 8d8e325..5cb2fa3 100644
> --- a/src/mesa/drivers/dri/intel/intel_extensions.c
> +++ b/src/mesa/drivers/dri/intel/intel_extensions.c
> @@ -91,12 +91,9 @@ intelInitExtensions(struct gl_context *ctx)
>ctx->Const.GLSLVersion = 120;
> _mesa_override_glsl_version(ctx);
>
> - if (intel->gen == 6 ||
> - (intel->gen == 7 && intel->intelScreen->kernel_has_gen7_sol_reset))
> - ctx->Extensions.EXT_transform_feedback = true;
> -
> if (intel->gen >= 6) {
>ctx->Extensions.EXT_framebuffer_multisample = true;
> + ctx->Extensions.EXT_transform_feedback = true;
>ctx->Extensions.ARB_blend_func_extended =
> !driQueryOptionb(&intel->optionCache, "disable_blend_func_extended");
>ctx->Extensions.ARB_draw_buffers_blend = true;
>ctx->Extensions.ARB_ES3_compatibility = true;
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> b/src/mesa/drivers/dri/intel/intel_screen.c
> index ad1b351..f3dc908 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.c
> +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> @@ -1195,17 +1195,10 @@ set_max_gl_versions(struct intel_screen *screen)
>
> switch (screen->gen) {
> case 7:
> - if (screen->kernel_has_gen7_sol_reset) {
> - screen->max_gl_core_version = 31;
> - screen->max_gl_compat_version = 30;
> - screen->max_gl_es1_version = 11;
> - screen->max_gl_es2_version = 30;
> - } else {
> - screen->max_gl_core_version = 0;
> - screen->max_gl_compat_version = 21;
> - screen->max_gl_es1_version = 11;
> - screen->max_gl_es2_version = 20;
> - }
> + screen->max_gl_core_version = 31;
> + screen->max_gl_compat_version = 30;
> + screen->max_gl_es1_version = 11;
> + screen->max_gl_es2_version = 30;
>break;
> case 6:
>screen->max_gl_core_version = 31;
> @@ -1293,10 +1286,6 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
>
> intelScreen->deviceID =
> drm_intel_bufmgr_gem_get_devid(intelScreen->bufmgr);
>
> - intelScreen->kernel_has_gen7_sol_reset =
> - intel_get_boolean(intelScreen->driScrnPriv,
> - I915_PARAM_HAS_GEN7_SOL_RESET);
> -
> if (IS_GEN7(intelScreen->deviceID)) {
>intelScreen->gen = 7;
> } else if (IS_GEN6(intelScreen->deviceID)) {
> @@ -1311,6 +1300,13 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
>intelScreen->gen = 2;
> }
>
> + if (intelScreen->gen == 7 &&
>
For future-proofing sake can we make this "intelScreen->gen >= 7"?
With that change, this patch is:
Reviewed-by: Paul Berry
> + !intel_get_boolean(intelScreen->driScrnPriv,
> + I915_PARAM_HAS_GEN7_SOL_RESET)) {
> + fprintf(stderr, "i965 requires Kernel 3.3 or later.\n");
> + return false;
> + }
> +
> intelScreen->hw_has_separate_stencil = intelScreen->gen >= 6;
> intelScreen->hw_must_use_separate_stencil = intelScreen->gen >= 7;
>
> diff --git a/src/mesa/drivers/dri/intel/intel_screen.h
> b/src/mesa/drivers/dri/intel/intel_screen.h
> index 7da9895..4833937 100644
> --- a/src/mesa/drivers/dri/intel/intel_screen.h
> +++ b/src/mesa/drivers/dri/intel/intel_screen.h
> @@ -60,8 +60,6 @@ struct intel_screen
> bool hw_has_separate_stencil;
> bool hw_must_use_separate_stencil;
>
> - bool kernel_has_gen7_sol_reset;
> -
> bool hw_has_llc;
> bool hw_has_swizzling;
>
> --
> 1.8.2.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] r600g/llvm: Factorize code loading from const buffer.
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/r600_llvm.c
> b/src/gallium/drivers/r600/r600_llvm.c
> index c6c9123..26d40a2 100644
> --- a/src/gallium/drivers/r600/r600_llvm.c
> +++ b/src/gallium/drivers/r600/r600_llvm.c
> @@ -23,30 +23,40 @@
> #define CONSTANT_BUFFER_0_ADDR_SPACE 8
> #define CONSTANT_BUFFER_1_ADDR_SPACE (CONSTANT_BUFFER_0_ADDR_SPACE +
> R600_UCP_CONST_BUFFER)
>
> +static LLVMValueRef llvm_load_const_buffer(
> + struct lp_build_tgsi_context * bld_base,
> + LLVMValueRef OffsetValue,
> + unsigned ConstantAddressSpace)
> +{
> + LLVMValueRef offset[2] = {
> +
> LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0,
> false),
> + OffsetValue
> + };
> +
> + LLVMTypeRef const_ptr_type =
> LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
> 1024),
> + ConstantAddressSpace);
> + LLVMValueRef const_ptr =
> LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
> lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
> + LLVMValueRef ptr = LLVMBuildGEP(bld_base->base.gallivm->builder,
> const_ptr, offset, 2, "");
> + return LLVMBuildLoad(bld_base->base.gallivm->builder, ptr, "");
> +}
> +
> static LLVMValueRef llvm_fetch_const(
> struct lp_build_tgsi_context * bld_base,
> const struct tgsi_full_src_register *reg,
> enum tgsi_opcode_type type,
> unsigned swizzle)
> {
> - LLVMValueRef offset[2] = {
> -
> LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0,
> false),
> - lp_build_const_int32(bld_base->base.gallivm,
> reg->Register.Index)
> - };
> + LLVMValueRef offset = lp_build_const_int32(bld_base->base.gallivm,
> reg->Register.Index);
> if (reg->Register.Indirect) {
> struct lp_build_tgsi_soa_context *bld =
> lp_soa_context(bld_base);
> LLVMValueRef index =
> LLVMBuildLoad(bld_base->base.gallivm->builder,
> bld->addr[reg->Indirect.Index][reg->Indirect.Swizzle], "");
> - offset[1] = LLVMBuildAdd(bld_base->base.gallivm->builder,
> offset[1], index, "");
> + offset = LLVMBuildAdd(bld_base->base.gallivm->builder, offset,
> index, "");
> }
> unsigned ConstantAddressSpace = CONSTANT_BUFFER_0_ADDR_SPACE ;
> if (reg->Register.Dimension) {
> ConstantAddressSpace += reg->Dimension.Index;
> }
> - LLVMTypeRef const_ptr_type =
> LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
> 1024),
> - ConstantAddressSpace);
> - LLVMValueRef const_ptr =
> LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
> lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
> - LLVMValueRef ptr = LLVMBuildGEP(bld_base->base.gallivm->builder,
> const_ptr, offset, 2, "");
> - LLVMValueRef cvecval = LLVMBuildLoad(bld_base->base.gallivm->builder,
> ptr, "");
> + LLVMValueRef cvecval = llvm_load_const_buffer(bld_base, offset,
> ConstantAddressSpace);
> LLVMValueRef cval =
> LLVMBuildExtractElement(bld_base->base.gallivm->builder, cvecval,
> lp_build_const_int32(bld_base->base.gallivm, swizzle), "");
> return bitcast(bld_base, type, cval);
> }
> @@ -250,14 +260,8 @@ static void llvm_emit_epilogue(struct
> lp_build_tgsi_context * bld_base)
> LLVMValueRef adjusted_elements[4];
> for (reg_index = 0; reg_index < 2; reg_index
> ++) {
> for (chan = 0; chan <
> TGSI_NUM_CHANNELS; chan++) {
> - LLVMValueRef offset[2] = {
> -
> LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0,
> false),
> -
> lp_build_const_int32(bld_base->base.gallivm, reg_index * 4 + chan)
> - };
> - LLVMTypeRef const_ptr_type =
> LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
> 1024), CONSTANT_BUFFER_1_ADDR_SPACE);
> - LLVMValueRef const_ptr =
> LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
> lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
> - LLVMValueRef ptr =
> LLVMBuildGEP(bld_base->base.gallivm->builder, const_ptr, offset, 2, "");
> - LLVMValueRef base_vector =
> LLVMBuildLoad(bld_base->base.gal
[Mesa-dev] [Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync
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_DEBUGGER=gdb doesn't seem to work, though I think it should?). The interesting part seems to be (on first glance): >copy_height=DW_OP_GNU_const_type> Again, just to make sure you don't search for a bug that is maybe no longer in r600g: I don't have the latest master for Mesa/libdrm, and it'll take me at least a few days, before I can get around to build a new version. Hency you might want to confirm the backtrace with somebody who runs master. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] r600g/llvm: Fix texelFetchOffset-2D
---
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
@@ -460,6 +460,12 @@ static void llvm_emit_tex(
for (c = 1; c < emit_data->arg_count; ++c)
args[c] = emit_data->args[c];
+ if (emit_data->inst->Instruction.Opcode == TGSI_OPCODE_TXF) {
+ args[1] = LLVMBuildShl(gallivm->builder, args[1],
lp_build_const_int32(gallivm, 1), "");
+ args[2] = LLVMBuildShl(gallivm->builder, args[2],
lp_build_const_int32(gallivm, 1), "");
+ args[3] = LLVMBuildShl(gallivm->builder, args[3],
lp_build_const_int32(gallivm, 1), "");
+ }
+
sampler_src = emit_data->inst->Instruction.NumSrcRegs-1;
args[c++] = lp_build_const_int32(gallivm,
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] r600g/llvm: fix cubemap lod/bias
---
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_llvm.c
+++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
@@ -654,6 +654,9 @@ void radeon_llvm_emit_prepare_cube_coords(
opcode == TGSI_OPCODE_TXB2 ||
opcode == TGSI_OPCODE_TXL2) {
coords[3] = coords_arg[4];
+ } else if (opcode == TGSI_OPCODE_TXB ||
+ opcode == TGSI_OPCODE_TXL) {
+ coords[3] = coords_arg[3];
}
}
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] r600g/llvm: Factorize code loading from const buffer.
---
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
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -23,30 +23,40 @@
#define CONSTANT_BUFFER_0_ADDR_SPACE 8
#define CONSTANT_BUFFER_1_ADDR_SPACE (CONSTANT_BUFFER_0_ADDR_SPACE +
R600_UCP_CONST_BUFFER)
+static LLVMValueRef llvm_load_const_buffer(
+ struct lp_build_tgsi_context * bld_base,
+ LLVMValueRef OffsetValue,
+ unsigned ConstantAddressSpace)
+{
+ LLVMValueRef offset[2] = {
+
LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0, false),
+ OffsetValue
+ };
+
+ LLVMTypeRef const_ptr_type =
LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
1024),
+ ConstantAddressSpace);
+ LLVMValueRef const_ptr =
LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
+ LLVMValueRef ptr = LLVMBuildGEP(bld_base->base.gallivm->builder,
const_ptr, offset, 2, "");
+ return LLVMBuildLoad(bld_base->base.gallivm->builder, ptr, "");
+}
+
static LLVMValueRef llvm_fetch_const(
struct lp_build_tgsi_context * bld_base,
const struct tgsi_full_src_register *reg,
enum tgsi_opcode_type type,
unsigned swizzle)
{
- LLVMValueRef offset[2] = {
-
LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0, false),
- lp_build_const_int32(bld_base->base.gallivm,
reg->Register.Index)
- };
+ LLVMValueRef offset = lp_build_const_int32(bld_base->base.gallivm,
reg->Register.Index);
if (reg->Register.Indirect) {
struct lp_build_tgsi_soa_context *bld =
lp_soa_context(bld_base);
LLVMValueRef index =
LLVMBuildLoad(bld_base->base.gallivm->builder,
bld->addr[reg->Indirect.Index][reg->Indirect.Swizzle], "");
- offset[1] = LLVMBuildAdd(bld_base->base.gallivm->builder,
offset[1], index, "");
+ offset = LLVMBuildAdd(bld_base->base.gallivm->builder, offset,
index, "");
}
unsigned ConstantAddressSpace = CONSTANT_BUFFER_0_ADDR_SPACE ;
if (reg->Register.Dimension) {
ConstantAddressSpace += reg->Dimension.Index;
}
- LLVMTypeRef const_ptr_type =
LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
1024),
- ConstantAddressSpace);
- LLVMValueRef const_ptr =
LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
- LLVMValueRef ptr = LLVMBuildGEP(bld_base->base.gallivm->builder,
const_ptr, offset, 2, "");
- LLVMValueRef cvecval = LLVMBuildLoad(bld_base->base.gallivm->builder,
ptr, "");
+ LLVMValueRef cvecval = llvm_load_const_buffer(bld_base, offset,
ConstantAddressSpace);
LLVMValueRef cval =
LLVMBuildExtractElement(bld_base->base.gallivm->builder, cvecval,
lp_build_const_int32(bld_base->base.gallivm, swizzle), "");
return bitcast(bld_base, type, cval);
}
@@ -250,14 +260,8 @@ static void llvm_emit_epilogue(struct
lp_build_tgsi_context * bld_base)
LLVMValueRef adjusted_elements[4];
for (reg_index = 0; reg_index < 2; reg_index
++) {
for (chan = 0; chan <
TGSI_NUM_CHANNELS; chan++) {
- LLVMValueRef offset[2] = {
-
LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0, false),
-
lp_build_const_int32(bld_base->base.gallivm, reg_index * 4 + chan)
- };
- LLVMTypeRef const_ptr_type =
LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
1024), CONSTANT_BUFFER_1_ADDR_SPACE);
- LLVMValueRef const_ptr =
LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
- LLVMValueRef ptr =
LLVMBuildGEP(bld_base->base.gallivm->builder, const_ptr, offset, 2, "");
- LLVMValueRef base_vector =
LLVMBuildLoad(bld_base->base.gallivm->builder, ptr, "");
+ LLVMValueRef offset =
lp_build_const_int32(bld_base->base.gallivm, reg_index * 4 + chan);
+ LLVMValueRef base_vector
[Mesa-dev] [PATCH 2/4] r600g/llvm: Fix cubearray textureSize
---
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 26d40a2..3d2c492 100644
--- a/src/gallium/drivers/r600/r600_llvm.c
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -22,6 +22,7 @@
#define CONSTANT_BUFFER_0_ADDR_SPACE 8
#define CONSTANT_BUFFER_1_ADDR_SPACE (CONSTANT_BUFFER_0_ADDR_SPACE +
R600_UCP_CONST_BUFFER)
+#define CONSTANT_TXQ_BUFFER (CONSTANT_BUFFER_0_ADDR_SPACE +
R600_TXQ_CONST_BUFFER)
static LLVMValueRef llvm_load_const_buffer(
struct lp_build_tgsi_context * bld_base,
@@ -471,6 +472,20 @@ static void llvm_emit_tex(
emit_data->output[0] = build_intrinsic(gallivm->builder,
action->intr_name,
emit_data->dst_type, args, c,
LLVMReadNoneAttribute);
+
+ if (emit_data->inst->Instruction.Opcode == TGSI_OPCODE_TXQ &&
+ ((emit_data->inst->Texture.Texture == TGSI_TEXTURE_CUBE_ARRAY ||
+ emit_data->inst->Texture.Texture ==
TGSI_TEXTURE_SHADOWCUBE_ARRAY)))
+ if (emit_data->inst->Dst[0].Register.WriteMask & 4) {
+ LLVMValueRef offset =
lp_build_const_int32(bld_base->base.gallivm, 0);
+ LLVMValueRef ZLayer =
LLVMBuildExtractElement(gallivm->builder,
+ llvm_load_const_buffer(bld_base, offset,
CONSTANT_TXQ_BUFFER),
+ lp_build_const_int32(gallivm, 0), "");
+
+ emit_data->output[0] =
LLVMBuildInsertElement(gallivm->builder, emit_data->output[0], ZLayer,
lp_build_const_int32(gallivm, 2), "");
+ struct radeon_llvm_context * ctx =
radeon_llvm_context(bld_base);
+ ctx->has_txq_cube_array_z_comp = true;
+ }
}
static void emit_cndlt(
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 4d74db0..81ed3ce 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -1169,6 +1169,7 @@ static int r600_shader_from_tgsi(struct r600_screen
*rscreen,
radeon_llvm_ctx.clip_vertex = ctx.cv_output;
radeon_llvm_ctx.alpha_to_one = key.alpha_to_one;
mod = r600_tgsi_llvm(&radeon_llvm_ctx, tokens);
+ ctx.shader->has_txq_cube_array_z_comp =
radeon_llvm_ctx.has_txq_cube_array_z_comp;
if (r600_llvm_compile(mod, rscreen->family, ctx.bc, &use_kill,
dump)) {
radeon_llvm_dispose(&radeon_llvm_ctx);
diff --git a/src/gallium/drivers/radeon/radeon_llvm.h
b/src/gallium/drivers/radeon/radeon_llvm.h
index 1d4bd45..14a8c34 100644
--- a/src/gallium/drivers/radeon/radeon_llvm.h
+++ b/src/gallium/drivers/radeon/radeon_llvm.h
@@ -66,6 +66,7 @@ struct radeon_llvm_context {
unsigned color_buffer_count;
unsigned fs_color_all;
unsigned alpha_to_one;
+ unsigned has_txq_cube_array_z_comp;
/*=== Front end configuration ===*/
--
1.8.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] r600g/llvm: Factorize code loading from const buffer.
---
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
+++ b/src/gallium/drivers/r600/r600_llvm.c
@@ -23,30 +23,40 @@
#define CONSTANT_BUFFER_0_ADDR_SPACE 8
#define CONSTANT_BUFFER_1_ADDR_SPACE (CONSTANT_BUFFER_0_ADDR_SPACE +
R600_UCP_CONST_BUFFER)
+static LLVMValueRef llvm_load_const_buffer(
+ struct lp_build_tgsi_context * bld_base,
+ LLVMValueRef OffsetValue,
+ unsigned ConstantAddressSpace)
+{
+ LLVMValueRef offset[2] = {
+
LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0, false),
+ OffsetValue
+ };
+
+ LLVMTypeRef const_ptr_type =
LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
1024),
+ ConstantAddressSpace);
+ LLVMValueRef const_ptr =
LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
+ LLVMValueRef ptr = LLVMBuildGEP(bld_base->base.gallivm->builder,
const_ptr, offset, 2, "");
+ return LLVMBuildLoad(bld_base->base.gallivm->builder, ptr, "");
+}
+
static LLVMValueRef llvm_fetch_const(
struct lp_build_tgsi_context * bld_base,
const struct tgsi_full_src_register *reg,
enum tgsi_opcode_type type,
unsigned swizzle)
{
- LLVMValueRef offset[2] = {
-
LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0, false),
- lp_build_const_int32(bld_base->base.gallivm,
reg->Register.Index)
- };
+ LLVMValueRef offset = lp_build_const_int32(bld_base->base.gallivm,
reg->Register.Index);
if (reg->Register.Indirect) {
struct lp_build_tgsi_soa_context *bld =
lp_soa_context(bld_base);
LLVMValueRef index =
LLVMBuildLoad(bld_base->base.gallivm->builder,
bld->addr[reg->Indirect.Index][reg->Indirect.Swizzle], "");
- offset[1] = LLVMBuildAdd(bld_base->base.gallivm->builder,
offset[1], index, "");
+ offset = LLVMBuildAdd(bld_base->base.gallivm->builder, offset,
index, "");
}
unsigned ConstantAddressSpace = CONSTANT_BUFFER_0_ADDR_SPACE ;
if (reg->Register.Dimension) {
ConstantAddressSpace += reg->Dimension.Index;
}
- LLVMTypeRef const_ptr_type =
LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
1024),
- ConstantAddressSpace);
- LLVMValueRef const_ptr =
LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
- LLVMValueRef ptr = LLVMBuildGEP(bld_base->base.gallivm->builder,
const_ptr, offset, 2, "");
- LLVMValueRef cvecval = LLVMBuildLoad(bld_base->base.gallivm->builder,
ptr, "");
+ LLVMValueRef cvecval = llvm_load_const_buffer(bld_base, offset,
ConstantAddressSpace);
LLVMValueRef cval =
LLVMBuildExtractElement(bld_base->base.gallivm->builder, cvecval,
lp_build_const_int32(bld_base->base.gallivm, swizzle), "");
return bitcast(bld_base, type, cval);
}
@@ -250,14 +260,8 @@ static void llvm_emit_epilogue(struct
lp_build_tgsi_context * bld_base)
LLVMValueRef adjusted_elements[4];
for (reg_index = 0; reg_index < 2; reg_index
++) {
for (chan = 0; chan <
TGSI_NUM_CHANNELS; chan++) {
- LLVMValueRef offset[2] = {
-
LLVMConstInt(LLVMInt64TypeInContext(bld_base->base.gallivm->context), 0, false),
-
lp_build_const_int32(bld_base->base.gallivm, reg_index * 4 + chan)
- };
- LLVMTypeRef const_ptr_type =
LLVMPointerType(LLVMArrayType(LLVMVectorType(bld_base->base.elem_type, 4),
1024), CONSTANT_BUFFER_1_ADDR_SPACE);
- LLVMValueRef const_ptr =
LLVMBuildIntToPtr(bld_base->base.gallivm->builder,
lp_build_const_int32(bld_base->base.gallivm, 0), const_ptr_type, "");
- LLVMValueRef ptr =
LLVMBuildGEP(bld_base->base.gallivm->builder, const_ptr, offset, 2, "");
- LLVMValueRef base_vector =
LLVMBuildLoad(bld_base->base.gallivm->builder, ptr, "");
+ LLVMValueRef offset =
lp_build_const_int32(bld_base->base.gallivm, reg_index * 4 + chan);
+ LLVMValueRef base_vector
[Mesa-dev] [Bug 64791] New: swrast crashes with compiz
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 Reporter: pierre-bugzi...@ossman.eu Hardware: Other Status: NEW Version: unspecified Component: Other Product: Mesa I'm getting a crash when using the classic swrast driver together with compiz. I have no idea how this is supposed to work, but the issue is that getImage() gets called with NULL as the destination buffer. The calling function is swrastSetTexBuffer2(), and to me it looks a bit off. The function fetches the current texture image (creating one if needed), modifies the fields and then calls getImage(). At no point does it adjust the size of the buffer to match the new fields though. So I guess that happened implicitly at some point, but doesn't anymore. I applied this (in the spirit of similiar functions) and that got rid of the crash: Index: mesa/src/mesa/drivers/dri/swrast/swrast.c === --- mesa/src/mesa/drivers/dri/swrast/swrast.c(revision 27412) +++ mesa/src/mesa/drivers/dri/swrast/swrast.c(working copy) @@ -94,9 +94,15 @@ else texFormat = MESA_FORMAT_ARGB; +/* Free old texture image */ +dri_ctx->Base.Driver.FreeTextureImageBuffer(&dri_ctx->Base, texImage); + _mesa_init_teximage_fields(&dri_ctx->Base, texImage, w, h, 1, 0, internalFormat, texFormat); +/* Allocate texture memory (no pixel data yet) */ +dri_ctx->Base.Driver.AllocTextureImageBuffer(&dri_ctx->Base, texImage); + sPriv->swrast_loader->getImage(dPriv, x, y, w, h, (char *)swImage->Buffer, dPriv->loaderPrivate); Unfortunately it doesn't seem to create something that actually works. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SIGFPE in libdrm_radeon on evergreen
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_split=0 from the call site. > > > Yes, I'm just not sure why tile_split is 0 here and what is the best way to > fix it, possibly in fact this is a consequence of some problem in r600g, not > in the libdrm. Though probably libdrm should handle it more gracefully > anyway. > > Vadim Just a guess, ddx is not properly setting tile split on a surface and then r600g call in trying to rebuild miptree ... I think i fixed issue in ddx couple month ago but maybe i did not. Cheers, Jerome >> >> >> On Mon, May 20, 2013 at 4:11 AM, Vadim Girlin >> wrote: >> >>> Reduced test app attached and below is gdb backtrace. I suspect something >>> is not initialized properly but I'm not very familiar with this code. >>> >>> Vadim >>> >>> >>> Program received signal SIGFPE, Arithmetic exception. >>> 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, >>> surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, >>> start_level=0) >>> at radeon_surface.c:651 >>> 651 slice_pt = tileb / tile_split; >>> >>> #0 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, >>> surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, >>> start_level=0) >>> at radeon_surface.c:651 >>> #1 0x76905eea in eg_surface_init_2d_miptrees (surf_man=0x633ea0, >>> surf=0x88d848) at radeon_surface.c:807 >>> #2 0x76906062 in eg_surface_init (surf_man=0x633ea0, >>> surf=0x88d848) at radeon_surface.c:863 >>> #3 0x76907fe6 in radeon_surface_init (surf_man=0x633ea0, >>> surf=0x88d848) at radeon_surface.c:1901 >>> #4 0x7713260b in radeon_drm_winsys_surface_init (rws=0x6339a0, >>> surf=0x88d848) at radeon_drm_winsys.c:477 >>> #5 0x770a3e1c in r600_setup_surface (screen=0x6340d0, >>> rtex=0x88d760, pitch_in_bytes_override=0) at r600_texture.c:203 >>> #6 0x770a4774 in r600_texture_create_object (screen=0x6340d0, >>> base=0x7fffd6d0, pitch_in_bytes_override=0, buf=0x0, >>> surface=0x7fffc8e0) >>> at r600_texture.c:432 >>> #7 0x770a5268 in r600_texture_create (screen=0x6340d0, >>> templ=0x7fffd6d0) at r600_texture.c:607 >>> #8 0x7708a5bd in r600_resource_create (screen=0x6340d0, >>> templ=0x7fffd6d0) at r600_resource.c:38 >>> #9 0x77125579 in dri2_drawable_process_buffers >>> (drawable=0x88af80, buffers=0x88aea0, buffer_count=1, atts=0x88b628, >>> att_count=2) at dri2.c:283 >>> #10 0x7712590a in dri2_allocate_textures (drawable=0x88af80, >>> statts=0x88b628, statts_count=2) at dri2.c:404 >>> #11 0x77123e6a in dri_st_framebuffer_validate (stfbi=0x88af80, >>> statts=0x88b628, count=2, out=0x7fffd840) at dri_drawable.c:81 >>> #12 0x76e461c1 in st_framebuffer_validate (stfb=0x88b1e0, >>> st=0x883870) at ../../src/mesa/state_tracker/**st_manager.c:193 >>> >>> #13 0x76e472a8 in st_api_make_current (stapi=0x7761b9e0 >>> , stctxi=0x883870, stdrawi=0x88af80, streadi=0x88af80) >>> at ../../src/mesa/state_tracker/**st_manager.c:721 >>> >>> #14 0x77122ce8 in dri_make_current (cPriv=0x7fdb70, >>> driDrawPriv=0x88af40, driReadPriv=0x88af40) at dri_context.c:255 >>> #15 0x76c6ba1f in driBindContext (pcp=0x7fdb70, pdp=0x88af40, >>> prp=0x88af40) at ../../../../src/mesa/drivers/**dri/common/dri_util.c:382 >>> >>> #16 0x77dc57e3 in dri2_bind_context (context=0x7fd9d0, >>> old=0x616650, draw=67108873, read=67108873) at dri2_glx.c:172 >>> #17 0x77d8c253 in MakeContextCurrent (dpy=0x602040, >>> draw=67108873, >>> read=67108873, gc_user=0x7fd9d0) at glxcurrent.c:269 >>> #18 0x00384e82713c in fgOpenWindow () from /lib64/libglut.so.3 >>> #19 0x00384e825afa in fgCreateWindow () from /lib64/libglut.so.3 >>> #20 0x00384e825b95 in fgCreateMenu () from /lib64/libglut.so.3 >>> #21 0x00384e823cd3 in glutCreateMenu () from /lib64/libglut.so.3 >>> #22 0x00400816 in main (argc=1, argv=0x7fffdf18) at test.c:17 >>> >>> >>> ___ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >>> >>> >> > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync
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 (nothing else) and "Floating point exception" on the console > where Steam is running. Can you get a proper backtrace with gdb? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync
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 the console where Steam is running. Additional information: Game crashes after intro, which I can watch. Warning: my Mesa/DRM stack is not up-to-date and I can't update it immediately, but since others are seeing this crash too, maybe this helps to find the reason. I'll try to get a recent Mesa/libdrm stack up here soon. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SIGFPE in libdrm_radeon on evergreen
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 here and what is the best way to fix it, possibly in fact this is a consequence of some problem in r600g, not in the libdrm. Though probably libdrm should handle it more gracefully anyway. Vadim On Mon, May 20, 2013 at 4:11 AM, Vadim Girlin wrote: Reduced test app attached and below is gdb backtrace. I suspect something is not initialized properly but I'm not very familiar with this code. Vadim Program received signal SIGFPE, Arithmetic exception. 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0) at radeon_surface.c:651 651 slice_pt = tileb / tile_split; #0 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, start_level=0) at radeon_surface.c:651 #1 0x76905eea in eg_surface_init_2d_miptrees (surf_man=0x633ea0, surf=0x88d848) at radeon_surface.c:807 #2 0x76906062 in eg_surface_init (surf_man=0x633ea0, surf=0x88d848) at radeon_surface.c:863 #3 0x76907fe6 in radeon_surface_init (surf_man=0x633ea0, surf=0x88d848) at radeon_surface.c:1901 #4 0x7713260b in radeon_drm_winsys_surface_init (rws=0x6339a0, surf=0x88d848) at radeon_drm_winsys.c:477 #5 0x770a3e1c in r600_setup_surface (screen=0x6340d0, rtex=0x88d760, pitch_in_bytes_override=0) at r600_texture.c:203 #6 0x770a4774 in r600_texture_create_object (screen=0x6340d0, base=0x7fffd6d0, pitch_in_bytes_override=0, buf=0x0, surface=0x7fffc8e0) at r600_texture.c:432 #7 0x770a5268 in r600_texture_create (screen=0x6340d0, templ=0x7fffd6d0) at r600_texture.c:607 #8 0x7708a5bd in r600_resource_create (screen=0x6340d0, templ=0x7fffd6d0) at r600_resource.c:38 #9 0x77125579 in dri2_drawable_process_buffers (drawable=0x88af80, buffers=0x88aea0, buffer_count=1, atts=0x88b628, att_count=2) at dri2.c:283 #10 0x7712590a in dri2_allocate_textures (drawable=0x88af80, statts=0x88b628, statts_count=2) at dri2.c:404 #11 0x77123e6a in dri_st_framebuffer_validate (stfbi=0x88af80, statts=0x88b628, count=2, out=0x7fffd840) at dri_drawable.c:81 #12 0x76e461c1 in st_framebuffer_validate (stfb=0x88b1e0, st=0x883870) at ../../src/mesa/state_tracker/**st_manager.c:193 #13 0x76e472a8 in st_api_make_current (stapi=0x7761b9e0 , stctxi=0x883870, stdrawi=0x88af80, streadi=0x88af80) at ../../src/mesa/state_tracker/**st_manager.c:721 #14 0x77122ce8 in dri_make_current (cPriv=0x7fdb70, driDrawPriv=0x88af40, driReadPriv=0x88af40) at dri_context.c:255 #15 0x76c6ba1f in driBindContext (pcp=0x7fdb70, pdp=0x88af40, prp=0x88af40) at ../../../../src/mesa/drivers/**dri/common/dri_util.c:382 #16 0x77dc57e3 in dri2_bind_context (context=0x7fd9d0, old=0x616650, draw=67108873, read=67108873) at dri2_glx.c:172 #17 0x77d8c253 in MakeContextCurrent (dpy=0x602040, draw=67108873, read=67108873, gc_user=0x7fd9d0) at glxcurrent.c:269 #18 0x00384e82713c in fgOpenWindow () from /lib64/libglut.so.3 #19 0x00384e825afa in fgCreateWindow () from /lib64/libglut.so.3 #20 0x00384e825b95 in fgCreateMenu () from /lib64/libglut.so.3 #21 0x00384e823cd3 in glutCreateMenu () from /lib64/libglut.so.3 #22 0x00400816 in main (argc=1, argv=0x7fffdf18) at test.c:17 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SIGFPE in libdrm_radeon on evergreen
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 is gdb backtrace. I suspect something > is not initialized properly but I'm not very familiar with this code. > > Vadim > > > Program received signal SIGFPE, Arithmetic exception. > 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, > surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, > start_level=0) > at radeon_surface.c:651 > 651 slice_pt = tileb / tile_split; > > #0 0x769058d7 in eg_surface_init_2d (surf_man=0x633ea0, > surf=0x88d848, level=0x88dea8, bpe=1, tile_split=0, offset=65536, > start_level=0) > at radeon_surface.c:651 > #1 0x76905eea in eg_surface_init_2d_miptrees (surf_man=0x633ea0, > surf=0x88d848) at radeon_surface.c:807 > #2 0x76906062 in eg_surface_init (surf_man=0x633ea0, > surf=0x88d848) at radeon_surface.c:863 > #3 0x76907fe6 in radeon_surface_init (surf_man=0x633ea0, > surf=0x88d848) at radeon_surface.c:1901 > #4 0x7713260b in radeon_drm_winsys_surface_init (rws=0x6339a0, > surf=0x88d848) at radeon_drm_winsys.c:477 > #5 0x770a3e1c in r600_setup_surface (screen=0x6340d0, > rtex=0x88d760, pitch_in_bytes_override=0) at r600_texture.c:203 > #6 0x770a4774 in r600_texture_create_object (screen=0x6340d0, > base=0x7fffd6d0, pitch_in_bytes_override=0, buf=0x0, > surface=0x7fffc8e0) > at r600_texture.c:432 > #7 0x770a5268 in r600_texture_create (screen=0x6340d0, > templ=0x7fffd6d0) at r600_texture.c:607 > #8 0x7708a5bd in r600_resource_create (screen=0x6340d0, > templ=0x7fffd6d0) at r600_resource.c:38 > #9 0x77125579 in dri2_drawable_process_buffers > (drawable=0x88af80, buffers=0x88aea0, buffer_count=1, atts=0x88b628, > att_count=2) at dri2.c:283 > #10 0x7712590a in dri2_allocate_textures (drawable=0x88af80, > statts=0x88b628, statts_count=2) at dri2.c:404 > #11 0x77123e6a in dri_st_framebuffer_validate (stfbi=0x88af80, > statts=0x88b628, count=2, out=0x7fffd840) at dri_drawable.c:81 > #12 0x76e461c1 in st_framebuffer_validate (stfb=0x88b1e0, > st=0x883870) at ../../src/mesa/state_tracker/**st_manager.c:193 > #13 0x76e472a8 in st_api_make_current (stapi=0x7761b9e0 > , stctxi=0x883870, stdrawi=0x88af80, streadi=0x88af80) > at ../../src/mesa/state_tracker/**st_manager.c:721 > #14 0x77122ce8 in dri_make_current (cPriv=0x7fdb70, > driDrawPriv=0x88af40, driReadPriv=0x88af40) at dri_context.c:255 > #15 0x76c6ba1f in driBindContext (pcp=0x7fdb70, pdp=0x88af40, > prp=0x88af40) at ../../../../src/mesa/drivers/**dri/common/dri_util.c:382 > #16 0x77dc57e3 in dri2_bind_context (context=0x7fd9d0, > old=0x616650, draw=67108873, read=67108873) at dri2_glx.c:172 > #17 0x77d8c253 in MakeContextCurrent (dpy=0x602040, draw=67108873, > read=67108873, gc_user=0x7fd9d0) at glxcurrent.c:269 > #18 0x00384e82713c in fgOpenWindow () from /lib64/libglut.so.3 > #19 0x00384e825afa in fgCreateWindow () from /lib64/libglut.so.3 > #20 0x00384e825b95 in fgCreateMenu () from /lib64/libglut.so.3 > #21 0x00384e823cd3 in glutCreateMenu () from /lib64/libglut.so.3 > #22 0x00400816 in main (argc=1, argv=0x7fffdf18) at test.c:17 > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
