[Mesa-dev] Why failover module are not used?

Hi all, In our mesa code, there is a pipe driver named failover which is not used at all. I think the failover pipe driver is a good solution of the hardware without full capability to support GL2.0. But why it's discarded? It's because fallback solution isn't needed for almost all hardware or

[Mesa-dev] [Bug 40860] [bisected] piglit "spec/OES_compressed_paletted_texture/invalid formats" fails

https://bugs.freedesktop.org/show_bug.cgi?id=40860 fangxun changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #3 from fangxun 2011-09-

[Mesa-dev] UBO support

This set of patches add partial support for Uniform Buffer Object (UBO) in mesa. This is still Work In Progress so the last 3 patches are not complete yet, and support from the driver is not done yet. The first 6 patches however can be reviewed. I did not implement UBO "inside shader name" and a

[Mesa-dev] [PATCH 1/9] glapi: Add Uniform Buffer Object API

--- src/mapi/glapi/gen/ARB_Uniform_Buffer_Object.xml | 114 ++ src/mapi/glapi/gen/Makefile |1 + src/mapi/glapi/gen/gl_API.xml|2 +- 3 files changed, 116 insertions(+), 1 deletions(-) create mode 100644 src/mapi/glapi/gen/ARB_U

[Mesa-dev] [PATCH 3/9] mesa : advertise GL_ARB_Uniform_Buffer_Object extension

--- src/glsl/glsl_lexer.ll |3 ++- src/glsl/glsl_parser_extras.cpp |1 + src/glsl/glsl_parser_extras.h |2 ++ 3 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll index cfd8926..a091f62 100644 --- a/src/glsl/glsl_lexe

[Mesa-dev] [PATCH 4/9] mesa: initial data structures for Uniform Buffer Objects

--- src/mesa/main/mtypes.h| 47 - src/mesa/main/shaderobj.c |7 ++ 2 files changed, 53 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index f2eb889..49ae2fa 100644 --- a/src/mesa/main/mtypes.h ++

[Mesa-dev] [PATCH 5/9] glsl: change IR to add UBO information

--- src/glsl/ir.h |2 ++ src/glsl/ir_clone.cpp |2 ++ src/glsl/opt_dead_code.cpp |2 ++ 3 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/glsl/ir.h b/src/glsl/ir.h index 2e899f3..cf57b3e 100644 --- a/src/glsl/ir.h +++ b/src/glsl/ir.h @@ -394,6 +394,8

[Mesa-dev] [PATCH 6/9] glsl: parser now aware of UBO

--- src/glsl/ast.h | 25 ++ src/glsl/ast_to_hir.cpp | 43 ++- src/glsl/glsl_parser.yy | 162 +++ src/glsl/glsl_parser_extras.h |5 + src/mesa/program/ir_to_mesa.cpp |5 + 5 files changed, 239 insertions

[Mesa-dev] [PATCH 7/9] glsl: linker supports UBO

--- src/glsl/linker.cpp | 154 ++- 1 files changed, 152 insertions(+), 2 deletions(-) diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index ba81c59..8dcc0d4 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -784,6 +784,47 @@ get_

[Mesa-dev] [PATCH 8/9] mesa: add Uniform Buffer Object API implementation

--- src/mesa/main/bufferobj.c |2 + src/mesa/main/uniforms.c | 99 + 2 files changed, 101 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c index c453f9c..794cde5 100644 --- a/src/mesa/main/bufferobj

[Mesa-dev] [PATCH 9/9] mesa : Api binding for UBO

--- src/mesa/main/uniforms.c | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c index b923aef..172c817 100644 --- a/src/mesa/main/uniforms.c +++ b/src/mesa/main/uniforms.c @@ -1522,6 +1522,23 @@ _mesa_G

[Mesa-dev] [Bug 41152] New: [glsl] Shader backend in Regnum Online does not work

https://bugs.freedesktop.org/show_bug.cgi?id=41152 Summary: [glsl] Shader backend in Regnum Online does not work Product: Mesa Version: git Platform: Other URL: http://www.regnumonlinegame.com/ OS/Version: All Status: NE

Re: [Mesa-dev] Why failover module are not used?

On Fri, Sep 23, 2011 at 3:18 AM, wrote: > Hi all, > >    In our mesa code, there is a pipe driver named failover which is not used > at all.  I think the failover pipe driver is a good solution of the hardware > without full capability to support GL2.0. But why it’s discarded? It’s > because fall

Re: [Mesa-dev] [PATCH] mesa: Also set the remaining draw buffers to GL_NONE when updating just the first buffer in _mesa_drawbuffers().

On Fri, 23 Sep 2011 03:04:21 +0200, Henri Verbeet wrote: Non-text part: multipart/mixed > On 23 September 2011 01:48, Eric Anholt wrote: > > In the case of n == 1 with more than one bit set, doesn't this stomp the > > _ColorDrawBufferIndexes[] we just calculated between n and > > _NumColorDrawBuf

Re: [Mesa-dev] [PATCH] intel: fix potential segfault error at intel_(un)map_texture_image

On Thu, 15 Sep 2011 16:02:49 +0800, Yuanhan Liu wrote: > intel_image->mt might be NULL, say with border width set. It then would > trigger a segfault at intel_map/unmap_texture_image function. > > This would fix the oglc misctest(basic.textureBorderIgnore) fail. > > Signed-off-by: Yuanhan Liu

Re: [Mesa-dev] [PATCH] i965: use nonblocking maps MapRangeBuffer

On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky wrote: > This makes the code a lot cleaner, and theoretically faster (not many > real world tests use this GL extension). > > Cc: Eric Anholt > Cc: Daniel Vetter > Cc: Mesa Devs > Signed-off-by: Ben Widawsky > --- > src/mesa/drivers/dri/intel/

Re: [Mesa-dev] [PATCH] intel: Remove pointless boolean return value from *_miptree_layout.

On 09/08/2011 09:14 PM, Kenneth Graunke wrote: i915_miptree_layout, i945_miptree_layout, and brw_miptree_layout always just return GL_TRUE, so there's really no point to it. Change them to void functions and remove the (dead) error checking code. Signed-off-by: Kenneth Graunke Reviewed-by: Ia

Re: [Mesa-dev] [Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer

On Fri, 23 Sep 2011 10:15:02 -0700 Eric Anholt wrote: > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky > wrote: > > This makes the code a lot cleaner, and theoretically faster (not > > many real world tests use this GL extension). > > > > Cc: Eric Anholt > > Cc: Daniel Vetter > > Cc: Mesa D

Re: [Mesa-dev] [Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer

On Fri, 23 Sep 2011 11:46:41 -0700 Ben Widawsky wrote: > On Fri, 23 Sep 2011 10:15:02 -0700 > Eric Anholt wrote: > > > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky > > wrote: > > > This makes the code a lot cleaner, and theoretically faster (not > > > many real world tests use this GL exte

Re: [Mesa-dev] [Intel-gfx] [PATCH] i965: use nonblocking maps MapRangeBuffer

On Fri, 23 Sep 2011 11:56:59 -0700 Ben Widawsky wrote: > On Fri, 23 Sep 2011 11:46:41 -0700 > Ben Widawsky wrote: > > > On Fri, 23 Sep 2011 10:15:02 -0700 > > Eric Anholt wrote: > > > > > On Thu, 22 Sep 2011 16:27:12 -0700, Ben Widawsky > > > wrote: > > > > This makes the code a lot cleaner,

Re: [Mesa-dev] [PATCH] glsl: Stop tree grafting if a variable is overwritten as an 'out' param.

On 22 September 2011 15:21, Kenneth Graunke wrote: > Found by inspection. > > Signed-off-by: Kenneth Graunke > --- > src/glsl/opt_tree_grafting.cpp | 37 > ++--- > 1 files changed, 26 insertions(+), 11 deletions(-) > > diff --git a/src/glsl/opt_tree_grafting.cp

[Mesa-dev] [PATCH] egl: fix null platform autodetection

--- src/egl/main/egldisplay.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c index 39ba883..4960800 100644 --- a/src/egl/main/egldisplay.c +++ b/src/egl/main/egldisplay.c @@ -146,7 +146,11 @@ _eglNativePlatformDetec

Re: [Mesa-dev] UBO support

On 09/23/2011 07:53 AM, vlj wrote: This set of patches add partial support for Uniform Buffer Object (UBO) in mesa. This is still Work In Progress so the last 3 patches are not complete yet, and support from the driver is not done yet. The first 6 patches however can be reviewed. I did not imp

Re: [Mesa-dev] [PATCH 8/9] mesa: add Uniform Buffer Object API implementation

On 09/23/2011 07:53 AM, vlj wrote: --- src/mesa/main/bufferobj.c |2 + src/mesa/main/uniforms.c | 99 + 2 files changed, 101 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c index c453f9c..794c

Re: [Mesa-dev] [PATCH 9/9] mesa : Api binding for UBO

On 09/23/2011 07:53 AM, vlj wrote: --- src/mesa/main/uniforms.c | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/src/mesa/main/uniforms.c b/src/mesa/main/uniforms.c index b923aef..172c817 100644 --- a/src/mesa/main/uniforms.c +++ b/src/mesa/main/un

Re: [Mesa-dev] [PATCH 4/9] mesa: initial data structures for Uniform Buffer Objects

On 09/23/2011 07:53 AM, vlj wrote: --- src/mesa/main/mtypes.h| 47 - src/mesa/main/shaderobj.c |7 ++ 2 files changed, 53 insertions(+), 1 deletions(-) diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index f2eb889..49ae2f

Re: [Mesa-dev] [PATCH 7/9] glsl: linker supports UBO

On 09/23/2011 07:53 AM, vlj wrote: --- src/glsl/linker.cpp | 154 ++- 1 files changed, 152 insertions(+), 2 deletions(-) diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index ba81c59..8dcc0d4 100644 --- a/src/glsl/linker.cpp +++ b/src/gl

Re: [Mesa-dev] MapTextureImage for glGetTexImage

On 09/22/2011 07:24 PM, Brian Paul wrote: On Thu, Sep 22, 2011 at 6:14 PM, Eric Anholt wrote: Here's an extract of what I had in one of my branches for mti, with a slight cleanup to reduce diffs in texgetimage.c. Tested on i965 and softpipe. This code can also be found in the mti-getteximage

Re: [Mesa-dev] Why failover module are not used?

Lack of interest. Nobody wants fallbacks. Especially fallbacks with 0.1 fps, which kinda looks like a hardlock for a while. Besides that, mapping VRAM to user address space is impractical for several reasons. Marek On Fri, Sep 23, 2011 at 9:18 AM, wrote: > Hi all, > >    In our mesa code, there

[Mesa-dev] Half Life 2, Wine, r600g

First- This may really be the wrong place for this, if so kindly point me in the right direction and I will buzz off! I'm trying to run Half Life 2 through Wine on Xubuntu 11.04 using xorg-edgers and the r600g driver. Here's what I get: http://pwnux.blogspot.com/2011/09/current-state-of-r600g.htm

Re: [Mesa-dev] [PATCH 2/2] glsl: Implement a lowering pass for gl_ClipDistance.

On 21 September 2011 18:21, Kenneth Graunke wrote: > > Overall, this looks great, Paul. Other than my few small comments: > > Reviewed-by: Kenneth Graunke > Thanks, Ken. I just pushed this to master. Let me know when your ir_call patches land--I don't think they will conflict, but after they

[Mesa-dev] [PATCH v2 1/2] i965: Cleanup MapRangeBuffer

Clean the code up, and always use a BO when creating a new buffer. I've not seen any regressions but haven't yet tried this on < Gen6. Cc: Chad Versace Cc: Eric Anholt Cc: Mesa Devs Signed-off-by: Ben Widawsky --- src/mesa/drivers/dri/intel/intel_buffer_objects.c | 86 +

[Mesa-dev] [PATCH v2 2/2] i965: Add calls to nonblocking maps

When mapping a range of a buffer that has the UNSYNCHRONIZED_BIT, and is only writable, we can take some shortcuts and let people shoot their feet. Cc: Eric Anholt Cc: Mesa Devs Signed-off-by: Ben Widawsky --- src/mesa/drivers/dri/intel/intel_buffer_objects.c | 35 ++-- src/m

[Mesa-dev] [PATCH 00/19] i965: Do HiZ and depth resolves

By default, HiZ is still disabled. This series causes no Piglit regressions when HiZ is disabled. When HiZ *is* enabled, it is now stable enough to run gnome-shell, nexuiz, and openarena without any artifacts. Mipmapped depth textures, however, are still broken, as well as many Piglit tests. Chad

[Mesa-dev] [PATCH 01/19] intel: Add HiZ operations to intel_context.vtbl

Add the following functions: resolve_depthbuffer resolve_hizbuffer Signed-off-by: Chad Versace --- src/mesa/drivers/dri/intel/intel_context.h | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.h b/src/mesa/drivers

[Mesa-dev] [PATCH 02/19] i965: Initialize intel_context.vtbl after calling intelInitContext

The intel_context.gen field is set by intelInitContext. So, by calling intelInitContext before initializing the vtable, we can can construct different vtables for different gens. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_context.c |3 ++- 1 files changed, 2 insertions(+),

[Mesa-dev] [PATCH 03/19] i965: Add stub functions for HiZ operations

Add stub functions for the following: brw_hiz_resolve_depthbuffer brw_hiz_resolve_hizbuffer These will later be used to implement: intel.vtbl.resolve_depthbuffer intel.vtbl.resolve_hizbuffer Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/Makefile.sources |1 + src

[Mesa-dev] [PATCH 04/19] i965: Set HiZ operations in brw vtbl

If Gen >= 6, then set the following: vtbl.resolve_depthbuffer vtbl.resolve_hizbuffer. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_vtbl.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c b/src/mesa/dri

[Mesa-dev] [PATCH 05/19] intel: Add HiZ control state to intel_region

The HiZ control state is used only by depth regions for which HiZ is enabled. The control state points to the depth region's associated HiZ region and indicates if any resolve is needed. A later commit will remove intel_renderbuffer::hiz_region. since that pointer is will be duplicated by intel_re

[Mesa-dev] [PATCH 06/19] intel: Add 'mode' param to intel_region_map

The 'mode' param is a bitmask of GL_MAP_READ_BIT and GL_MAP_WRITE_BIT. A future commit will perform HiZ resolve operations in intel_region_map(). So, even though the access mode is irrelevant to the GTT, the extra information allows us to intelligently avoid unneccessary HiZ ops. Signed-off-by: C

[Mesa-dev] [PATCH 07/19] intel: Execute HiZ resolve ops in intel_region_map

Signed-off-by: Chad Versace --- src/mesa/drivers/dri/intel/intel_regions.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_regions.c b/src/mesa/drivers/dri/intel/intel_regions.c index 0a5c2c1..304de8b 100644 --- a/src/mesa

[Mesa-dev] [PATCH 08/19] intel: Use intel_region_map/unmap in intel_renderbuffer_map/unmap

Before this commit, intel_renderbuffer_map/unmap() directly called drm_intel_gem_bo_map_gtt(). Since a HiZ or depth resolve may be required before mapping, though, we need instead need to call intel_region_map/unmap(). Signed-off-by: Chad Versace --- src/mesa/drivers/dri/intel/intel_span.c |

[Mesa-dev] [PATCH 09/19] intel: Move definition of intel_framebuffer_get_hiz_region from .h to .c

This eliminates the need for intel_fbo.h to include intel_regions.h on the next commit. And this function was too large to be inline, anyway. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/intel/intel_fbo.c | 12 src/mesa/drivers/dri/intel/intel_fbo.h | 14 ++

[Mesa-dev] [PATCH 10/19] intel: Add function intel_renderbuffer_hiz_alloc

This function allocates the HiZ region and initializes the HiZ control state for a depthbuffer. It is wise to define the logic for HiZ region allocation in a single location, since when MSAA arrives that logic will become more complicated. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/in

[Mesa-dev] [PATCH 11/19] intel: Remove intel_renderbuffer::hiz_region

And replace it with intel_renderbuffer::region::hiz::region. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_misc_state.c | 27 +++-- src/mesa/drivers/dri/intel/intel_context.c | 14 -- src/mesa/drivers/dri/intel/intel_fbo.c | 36 ++

[Mesa-dev] [PATCH 12/19] i965: Add HiZ operation state to brw_context

struct brw_context::hiz contains state needed to perform HiZ meta-ops and indicates if a HiZ operation is currently in progress. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_context.h | 35 +++ src/mesa/drivers/dri/i965/brw_hiz.c | 20

[Mesa-dev] [PATCH 13/19] i965: Complete stubs for HiZ operation meta-ops

Complete the following functions: brw_hiz_resolve_depthbuffer brw_hiz_resolve_hizbuffer In addition to these meta-ops, we must manipulate several state batches (see comments to brw_hiz_meta_save). That work is done in the subsequent commit "i965: Manipulate state batches for Hiz meta-ops".

[Mesa-dev] [PATCH 14/19] i965/gen6: Don't set intel_context.reduced_primitive on Gen >= 6

Before this commit, brw_set_prim() used intel_context.reduced_primitive and BRW_NEW_REDUCED_PRIMITIVE regardless of generation. This was confusing, because those bits are not actually used on Gen >= 6. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_draw.c |3 ++- src/mes

[Mesa-dev] [PATCH 15/19] i965: Change type of brw_context.primitive from GLenum to hardware primitive

For example, GL_TRIANLES is converted to _3DPRIM_TRILIST. The conversion is necessary because HiZ and MSAA resolve operations emit a 3DPRIM_RECTLIST, which cannot be conveyed by GLenum. As a consequence, brw_gs_prog_key.primitive is also converted. Signed-off-by: Chad Versace --- src/mesa/driv

[Mesa-dev] [PATCH 16/19] i965: Manipulate state batches for HiZ operation meta-ops

Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_draw.c |3 ++ src/mesa/drivers/dri/i965/gen6_clip_state.c | 17 +++ src/mesa/drivers/dri/i965/gen6_depthstencil.c | 22 +- src/mesa/drivers/dri/i965/gen6_sf_state.c | 16

[Mesa-dev] [PATCH 17/19] i965: After emitting a HiZ buffer, mark that it needs a HiZ resolve

Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_misc_state.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c b/src/mesa/drivers/dri/i965/brw_misc_state.c index 5adf2d7..1121f61 100644 --- a/src/mesa/drivers/dr

[Mesa-dev] [PATCH 18/19] i965: Do needed HiZ meta-ops before drawing

In brw_try_draw_prims(), perform a HiZ resolve on the attached depthbuffer and perform a depth resolve on each enabled depth texture, if needed. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_draw.c | 43 ++ 1 files changed, 43 insertions(+), 0 de

[Mesa-dev] [PATCH 19/19] i965/gen7: Manipulate gen7 state batches for HiZ meta-ops

From: Kenneth Graunke Signed-off-by: Chad Versace Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/gen7_clip_state.c | 17 ++ src/mesa/drivers/dri/i965/gen7_misc_state.c | 33 +- src/mesa/drivers/dri/i965/gen7_sf_state.c | 13 +-

[Mesa-dev] [PATCH 11/19 v2] intel: Remove intel_renderbuffer::hiz_region

And replace it with intel_renderbuffer::region::hiz::region. v2: In intel_process_dri2_buffer*(), don't call intel_get_renderbuffer() to get the depthbuffer. The variable 'rb' already points to it. Signed-off-by: Chad Versace --- src/mesa/drivers/dri/i965/brw_misc_state.c | 27 +++

[Mesa-dev] [PATCH] intel: Remove intel_renderbuffer::hiz_region

And replace it with intel_renderbuffer::region::hiz::region. v2: In intel_process_dri2_buffer*(), don't call intel_get_renderbuffer() to get the depthbuffer. The variable 'rb' already points to it. v3: Actually do what I intended in the v2 change (oops). Replace depth_irb with rb. Signed

[Mesa-dev] [Bug 41162] New: util/u_draw.c:71:util_draw_max_index: Assertion `buffer_size - buffer->buffer_offset <= buffer_size' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=41162 Summary: util/u_draw.c:71:util_draw_max_index: Assertion `buffer_size - buffer->buffer_offset <= buffer_size' failed. Product: Mesa Version: git Platform: x86-64 (A

[Mesa-dev] [PATCH] i965: Fix incorrect maximum PS thread count shift on Ivybridge.

I mistakenly set GEN7_PS_MAX_THREAD_SHIFT to 23; it's actually 24 on Ivybridge. Not only did this halve our thread count, it caused us to write 1 into a bit 23, which is marked as MBZ (must be zero). Furthermore, it made us write an even number into this field, which is apparently not allowed. Ap