[Mesa-dev] [Bug 52512] Build failures: glsl_lexer.cc & glsl_parser.cc don't exist
https://bugs.freedesktop.org/show_bug.cgi?id=52512 --- Comment #1 from Kenneth Graunke 2012-07-25 23:06:30 UTC --- Presumably this is with the latest git master? Have you done make clean/git clean? Also, what version of automake do you have? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 52513] New: Building static libs doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=52513 Bug #: 52513 Summary: Building static libs doesn't work Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: bugs...@moreofthesa.me.uk Created attachment 64688 --> https://bugs.freedesktop.org/attachment.cgi?id=64688 Patch (git am) I've been seeing build failures when compiling static libs due to an assumption that shared libraries are being built despite configuration options. The attached patch fixes this. (I'm using tweaked Debian packaging for local builds.) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 52512] New: Build failures: glsl_lexer.cc & glsl_parser.cc don't exist
https://bugs.freedesktop.org/show_bug.cgi?id=52512 Bug #: 52512 Summary: Build failures: glsl_lexer.cc & glsl_parser.cc don't exist Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: bugs...@moreofthesa.me.uk make[5]: *** No rule to make target `../../../../../src/mesa/libdricore/../../glsl/glsl_lexer.cc', needed by `glsl_lexer.lo'. Stop. And similarly for glsl_parser.cc. Fixed locally by symlinking glsl_lexer.cc to glsl_lexer.cpp and glsl_parser.cc to glsl_parser.cpp. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 4/4] i965: Use sendc for all render target writes on Gen6+.
Paul Berry writes: > The sendc instruction causes the fragment shader thread to wait for > any dependent threads (i.e. threads rendering to overlapping pixels) > to complete before sending the message. We need to use sendc on the > first render target write in order to guarantee that fragment shader > outputs are written to the render target in the correct order. Reviewed-by: Eric Anholt pgpc7ol6waYaH.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] xlib: add X error handler around XGetImage() call
XGetImage() will generate a BadMatch error if the source window isn't visible. When that happens, create a new XImage. Fixes piglit 'select' test failures with swrast/xlib driver. NOTE: This is a candidate for the 8.0 branch. --- src/mesa/drivers/x11/xm_buffer.c | 29 + 1 files changed, 29 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/x11/xm_buffer.c b/src/mesa/drivers/x11/xm_buffer.c index a7395a3..eb68f94 100644 --- a/src/mesa/drivers/x11/xm_buffer.c +++ b/src/mesa/drivers/x11/xm_buffer.c @@ -446,14 +446,43 @@ xmesa_MapRenderbuffer(struct gl_context *ctx, } else { /* this must be a pixmap/window renderbuffer */ + int (*old_handler)(XMesaDisplay *, XErrorEvent *); int y2 = rb->Height - y - h; assert(xrb->pixmap); + /* Install error handler for XGetImage() in case the the window + * isn't mapped. If we fail we'll create a temporary XImage. + */ + mesaXErrorFlag = 0; + old_handler = XSetErrorHandler(mesaHandleXError); + /* read pixel data out of the pixmap/window into an XImage */ ximage = XGetImage(xrb->Parent->display, xrb->pixmap, x, y2, w, h, AllPlanes, ZPixmap); + + XSetErrorHandler(old_handler); + + if (mesaXErrorFlag) { +/* create new, temporary XImage */ +int bytes_per_line = + _mesa_format_row_stride(xrb->Base.Base.Format, + xrb->Base.Base.Width); +char *image = (char *) malloc(bytes_per_line * + xrb->Base.Base.Height); +ximage = XCreateImage(xrb->Parent->display, + xrb->Parent->xm_visual->visinfo->visual, + xrb->Parent->xm_visual->visinfo->depth, + ZPixmap, /* format */ + 0, /* offset */ + image, /* data */ + xrb->Base.Base.Width, + xrb->Base.Base.Height, + 8, /* pad */ + bytes_per_line); + } + if (!ximage) { *mapOut = NULL; *rowStrideOut = 0; -- 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 00/15] i965: Enable window system multisampling
On 21 July 2012 17:36, Chad Versace wrote: > No Piglit regressions on Ivybridge. > > Tested with `glxgears -samples 1`. > > Passes 53/70 of oglconform's winsys multisample tests. The failing tests > mostly consist of those that call glDrawPixels on the depth and stencil > buffer (which fail due to a swrast fallback) or do fancy things with the > msaa alpha enums (which also fail with non-winsys msaa). > > We probably need to write some Piglit tests for some winsys msaa corner > cases, > but I think the series is good enough to push now based on the evidence of > oglconform's pass rate. > > Chad Versace (15): > intel: Remove dead code in intelAllocateBuffer > intel: Decrease nesting level in intelCreateBuffer > intel: Use consistent pattern in intelCreateBuffer > intel: Refactor quantize_num_samples > intel: Set num samples for winsys renderbuffers > intel: Add intel_mipmap_tree::singlesample_mt > intel: Refactor creation of hiz and mcs miptrees > intel: Allocate miptree for multisample DRI2 buffers > i965: Add function intel_miptree_downsample > i965: Mark winsys MSAA color buffer as needing resolve postdraw > intel: Downsample during glReadPixels > intel: Downsample on DRI2 flush > intel: Refactor creation of DRI2 configs > intel: Refactor intel_screen_make_configs > intel: Advertise multisample DRI2 configs on gen >= 6 > To update the list on what Chad and I discussed in person today: Patches 1-7, 9, and 12-13 are Reviewed-by: Paul Berry I have some concerns about patches 8, 10, and 11 which I've already emailed you about. I don't feel qualified to review patches 14-15, but fortunately Ian and Eric already seem to be weighing in on those patches. You and I discovered this morning that patch 15 introduces a bug with gnome--it makes gnome-terminal windows fail to show up when using the gnome compositing window manager. The bug seems to be related to where the multisampled visuals appear in the list of visuals, and we suspect that some part of gnome is erroneously relying on the visuals being in a certain order. I will try to investigate this bug as soon as I get a chance (partly because I think you are busier than me these days, and partly because I think it will be educational for me). I'll keep you posted on my progress. If things get too busy for you and you want me to take over the patch series, let me know. For now I'll assume you still own the patch series, and I'm just providing troubleshooting assistance :) > > src/mesa/drivers/dri/i965/Makefile.sources | 1 + > src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp | 66 +++ > src/mesa/drivers/dri/i965/brw_draw.c| 17 +- > src/mesa/drivers/dri/intel/intel_context.c | 26 +- > src/mesa/drivers/dri/intel/intel_fbo.c | 58 +-- > src/mesa/drivers/dri/intel/intel_fbo.h | 8 +- > src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 82 > src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 39 ++ > src/mesa/drivers/dri/intel/intel_screen.c | 540 > +--- > src/mesa/drivers/dri/intel/intel_screen.h | 3 + > 10 files changed, 536 insertions(+), 304 deletions(-) > create mode 100644 src/mesa/drivers/dri/i965/brw_blorp_orphans.cpp > > -- > 1.7.11.2 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47375] Blender crash on startup after upgrade to mesa 8.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=47375 --- Comment #15 from Brian Paul 2012-07-25 22:22:58 PDT --- (In reply to comment #14) > Brian, can you tell me what are the differences in swrast component between > the > 7.11.2-1 mesa release version and the 8.0.x release ? There's a ton of changes in swrast since 7.11, unfortunately. > we know that swrast runs without problems in 7.11.2-1 mesa version with > blender > and an old ati radeon card ( rv250, rv280 cards ), > > but something in the 8.0.x mesa release has changed in the "swrast component", > if we can locate these new lines in the source code then we will find probably > the culprit, > > maybe a new onpenGL instruction who is not supported by old card like rv250, > rv280, don't forget that radeon 9000 card ( rv250 ) only supports opengl 1.3 > version, > > I need some tips in order to debug this problem ( I'm a newbie in debugging > opengl/multimedia software ) Let's first find out why the 'fallback' variable in _mesa_meta_DrawPixels() is getting set. Basically, use gdb to set a breakpoint in _mesa_meta_DrawPixels() then go step by step to see where 'fallback = GL_TRUE' is getting hit. To set a breakpoint: "break _mesa_meta_DrawPixels()" To step one instruction: "s" or "step" When you find the point where fallback = GL_TRUE is set, note the current line and try to print some of the variables in the conditionals. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 1/5] radeonsi: rename r600_resource to si_resource
On Wed, Jul 25, 2012 at 1:58 PM, Christian König wrote: > Also split it into seperate header and add > some helper functions. > > Signed-off-by: Christian König For the series: Reviewed-by: Alex Deucher ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can --enable-shared-glapi die?
On Tue, 2012-07-24 at 10:45 -0700, Ian Romanick wrote: > On 07/23/2012 12:59 PM, Ian Romanick wrote: > > Perhaps someone can refresh my memory as to what exactly this option > > does? Can we make this the default and remove the option from configure? > > Thanks to all for the refresher. Off-list someone raised another issue > to me that seems like a deal breaker. If an application links with a > libGL that uses libglapi it appears that the application gets implicitly > linked with libglapi (as shown by objdump -x | grep -i need). This will > cause the application to fail if a non-glapi libGL (i.e., any of the > closed-source drivers) is later installed. The problem seems to be that > symbols like glBegin are in libglapi. > > Is this fixable? I think the usual cause for this is linking with libtool. By default, libtool will read the libGL.la file associated with your libGL.so, and add all of the dependency libraries listed in the .la file to the link command line, even if the operating system does not require them to be linked in. (There are some options that some versions of ld have that will cause ld to ignore these libraries and not *actually* link them in; some newer distributions are starting to use these options) The easy workaround is simply to delete the libGL.la file after installation, to force libtool to link *only* to libGL.so. -- Calvin Walton ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2, android-build] android-build: fix dricore build for autogenerated files
On 07/23/2012 12:13 PM, Daniel Charles wrote: > Recently more files were removed from control to be auto-generated > in the dricore library. Android build was not able to locate the > new files if they were not created beforehand. > > LOCAL_SRC_FILES includes some of those files and Android.gen.mk > re-defines this variable by filtering out the auto-generated files. > Unfortunately for this variable it is not the same to have the SRCDIR > variable defined as the current directory. > > By re-defining SRCDIR for the autotools build the Android build system > is happy again and the new files were actually removed from the sources > to use the auto generated versions. > > Also patch d5c1801a018efda8ac2b was partially reverted as the files > can not be compiled to the LOCAL_PATH, instead they should live on the > intermediates folder so that a clean can wipe them out. > > Change-Id: I75e86453d23f6b6f0e2a7dfb1b48272965c9fbf2 > Signed-off-by: Daniel Charles > --- > src/mesa/Android.gen.mk | 68 +-- > src/mesa/Android.mk |1 - > src/mesa/Makefile.am|4 +- > src/mesa/sources.mak| 561 > --- > 4 files changed, 337 insertions(+), 297 deletions(-) Looks good to me. Reviewed-by: Chad Versace I'll commit this tomorrow if no one objects. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47375] Blender crash on startup after upgrade to mesa 8.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=47375 --- Comment #14 from Barto 2012-07-25 18:56:11 PDT --- (In reply to comment #13) > I also tried forcing fallback=1 so that _swrast_DrawPixels() gets called but I > didn't see any failed assertions. I'm using the Mesa 8.0.x branch. > > I don't have a r200 gpu to try that driver. Brian, can you tell me what are the differences in swrast component between the 7.11.2-1 mesa release version and the 8.0.x release ? we know that swrast runs without problems in 7.11.2-1 mesa version with blender and an old ati radeon card ( rv250, rv280 cards ), but something in the 8.0.x mesa release has changed in the "swrast component", if we can locate these new lines in the source code then we will find probably the culprit, maybe a new onpenGL instruction who is not supported by old card like rv250, rv280, don't forget that radeon 9000 card ( rv250 ) only supports opengl 1.3 version, I need some tips in order to debug this problem ( I'm a newbie in debugging opengl/multimedia software ) thanks -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 14/15] intel: Refactor intel_screen_make_configs
Chad Versace writes: > Transform the code from clever, obfuscated, and imperative to > straight-forward and table-driven. I don't like this change. It increases the amount of code, and to change any single option, you need to change more code. If we were to change back_buffer_modes (and I think we need to, since we potentially pageflip instead of blitting, so we don't adhere to GLX_SWAP_COPY_OML), we would need to hit each struct's count instead of just the shared list. And MSAA was incoherent with single sample in those bits for reasons I don't understand. If we were to expose 16 and 24 depth on both 16 and 32 color, we would need to duplicate it across all the color setup, instead of just removing the if/else in the previous code and bumping the count. If we were to choose whether to expose non-stencil depth configs based on whether the hardware requires separate stencil or not... I don't know what we would do. If I was to go cleaning up config creation code, I would change driCreateConfigs to have sentinels terminating the arrays instead of separate counts. pgpQT5pGnP5Nt.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] radeonsi: fix dst clobber of buffer loads
Signed-off-by: Christian König --- src/gallium/drivers/radeon/SIInstrInfo.td |2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/drivers/radeon/SIInstrInfo.td b/src/gallium/drivers/radeon/SIInstrInfo.td index aac6443..3fcf4e2 100644 --- a/src/gallium/drivers/radeon/SIInstrInfo.td +++ b/src/gallium/drivers/radeon/SIInstrInfo.td @@ -424,6 +424,7 @@ class MUBUF_Load_Helper op, string asm, RegisterClass regClass> : MUBUF asm, []> { let mayLoad = 1; + let Constraints = "@earlyclobber $dst"; } class MTBUF_Load_Helper op, string asm, RegisterClass regClass> : MTBUF < @@ -435,6 +436,7 @@ class MTBUF_Load_Helper op, string asm, RegisterClass regClass> : MTBUF asm, []> { let mayLoad = 1; + let Constraints = "@earlyclobber $dst"; } class MTBUF_Store_Helper op, string asm, RegisterClass regClass> : MTBUF < -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] radeonsi: fix register count calculation
Signed-off-by: Christian König --- src/gallium/drivers/radeonsi/si_state_draw.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c b/src/gallium/drivers/radeonsi/si_state_draw.c index 0d9f009..74ed01f 100644 --- a/src/gallium/drivers/radeonsi/si_state_draw.c +++ b/src/gallium/drivers/radeonsi/si_state_draw.c @@ -86,8 +86,8 @@ static void si_pipe_shader_vs(struct pipe_context *ctx, struct si_pipe_shader *s assert(num_sgprs <= 104); si_pm4_set_reg(pm4, R_00B128_SPI_SHADER_PGM_RSRC1_VS, - S_00B128_VGPRS((shader->num_vgprs - 1) / 4) | - S_00B128_SGPRS((num_sgprs - 1) / 8)); + S_00B128_VGPRS((align(shader->num_vgprs,4) / 4) - 1) | + S_00B128_SGPRS((align(num_sgprs, 8) / 8) - 1)); si_pm4_set_reg(pm4, R_00B12C_SPI_SHADER_PGM_RSRC2_VS, S_00B12C_USER_SGPR(num_user_sgprs)); @@ -192,8 +192,8 @@ static void si_pipe_shader_ps(struct pipe_context *ctx, struct si_pipe_shader *s assert(num_sgprs <= 104); si_pm4_set_reg(pm4, R_00B028_SPI_SHADER_PGM_RSRC1_PS, - S_00B028_VGPRS((shader->num_vgprs - 1) / 4) | - S_00B028_SGPRS((num_sgprs - 1) / 8)); + S_00B028_VGPRS((align(shader->num_vgprs, 4) / 4) - 1) | + S_00B028_SGPRS((align(num_sgprs, 8) / 8) - 1)); si_pm4_set_reg(pm4, R_00B02C_SPI_SHADER_PGM_RSRC2_PS, S_00B02C_USER_SGPR(num_user_sgprs)); -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] radeonsi: fix vertex buffer and elements
Let's just use the T# descriptors until we get a fetch shader. Signed-off-by: Christian König --- src/gallium/drivers/radeonsi/radeonsi_shader.c |6 +- src/gallium/drivers/radeonsi/si_state.c| 43 +++-- src/gallium/drivers/radeonsi/si_state.h|9 +-- src/gallium/drivers/radeonsi/si_state_draw.c | 80 +--- 4 files changed, 74 insertions(+), 64 deletions(-) diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c b/src/gallium/drivers/radeonsi/radeonsi_shader.c index 32290a2..4c9e4fa 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c @@ -182,7 +182,7 @@ static void declare_input_vs( struct lp_build_context * uint = &si_shader_ctx->radeon_bld.soa.bld_base.uint_bld; struct lp_build_context * base = &si_shader_ctx->radeon_bld.soa.bld_base.base; struct r600_context *rctx = si_shader_ctx->rctx; - struct pipe_vertex_element *velem = &rctx->vertex_elements->elements[input_index]; + //struct pipe_vertex_element *velem = &rctx->vertex_elements->elements[input_index]; unsigned chan; /* Load the T list */ @@ -191,12 +191,12 @@ static void declare_input_vs( * now */ t_list_ptr = use_sgpr(base->gallivm, SGPR_CONST_PTR_V4I32, 6); - t_offset = lp_build_const_int32(base->gallivm, velem->vertex_buffer_index); + t_offset = lp_build_const_int32(base->gallivm, input_index); t_list = build_indexed_load(base->gallivm, t_list_ptr, t_offset); /* Build the attribute offset */ - attribute_offset = lp_build_const_int32(base->gallivm, velem->src_offset); + attribute_offset = lp_build_const_int32(base->gallivm, 0); /* Load the buffer index is always, which is always stored in VGPR0 * for Vertex Shaders */ diff --git a/src/gallium/drivers/radeonsi/si_state.c b/src/gallium/drivers/radeonsi/si_state.c index 297d791..c417c9c 100644 --- a/src/gallium/drivers/radeonsi/si_state.c +++ b/src/gallium/drivers/radeonsi/si_state.c @@ -1226,10 +1226,10 @@ static bool si_is_sampler_format_supported(struct pipe_screen *screen, enum pipe util_format_get_first_non_void_channel(format)) != ~0U; } -uint32_t si_translate_vertexformat(struct pipe_screen *screen, - enum pipe_format format, - const struct util_format_description *desc, - int first_non_void) +static uint32_t si_translate_vertexformat(struct pipe_screen *screen, + enum pipe_format format, + const struct util_format_description *desc, + int first_non_void) { uint32_t result; @@ -2078,12 +2078,45 @@ static void *si_create_vertex_elements(struct pipe_context *ctx, const struct pipe_vertex_element *elements) { struct si_vertex_element *v = CALLOC_STRUCT(si_vertex_element); + int i; - assert(count < 32); + assert(count < PIPE_MAX_ATTRIBS); if (!v) return NULL; v->count = count; + for (i = 0; i < count; ++i) { + const struct util_format_description *desc; + unsigned data_format, num_format; + int first_non_void; + + desc = util_format_description(elements[i].src_format); + first_non_void = util_format_get_first_non_void_channel(elements[i].src_format); + data_format = si_translate_vertexformat(ctx->screen, elements[i].src_format, + desc, first_non_void); + + switch (desc->channel[first_non_void].type) { + case UTIL_FORMAT_TYPE_FIXED: + num_format = V_008F0C_BUF_NUM_FORMAT_USCALED; /* XXX */ + break; + case UTIL_FORMAT_TYPE_SIGNED: + num_format = V_008F0C_BUF_NUM_FORMAT_SNORM; + break; + case UTIL_FORMAT_TYPE_UNSIGNED: + num_format = V_008F0C_BUF_NUM_FORMAT_UNORM; + break; + case UTIL_FORMAT_TYPE_FLOAT: + default: + num_format = V_008F14_IMG_NUM_FORMAT_FLOAT; + } + + v->rsrc_word3[i] = S_008F0C_DST_SEL_X(si_map_swizzle(desc->swizzle[0])) | + S_008F0C_DST_SEL_Y(si_map_swizzle(desc->swizzle[1])) | + S_008F0C_DST_SEL_Z(si_map_swizzle(desc->swizzle[2])) | + S_008F0C_DST_SEL_W(si_map_swizzle(desc->swizzle[3])) | + S_008F0C_NUM_FORMAT(num_format) | + S_008F0C_DATA_FORMAT(data_format); + }
[Mesa-dev] [PATCH 1/5] radeonsi: rename r600_resource to si_resource
Also split it into seperate header and add some helper functions. Signed-off-by: Christian König --- src/gallium/drivers/radeonsi/r600.h| 21 ++ src/gallium/drivers/radeonsi/r600_buffer.c | 12 ++-- src/gallium/drivers/radeonsi/r600_hw_context.c | 23 +++ .../drivers/radeonsi/r600_hw_context_priv.h|2 +- src/gallium/drivers/radeonsi/r600_resource.h |9 +-- src/gallium/drivers/radeonsi/r600_texture.c| 24 +++ src/gallium/drivers/radeonsi/radeonsi_pipe.c | 15 ++--- src/gallium/drivers/radeonsi/radeonsi_pipe.h |8 +-- src/gallium/drivers/radeonsi/radeonsi_pm4.c|8 +-- src/gallium/drivers/radeonsi/radeonsi_pm4.h|4 +- src/gallium/drivers/radeonsi/radeonsi_resource.h | 67 src/gallium/drivers/radeonsi/radeonsi_shader.c |5 +- src/gallium/drivers/radeonsi/si_state.c| 23 +++ src/gallium/drivers/radeonsi/si_state.h|2 +- src/gallium/drivers/radeonsi/si_state_draw.c | 11 ++-- 15 files changed, 140 insertions(+), 94 deletions(-) create mode 100644 src/gallium/drivers/radeonsi/radeonsi_resource.h diff --git a/src/gallium/drivers/radeonsi/r600.h b/src/gallium/drivers/radeonsi/r600.h index 6ff0bf8..f22d920 100644 --- a/src/gallium/drivers/radeonsi/r600.h +++ b/src/gallium/drivers/radeonsi/r600.h @@ -30,6 +30,8 @@ #include "util/u_double_list.h" #include "util/u_transfer.h" +#include "radeonsi_resource.h" + #define R600_ERR(fmt, args...) \ fprintf(stderr, "EE %s:%d %s - "fmt, __FILE__, __LINE__, __func__, ##args) @@ -55,17 +57,6 @@ struct r600_tiling_info { unsigned group_bytes; }; -struct r600_resource { - struct u_resource b; - - /* Winsys objects. */ - struct pb_buffer*buf; - struct radeon_winsys_cs_handle *cs_buf; - - /* Resource state. */ - unsigneddomains; -}; - /* R600/R700 STATES */ struct r600_query { union { @@ -85,7 +76,7 @@ struct r600_query { /* The buffer where query results are stored. It's used as a ring, * data blocks for current query are stored sequentially from * results_start to results_end, with wrapping on the buffer end */ - struct r600_resource*buffer; + struct si_resource *buffer; /* The number of dwords for begin_query or end_query. */ unsignednum_cs_dw; /* linked list of queries */ @@ -96,7 +87,7 @@ struct r600_so_target { struct pipe_stream_output_target b; /* The buffer where BUFFER_FILLED_SIZE is stored. */ - struct r600_resource*filled_size; + struct si_resource *filled_size; unsignedstride; unsignedso_index; }; @@ -113,7 +104,7 @@ struct r600_draw { uint32_tindices_bo_offset; unsigneddb_render_override; unsigneddb_render_control; - struct r600_resource*indices; + struct si_resource *indices; }; struct r600_context; @@ -133,7 +124,7 @@ void r600_context_queries_suspend(struct r600_context *ctx); void r600_context_queries_resume(struct r600_context *ctx); void r600_query_predication(struct r600_context *ctx, struct r600_query *query, int operation, int flag_wait); -void r600_context_emit_fence(struct r600_context *ctx, struct r600_resource *fence, +void r600_context_emit_fence(struct r600_context *ctx, struct si_resource *fence, unsigned offset, unsigned value); void r600_context_streamout_begin(struct r600_context *ctx); diff --git a/src/gallium/drivers/radeonsi/r600_buffer.c b/src/gallium/drivers/radeonsi/r600_buffer.c index 15bff91..76de941 100644 --- a/src/gallium/drivers/radeonsi/r600_buffer.c +++ b/src/gallium/drivers/radeonsi/r600_buffer.c @@ -40,7 +40,7 @@ static void r600_buffer_destroy(struct pipe_screen *screen, struct pipe_resource *buf) { struct r600_screen *rscreen = (struct r600_screen*)screen; - struct r600_resource *rbuffer = r600_resource(buf); + struct si_resource *rbuffer = si_resource(buf); pb_reference(&rbuffer->buf, NULL); FREE(rbuffer); @@ -72,7 +72,7 @@ static struct pipe_transfer *r600_get_transfer(struct pipe_context *ctx, static void *r600_buffer_transfer_map(struct pipe_context *pipe, struct pipe_transfer *transfer) { - struct r600_resource *rbuffer = r600_resource(transfer->resource); + struct si_resource *rbuffer = si_resource(transfer->resource); struct r600_context *rctx = (struct r600_context*)pipe; uint8_t *data; @@ -115,7 +115,7 @@ static const struct u_resource_vtbl r600_buffer_vtbl = }; bool r600_init_re
[Mesa-dev] [PATCH 2/5] radeonsi: fix shader size and handling
We should always upload the shader here. Signed-off-by: Christian König --- src/gallium/drivers/radeonsi/radeonsi_shader.c | 26 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c b/src/gallium/drivers/radeonsi/radeonsi_shader.c index 0edb379..32290a2 100644 --- a/src/gallium/drivers/radeonsi/radeonsi_shader.c +++ b/src/gallium/drivers/radeonsi/radeonsi_shader.c @@ -552,6 +552,7 @@ int si_pipe_shader_create( unsigned char * inst_bytes; unsigned inst_byte_count; unsigned i; + uint32_t *ptr; bool dump; dump = debug_get_bool_option("RADEON_DUMP_SHADERS", FALSE); @@ -606,23 +607,22 @@ int si_pipe_shader_create( tgsi_parse_free(&si_shader_ctx.parse); /* copy new shader */ + si_resource_reference(&shader->bo, NULL); + shader->bo = si_resource_create_custom(ctx->screen, PIPE_USAGE_IMMUTABLE, + inst_byte_count - 12); if (shader->bo == NULL) { - uint32_t *ptr; + return -ENOMEM; + } - shader->bo = si_resource_create_custom(ctx->screen, PIPE_USAGE_IMMUTABLE, inst_byte_count); - if (shader->bo == NULL) { - return -ENOMEM; - } - ptr = (uint32_t*)rctx->ws->buffer_map(shader->bo->cs_buf, rctx->cs, PIPE_TRANSFER_WRITE); - if (0 /*R600_BIG_ENDIAN*/) { - for (i = 0; i < (inst_byte_count-12)/4; ++i) { - ptr[i] = util_bswap32(*(uint32_t*)(inst_bytes+12 + i*4)); - } - } else { - memcpy(ptr, inst_bytes + 12, inst_byte_count - 12); + ptr = (uint32_t*)rctx->ws->buffer_map(shader->bo->cs_buf, rctx->cs, PIPE_TRANSFER_WRITE); + if (0 /*R600_BIG_ENDIAN*/) { + for (i = 0; i < (inst_byte_count-12)/4; ++i) { + ptr[i] = util_bswap32(*(uint32_t*)(inst_bytes+12 + i*4)); } - rctx->ws->buffer_unmap(shader->bo->cs_buf); + } else { + memcpy(ptr, inst_bytes + 12, inst_byte_count - 12); } + rctx->ws->buffer_unmap(shader->bo->cs_buf); free(inst_bytes); -- 1.7.9.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/15] intel: Set num samples for winsys renderbuffers
Chad Versace writes: > Add a new param, num_samples, to intel_create_renderbuffer and > intel_create_private_renderbuffer. The caller, intelCreateBuffer, passes > in the value of gl_config::NumSamples. > > No multisample GL config is yet advertised, so the value of num_samples is > currently 0. > > For server-owned winsys buffers, gl_renderbuffer::NumSamples is not yet > used. It would make more sense to me if the quantizing was done once and passed to the create_renderbuffer call (you need the same NumSamples across them, anyway). Then you wouldn't need the screen argument, either. pgpHslJpdodl6.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/15] intel: Refactor quantize_num_samples
Chad Versace writes: > Rename quantize_num_samples to intel_quantize_num_samples and change the > first param from struct intel_context* to struct intel_screen*. The > function will later be used by intelCreateBuffer, which is not bound to > any context but is bound to a screen. Since the function now depends on > the screen, move it to intel_screen.[ch]. intel_fbo seems like a good place for it as well -- we've got other screen-dependent function scattered around. I don't really care either way, but I think I would have looked in intel_fbo.c first. pgppzRxQzqjPm.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove _math_matrix_alloc_inv()
On 07/25/2012 06:33 AM, Brian Paul wrote: > Always allocate space for the inverse matrix in _math_matrix_ctr() > since we were always calling _math_matrix_alloc_inv() anyway. > --- > src/mesa/main/matrix.c|4 +-- > src/mesa/math/m_matrix.c | 51 > - > src/mesa/math/m_matrix.h |5 +--- > src/mesa/program/prog_statevars.c |1 - > 4 files changed, 13 insertions(+), 48 deletions(-) Nice cleanup! Much less fiddly code. Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] i965: Use sendc for all render target writes on Gen6+.
On 07/25/2012 07:20 AM, Paul Berry wrote: > The sendc instruction causes the fragment shader thread to wait for > any dependent threads (i.e. threads rendering to overlapping pixels) > to complete before sending the message. We need to use sendc on the > first render target write in order to guarantee that fragment shader > outputs are written to the render target in the correct order. > > Previously, we only used the "sendc" instruction when writing to > binding table index 0. This did the right thing for fragment shaders, > because our fragment shader back-ends always issue their first render > target write to binding table index 0. However, it did the wrong > thing for blorp, which performs its render target writes to binding > table index 1. > > A more robust solution is to use sendc for all render target writes. > This should not produce any performance penalty, since after the first > sendc, all of the dependent threads will have completed. > > For more information about sendc, see the Ivy Bridge PRM, Vol4 Part3 > p218 (sendc - Conditional Send Message), and p54 (TDR Registers). > --- > src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c > b/src/mesa/drivers/dri/i965/brw_eu_emit.c > index 93e84ae..25bf91b 100644 > --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c > +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c > @@ -2259,7 +2259,7 @@ void brw_fb_WRITE(struct brw_compile *p, > else >dest = retype(vec8(brw_null_reg()), BRW_REGISTER_TYPE_UW); > > - if (intel->gen >= 6 && binding_table_index == 0) { > + if (intel->gen >= 6) { >insn = next_insn(p, BRW_OPCODE_SENDC); > } else { >insn = next_insn(p, BRW_OPCODE_SEND); For the series (pithy comments aside): Reviewed-by: Kenneth Graunke Please wait for Eric's ack on patch 4 before pushing that, though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] intel: Make more consistent use of _mesa_is_{user, winsys}_fbo()
On 07/25/2012 07:20 AM, Paul Berry wrote: > A lot of code was still differentiating between between winsys and > user fbos by testing the fbo's name against zero. This converts > everything in the i915 and 965 drivers over to use _mesa_is_user_fbo() > and _mesa_is_winsys_fbo(). > --- > src/mesa/drivers/dri/i915/i830_vtbl.c |3 ++- > src/mesa/drivers/dri/i915/intel_tris.c |3 ++- > src/mesa/drivers/dri/i965/brw_blorp_blit.cpp|5 +++-- > src/mesa/drivers/dri/intel/intel_blit.c |3 ++- > src/mesa/drivers/dri/intel/intel_buffers.c |2 +- > src/mesa/drivers/dri/intel/intel_fbo.c |2 +- > src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |5 +++-- > src/mesa/drivers/dri/intel/intel_pixel_copy.c |5 +++-- > src/mesa/drivers/dri/intel/intel_tex_copy.c |3 ++- > 9 files changed, 19 insertions(+), 12 deletions(-) > > diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c > b/src/mesa/drivers/dri/i915/i830_vtbl.c > index 28e95d9..6019852 100644 > --- a/src/mesa/drivers/dri/i915/i830_vtbl.c > +++ b/src/mesa/drivers/dri/i915/i830_vtbl.c > @@ -39,6 +39,7 @@ > #include "swrast_setup/swrast_setup.h" > #include "main/renderbuffer.h" > #include "main/framebuffer.h" > +#include "main/fbobject.h" > > #define FILE_DEBUG_FLAG DEBUG_STATE > > @@ -769,7 +770,7 @@ i830_update_draw_buffer(struct intel_context *intel) >/* Get the intel_renderbuffer for the single colorbuffer we're drawing > * into. > */ > - if (fb->Name == 0) { > + if (_mesa_is_winsys_fbo(fb)) { >/* drawing to window system buffer */ >if (fb->_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT) > colorRegions[0] = intel_get_rb_region(fb, BUFFER_FRONT_LEFT); > diff --git a/src/mesa/drivers/dri/i915/intel_tris.c > b/src/mesa/drivers/dri/i915/intel_tris.c > index cf67d74..5954b24 100644 > --- a/src/mesa/drivers/dri/i915/intel_tris.c > +++ b/src/mesa/drivers/dri/i915/intel_tris.c > @@ -38,6 +38,7 @@ > #include "main/texobj.h" > #include "main/state.h" > #include "main/dd.h" > +#include "main/fbobject.h" > > #include "swrast/swrast.h" > #include "swrast_setup/swrast_setup.h" > @@ -503,7 +504,7 @@ intel_emit_fragcoord(struct intel_context *intel, > intelVertexPtr v) > > fragcoord[0] = vertex_position[0]; > > - if (fb->Name) > + if (_mesa_is_user_fbo(fb)) >fragcoord[1] = vertex_position[1]; > else >fragcoord[1] = fb->Height - vertex_position[1]; > diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp > b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp > index f8b7e4a..bd15632 100644 > --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp > +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp > @@ -22,6 +22,7 @@ > */ > > #include "main/teximage.h" > +#include "main/fbobject.h" > > #include "glsl/ralloc.h" > > @@ -214,13 +215,13 @@ try_blorp_blit(struct intel_context *intel, > /* Account for the fact that in the system framebuffer, the origin is at > * the lower left. > */ > - if (read_fb->Name == 0) { > + if (_mesa_is_winsys_fbo(read_fb)) { >GLint tmp = read_fb->Height - srcY0; >srcY0 = read_fb->Height - srcY1; >srcY1 = tmp; >mirror_y = !mirror_y; > } > - if (draw_fb->Name == 0) { > + if (_mesa_is_winsys_fbo(draw_fb)) { >GLint tmp = draw_fb->Height - dstY0; >dstY0 = draw_fb->Height - dstY1; >dstY1 = tmp; > diff --git a/src/mesa/drivers/dri/intel/intel_blit.c > b/src/mesa/drivers/dri/intel/intel_blit.c > index fd4a86c..36a2c6a 100644 > --- a/src/mesa/drivers/dri/intel/intel_blit.c > +++ b/src/mesa/drivers/dri/intel/intel_blit.c > @@ -30,6 +30,7 @@ > #include "main/context.h" > #include "main/enums.h" > #include "main/colormac.h" > +#include "main/fbobject.h" > > #include "intel_blit.h" > #include "intel_buffers.h" > @@ -248,7 +249,7 @@ intelClearWithBlit(struct gl_context *ctx, GLbitfield > mask) > } > > cx = fb->_Xmin; > - if (fb->Name == 0) > + if (_mesa_is_winsys_fbo(fb)) >cy = ctx->DrawBuffer->Height - fb->_Ymax; > else >cy = fb->_Ymin; > diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c > b/src/mesa/drivers/dri/intel/intel_buffers.c > index 2b02763..9a9a259 100644 > --- a/src/mesa/drivers/dri/intel/intel_buffers.c > +++ b/src/mesa/drivers/dri/intel/intel_buffers.c > @@ -70,7 +70,7 @@ void > intel_check_front_buffer_rendering(struct intel_context *intel) > { > const struct gl_framebuffer *fb = intel->ctx.DrawBuffer; > - if (fb->Name == 0) { > + if (_mesa_is_winsys_fbo(fb)) { >/* drawing to window system buffer */ >if (fb->_NumColorDrawBuffers > 0) { > if (fb->_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT) { > diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c > b/src/mesa/drivers/dri/intel/intel_fbo.c > index ac7d6c1..a53985b 100644 > --- a/src/mesa/drivers/dri/intel/intel_fbo.c > +++ b/src/mesa/drivers/dri/i
Re: [Mesa-dev] [PATCH 1/4] mesa: Make more consistent use of _mesa_is_{user, winsys}_fbo()
On 07/25/2012 07:19 AM, Paul Berry wrote: > A lot of code was still differentiating between between winsys and > user fbos by testing the fbo's name against zero. This converts > everything in core mesa, the state tracker, and src/mesa/program over > to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo(). > --- > src/mesa/main/context.c |8 > src/mesa/main/drawpix.c |4 +++- > src/mesa/main/framebuffer.c |6 +++--- > src/mesa/main/readpix.c |4 +++- > src/mesa/program/prog_statevars.c |3 ++- > src/mesa/state_tracker/st_cb_viewport.c |3 ++- > src/mesa/state_tracker/st_context.h |3 ++- > src/mesa/state_tracker/st_manager.c |3 ++- > 8 files changed, 21 insertions(+), 13 deletions(-) > > diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c > index 41550f9..243053e 100644 > --- a/src/mesa/main/context.c > +++ b/src/mesa/main/context.c > @@ -1456,8 +1456,8 @@ _mesa_make_current( struct gl_context *newCtx, >_glapi_set_dispatch(newCtx->CurrentDispatch); > >if (drawBuffer && readBuffer) { > - ASSERT(drawBuffer->Name == 0); > - ASSERT(readBuffer->Name == 0); > + ASSERT(_mesa_is_winsys_fbo(drawBuffer)); > + ASSERT(_mesa_is_winsys_fbo(readBuffer)); > _mesa_reference_framebuffer(&newCtx->WinSysDrawBuffer, drawBuffer); > _mesa_reference_framebuffer(&newCtx->WinSysReadBuffer, readBuffer); > > @@ -1465,7 +1465,7 @@ _mesa_make_current( struct gl_context *newCtx, >* Only set the context's Draw/ReadBuffer fields if they're NULL >* or not bound to a user-created FBO. >*/ > - if (!newCtx->DrawBuffer || newCtx->DrawBuffer->Name == 0) { > + if (!newCtx->DrawBuffer || _mesa_is_winsys_fbo(newCtx->DrawBuffer)) > { > _mesa_reference_framebuffer(&newCtx->DrawBuffer, drawBuffer); > /* Update the FBO's list of drawbuffers/renderbuffers. > * For winsys FBOs this comes from the GL state (which may have > @@ -1473,7 +1473,7 @@ _mesa_make_current( struct gl_context *newCtx, > */ > _mesa_update_draw_buffers(newCtx); > } > - if (!newCtx->ReadBuffer || newCtx->ReadBuffer->Name == 0) { > + if (!newCtx->ReadBuffer || _mesa_is_winsys_fbo(newCtx->ReadBuffer)) > { > _mesa_reference_framebuffer(&newCtx->ReadBuffer, readBuffer); > } > > diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c > index 49b0782..bd9837f 100644 > --- a/src/mesa/main/drawpix.c > +++ b/src/mesa/main/drawpix.c > @@ -36,6 +36,7 @@ > #include "state.h" > #include "dispatch.h" > #include "glformats.h" > +#include "fbobject.h" > > > #if FEATURE_drawpix > @@ -240,7 +241,8 @@ _mesa_CopyPixels( GLint srcx, GLint srcy, GLsizei width, > GLsizei height, >goto end; > } > > - if (ctx->ReadBuffer->Name != 0 && ctx->ReadBuffer->Visual.samples > 0) { > + if (_mesa_is_user_fbo(ctx->ReadBuffer) && > + ctx->ReadBuffer->Visual.samples > 0) { >_mesa_error(ctx, GL_INVALID_OPERATION, > "glCopyPixels(multisample FBO)"); >goto end; > diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c > index f45ece6..13887f8 100644 > --- a/src/mesa/main/framebuffer.c > +++ b/src/mesa/main/framebuffer.c > @@ -347,7 +347,7 @@ _mesa_resizebuffers( struct gl_context *ctx ) >GLuint newWidth, newHeight; >struct gl_framebuffer *buffer = ctx->WinSysDrawBuffer; > > - assert(buffer->Name == 0); > + assert(_mesa_is_winsys_fbo(buffer)); > >/* ask device driver for size of output buffer */ >ctx->Driver.GetBufferSize( buffer, &newWidth, &newHeight ); > @@ -364,7 +364,7 @@ _mesa_resizebuffers( struct gl_context *ctx ) >GLuint newWidth, newHeight; >struct gl_framebuffer *buffer = ctx->WinSysReadBuffer; > > - assert(buffer->Name == 0); > + assert(_mesa_is_winsys_fbo(buffer)); > >/* ask device driver for size of read buffer */ >ctx->Driver.GetBufferSize( buffer, &newWidth, &newHeight ); > @@ -444,7 +444,7 @@ _mesa_update_draw_buffer_bounds(struct gl_context *ctx) > if (!buffer) >return; > > - if (buffer->Name) { > + if (_mesa_is_user_fbo(buffer)) { >/* user-created framebuffer size depends on the renderbuffers */ >update_framebuffer_size(ctx, buffer); > } > diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c > index 82d99fd..7ac8774 100644 > --- a/src/mesa/main/readpix.c > +++ b/src/mesa/main/readpix.c > @@ -37,6 +37,7 @@ > #include "pbo.h" > #include "state.h" > #include "glformats.h" > +#include "fbobject.h" > > > /** > @@ -722,7 +723,8 @@ _mesa_ReadnPixelsARB( GLint x, GLint y, GLsizei width, > GLsizei height, >} > } > > - if (ctx->ReadBuffer->Name != 0 && ctx->ReadBuffer->Visual.samples > 0) { > + if (_mes
Re: [Mesa-dev] Check the compilation problems in mesa-user
On 07/25/2012 10:57 AM, Eric Anholt wrote: Brian Paul writes: On 07/25/2012 09:01 AM, Matt Turner wrote: On Wed, Jul 25, 2012 at 6:57 AM, Brian Paul wrote: Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on my to-do list is to write a gallium state tracker to implement OSMesa for gallium drivers. But I don't know when I'll get to that. OSMesa does software offscreen rendering? Why wouldn't developers just use FBOs these days? Beyond not depending on OSMesa, they'd have hardware acceleration. I think it's mostly legacay apps that use OSMesa. But some OSMesa apps do unusual things like directly touching the color/depth buffer values to avoid glRead/DrawPixels (see the OSMesaGetDepth/ColorBuffer() functions). Even for hardware drivers, people want to be able to directly map renderbuffers (wine, ported DX apps, chromium at least I've hard of). If someone writes an extension for that, we might be able to stop having a custom GL library just for that purpose. I've actually thought about prototyping a GL extension which would allow the user to map renderbuffers and texture images for direct access. One messy part is the need to completely describe the format/layout of the memory since OpenGL doesn't normally let you know those exact details. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Check the compilation problems in mesa-user
Brian Paul writes: > On 07/25/2012 09:01 AM, Matt Turner wrote: >> On Wed, Jul 25, 2012 at 6:57 AM, Brian Paul wrote: Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? >>> >>> >>> OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on >>> my to-do list is to write a gallium state tracker to implement OSMesa for >>> gallium drivers. But I don't know when I'll get to that. >> >> OSMesa does software offscreen rendering? Why wouldn't developers just >> use FBOs these days? Beyond not depending on OSMesa, they'd have >> hardware acceleration. > > I think it's mostly legacay apps that use OSMesa. But some OSMesa > apps do unusual things like directly touching the color/depth buffer > values to avoid glRead/DrawPixels (see the > OSMesaGetDepth/ColorBuffer() functions). Even for hardware drivers, people want to be able to directly map renderbuffers (wine, ported DX apps, chromium at least I've hard of). If someone writes an extension for that, we might be able to stop having a custom GL library just for that purpose. pgpOSmUUcd1gG.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Check the compilation problems in mesa-user
On 07/25/2012 09:01 AM, Matt Turner wrote: On Wed, Jul 25, 2012 at 6:57 AM, Brian Paul wrote: Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on my to-do list is to write a gallium state tracker to implement OSMesa for gallium drivers. But I don't know when I'll get to that. OSMesa does software offscreen rendering? Why wouldn't developers just use FBOs these days? Beyond not depending on OSMesa, they'd have hardware acceleration. I think it's mostly legacay apps that use OSMesa. But some OSMesa apps do unusual things like directly touching the color/depth buffer values to avoid glRead/DrawPixels (see the OSMesaGetDepth/ColorBuffer() functions). -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Check the compilation problems in mesa-user
On Wed, Jul 25, 2012 at 6:57 AM, Brian Paul wrote: >> Several days passed and no software renderer. >> I rather would like to test the llvmpipe >> than fix the compiler... >> >> What is the status with OSMesa and llvmpipe? > > > OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on > my to-do list is to write a gallium state tracker to implement OSMesa for > gallium drivers. But I don't know when I'll get to that. OSMesa does software offscreen rendering? Why wouldn't developers just use FBOs these days? Beyond not depending on OSMesa, they'd have hardware acceleration. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] mesa: Make more consistent use of _mesa_is_{user, winsys}_fbo()
On 07/25/2012 08:19 AM, Paul Berry wrote: A lot of code was still differentiating between between winsys and user fbos by testing the fbo's name against zero. This converts everything in core mesa, the state tracker, and src/mesa/program over to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo(). Nice. Patches 1 & 2: Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] i965: Use sendc for all render target writes on Gen6+.
The sendc instruction causes the fragment shader thread to wait for any dependent threads (i.e. threads rendering to overlapping pixels) to complete before sending the message. We need to use sendc on the first render target write in order to guarantee that fragment shader outputs are written to the render target in the correct order. Previously, we only used the "sendc" instruction when writing to binding table index 0. This did the right thing for fragment shaders, because our fragment shader back-ends always issue their first render target write to binding table index 0. However, it did the wrong thing for blorp, which performs its render target writes to binding table index 1. A more robust solution is to use sendc for all render target writes. This should not produce any performance penalty, since after the first sendc, all of the dependent threads will have completed. For more information about sendc, see the Ivy Bridge PRM, Vol4 Part3 p218 (sendc - Conditional Send Message), and p54 (TDR Registers). --- src/mesa/drivers/dri/i965/brw_eu_emit.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c b/src/mesa/drivers/dri/i965/brw_eu_emit.c index 93e84ae..25bf91b 100644 --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c @@ -2259,7 +2259,7 @@ void brw_fb_WRITE(struct brw_compile *p, else dest = retype(vec8(brw_null_reg()), BRW_REGISTER_TYPE_UW); - if (intel->gen >= 6 && binding_table_index == 0) { + if (intel->gen >= 6) { insn = next_insn(p, BRW_OPCODE_SENDC); } else { insn = next_insn(p, BRW_OPCODE_SEND); -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] i965/msaa: Remove TODO comments that are no longer relevant.
--- src/mesa/drivers/dri/i965/brw_state_upload.c |4 ++-- src/mesa/drivers/dri/i965/gen6_blorp.cpp |1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c b/src/mesa/drivers/dri/i965/brw_state_upload.c index 551fa6a..12535ed 100644 --- a/src/mesa/drivers/dri/i965/brw_state_upload.c +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c @@ -153,7 +153,7 @@ static const struct brw_tracked_state *gen6_atoms[] = &brw_samplers, &gen6_sampler_state, - &gen6_multisample_state, /* TODO: is this the right spot? */ + &gen6_multisample_state, &gen6_vs_state, &gen6_gs_state, @@ -222,7 +222,7 @@ const struct brw_tracked_state *gen7_atoms[] = &brw_wm_binding_table, &gen7_samplers, - &gen6_multisample_state, /* TODO: is this the right spot? */ + &gen6_multisample_state, &gen7_disable_stages, &gen7_vs_state, diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp b/src/mesa/drivers/dri/i965/gen6_blorp.cpp index b2cafdb..b134ab4 100644 --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp @@ -299,7 +299,6 @@ gen6_blorp_emit_blend_state(struct brw_context *brw, memset(blend, 0, sizeof(*blend)); - // TODO: handle other formats. blend->blend1.pre_blend_clamp_enable = 1; blend->blend1.post_blend_clamp_enable = 1; blend->blend1.clamp_range = BRW_RENDERTARGET_CLAMPRANGE_FORMAT; -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] intel: Make more consistent use of _mesa_is_{user, winsys}_fbo()
A lot of code was still differentiating between between winsys and user fbos by testing the fbo's name against zero. This converts everything in the i915 and 965 drivers over to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo(). --- src/mesa/drivers/dri/i915/i830_vtbl.c |3 ++- src/mesa/drivers/dri/i915/intel_tris.c |3 ++- src/mesa/drivers/dri/i965/brw_blorp_blit.cpp|5 +++-- src/mesa/drivers/dri/intel/intel_blit.c |3 ++- src/mesa/drivers/dri/intel/intel_buffers.c |2 +- src/mesa/drivers/dri/intel/intel_fbo.c |2 +- src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |5 +++-- src/mesa/drivers/dri/intel/intel_pixel_copy.c |5 +++-- src/mesa/drivers/dri/intel/intel_tex_copy.c |3 ++- 9 files changed, 19 insertions(+), 12 deletions(-) diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c b/src/mesa/drivers/dri/i915/i830_vtbl.c index 28e95d9..6019852 100644 --- a/src/mesa/drivers/dri/i915/i830_vtbl.c +++ b/src/mesa/drivers/dri/i915/i830_vtbl.c @@ -39,6 +39,7 @@ #include "swrast_setup/swrast_setup.h" #include "main/renderbuffer.h" #include "main/framebuffer.h" +#include "main/fbobject.h" #define FILE_DEBUG_FLAG DEBUG_STATE @@ -769,7 +770,7 @@ i830_update_draw_buffer(struct intel_context *intel) /* Get the intel_renderbuffer for the single colorbuffer we're drawing * into. */ - if (fb->Name == 0) { + if (_mesa_is_winsys_fbo(fb)) { /* drawing to window system buffer */ if (fb->_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT) colorRegions[0] = intel_get_rb_region(fb, BUFFER_FRONT_LEFT); diff --git a/src/mesa/drivers/dri/i915/intel_tris.c b/src/mesa/drivers/dri/i915/intel_tris.c index cf67d74..5954b24 100644 --- a/src/mesa/drivers/dri/i915/intel_tris.c +++ b/src/mesa/drivers/dri/i915/intel_tris.c @@ -38,6 +38,7 @@ #include "main/texobj.h" #include "main/state.h" #include "main/dd.h" +#include "main/fbobject.h" #include "swrast/swrast.h" #include "swrast_setup/swrast_setup.h" @@ -503,7 +504,7 @@ intel_emit_fragcoord(struct intel_context *intel, intelVertexPtr v) fragcoord[0] = vertex_position[0]; - if (fb->Name) + if (_mesa_is_user_fbo(fb)) fragcoord[1] = vertex_position[1]; else fragcoord[1] = fb->Height - vertex_position[1]; diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp index f8b7e4a..bd15632 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp @@ -22,6 +22,7 @@ */ #include "main/teximage.h" +#include "main/fbobject.h" #include "glsl/ralloc.h" @@ -214,13 +215,13 @@ try_blorp_blit(struct intel_context *intel, /* Account for the fact that in the system framebuffer, the origin is at * the lower left. */ - if (read_fb->Name == 0) { + if (_mesa_is_winsys_fbo(read_fb)) { GLint tmp = read_fb->Height - srcY0; srcY0 = read_fb->Height - srcY1; srcY1 = tmp; mirror_y = !mirror_y; } - if (draw_fb->Name == 0) { + if (_mesa_is_winsys_fbo(draw_fb)) { GLint tmp = draw_fb->Height - dstY0; dstY0 = draw_fb->Height - dstY1; dstY1 = tmp; diff --git a/src/mesa/drivers/dri/intel/intel_blit.c b/src/mesa/drivers/dri/intel/intel_blit.c index fd4a86c..36a2c6a 100644 --- a/src/mesa/drivers/dri/intel/intel_blit.c +++ b/src/mesa/drivers/dri/intel/intel_blit.c @@ -30,6 +30,7 @@ #include "main/context.h" #include "main/enums.h" #include "main/colormac.h" +#include "main/fbobject.h" #include "intel_blit.h" #include "intel_buffers.h" @@ -248,7 +249,7 @@ intelClearWithBlit(struct gl_context *ctx, GLbitfield mask) } cx = fb->_Xmin; - if (fb->Name == 0) + if (_mesa_is_winsys_fbo(fb)) cy = ctx->DrawBuffer->Height - fb->_Ymax; else cy = fb->_Ymin; diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c b/src/mesa/drivers/dri/intel/intel_buffers.c index 2b02763..9a9a259 100644 --- a/src/mesa/drivers/dri/intel/intel_buffers.c +++ b/src/mesa/drivers/dri/intel/intel_buffers.c @@ -70,7 +70,7 @@ void intel_check_front_buffer_rendering(struct intel_context *intel) { const struct gl_framebuffer *fb = intel->ctx.DrawBuffer; - if (fb->Name == 0) { + if (_mesa_is_winsys_fbo(fb)) { /* drawing to window system buffer */ if (fb->_NumColorDrawBuffers > 0) { if (fb->_ColorDrawBufferIndexes[0] == BUFFER_FRONT_LEFT) { diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c index ac7d6c1..a53985b 100644 --- a/src/mesa/drivers/dri/intel/intel_fbo.c +++ b/src/mesa/drivers/dri/intel/intel_fbo.c @@ -359,7 +359,7 @@ intel_resize_buffers(struct gl_context *ctx, struct gl_framebuffer *fb, fb->Initialized = true; /* XXX remove someday */ - if (fb->Name != 0) { + if (_mesa_is_user_fbo(fb)) { return; } diff --git a/src/mesa/drivers/dri/intel/intel_pixel_b
[Mesa-dev] [PATCH 1/4] mesa: Make more consistent use of _mesa_is_{user, winsys}_fbo()
A lot of code was still differentiating between between winsys and user fbos by testing the fbo's name against zero. This converts everything in core mesa, the state tracker, and src/mesa/program over to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo(). --- src/mesa/main/context.c |8 src/mesa/main/drawpix.c |4 +++- src/mesa/main/framebuffer.c |6 +++--- src/mesa/main/readpix.c |4 +++- src/mesa/program/prog_statevars.c |3 ++- src/mesa/state_tracker/st_cb_viewport.c |3 ++- src/mesa/state_tracker/st_context.h |3 ++- src/mesa/state_tracker/st_manager.c |3 ++- 8 files changed, 21 insertions(+), 13 deletions(-) diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c index 41550f9..243053e 100644 --- a/src/mesa/main/context.c +++ b/src/mesa/main/context.c @@ -1456,8 +1456,8 @@ _mesa_make_current( struct gl_context *newCtx, _glapi_set_dispatch(newCtx->CurrentDispatch); if (drawBuffer && readBuffer) { - ASSERT(drawBuffer->Name == 0); - ASSERT(readBuffer->Name == 0); + ASSERT(_mesa_is_winsys_fbo(drawBuffer)); + ASSERT(_mesa_is_winsys_fbo(readBuffer)); _mesa_reference_framebuffer(&newCtx->WinSysDrawBuffer, drawBuffer); _mesa_reference_framebuffer(&newCtx->WinSysReadBuffer, readBuffer); @@ -1465,7 +1465,7 @@ _mesa_make_current( struct gl_context *newCtx, * Only set the context's Draw/ReadBuffer fields if they're NULL * or not bound to a user-created FBO. */ - if (!newCtx->DrawBuffer || newCtx->DrawBuffer->Name == 0) { + if (!newCtx->DrawBuffer || _mesa_is_winsys_fbo(newCtx->DrawBuffer)) { _mesa_reference_framebuffer(&newCtx->DrawBuffer, drawBuffer); /* Update the FBO's list of drawbuffers/renderbuffers. * For winsys FBOs this comes from the GL state (which may have @@ -1473,7 +1473,7 @@ _mesa_make_current( struct gl_context *newCtx, */ _mesa_update_draw_buffers(newCtx); } - if (!newCtx->ReadBuffer || newCtx->ReadBuffer->Name == 0) { + if (!newCtx->ReadBuffer || _mesa_is_winsys_fbo(newCtx->ReadBuffer)) { _mesa_reference_framebuffer(&newCtx->ReadBuffer, readBuffer); } diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c index 49b0782..bd9837f 100644 --- a/src/mesa/main/drawpix.c +++ b/src/mesa/main/drawpix.c @@ -36,6 +36,7 @@ #include "state.h" #include "dispatch.h" #include "glformats.h" +#include "fbobject.h" #if FEATURE_drawpix @@ -240,7 +241,8 @@ _mesa_CopyPixels( GLint srcx, GLint srcy, GLsizei width, GLsizei height, goto end; } - if (ctx->ReadBuffer->Name != 0 && ctx->ReadBuffer->Visual.samples > 0) { + if (_mesa_is_user_fbo(ctx->ReadBuffer) && + ctx->ReadBuffer->Visual.samples > 0) { _mesa_error(ctx, GL_INVALID_OPERATION, "glCopyPixels(multisample FBO)"); goto end; diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c index f45ece6..13887f8 100644 --- a/src/mesa/main/framebuffer.c +++ b/src/mesa/main/framebuffer.c @@ -347,7 +347,7 @@ _mesa_resizebuffers( struct gl_context *ctx ) GLuint newWidth, newHeight; struct gl_framebuffer *buffer = ctx->WinSysDrawBuffer; - assert(buffer->Name == 0); + assert(_mesa_is_winsys_fbo(buffer)); /* ask device driver for size of output buffer */ ctx->Driver.GetBufferSize( buffer, &newWidth, &newHeight ); @@ -364,7 +364,7 @@ _mesa_resizebuffers( struct gl_context *ctx ) GLuint newWidth, newHeight; struct gl_framebuffer *buffer = ctx->WinSysReadBuffer; - assert(buffer->Name == 0); + assert(_mesa_is_winsys_fbo(buffer)); /* ask device driver for size of read buffer */ ctx->Driver.GetBufferSize( buffer, &newWidth, &newHeight ); @@ -444,7 +444,7 @@ _mesa_update_draw_buffer_bounds(struct gl_context *ctx) if (!buffer) return; - if (buffer->Name) { + if (_mesa_is_user_fbo(buffer)) { /* user-created framebuffer size depends on the renderbuffers */ update_framebuffer_size(ctx, buffer); } diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c index 82d99fd..7ac8774 100644 --- a/src/mesa/main/readpix.c +++ b/src/mesa/main/readpix.c @@ -37,6 +37,7 @@ #include "pbo.h" #include "state.h" #include "glformats.h" +#include "fbobject.h" /** @@ -722,7 +723,8 @@ _mesa_ReadnPixelsARB( GLint x, GLint y, GLsizei width, GLsizei height, } } - if (ctx->ReadBuffer->Name != 0 && ctx->ReadBuffer->Visual.samples > 0) { + if (_mesa_is_user_fbo(ctx->ReadBuffer) && + ctx->ReadBuffer->Visual.samples > 0) { _mesa_error(ctx, GL_INVALID_OPERATION, "glReadPixels(multisample FBO)"); return; } diff --git a/src/mesa/program/prog_statevars.c b/src/mesa/program/prog_statevars.c index 98ab9d0..e881c09
[Mesa-dev] [Bug 52282] [softpipe] piglit arb_shader_texture_lod-texgrad regression
https://bugs.freedesktop.org/show_bug.cgi?id=52282 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Brian Paul 2012-07-25 14:03:29 PDT --- This was also fixed by commit fa76d04aeaf249956072c023661b1e2cda103584. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] gallium: specify resource_resolve destination via a pipe_surface
On 07/25/2012 05:54 AM, Christoph Bumiller wrote: The format member of pipe_surface may differ from that of the pipe_resource, which is used to communicate, for instance, whether sRGB encode should be enabled in the resolve operation or not. Fixes resolve to sRGB surfaces in mesa/st when GL_FRAMEBUFFER_SRGB is disabled. --- src/gallium/drivers/nv30/nv30_miptree.c |5 +++- src/gallium/drivers/nv50/nv50_surface.c | 32 -- src/gallium/drivers/nvc0/nvc0_surface.c | 32 -- src/gallium/drivers/r300/r300_render.c |7 +- src/gallium/include/pipe/p_state.h |6 +--- src/mesa/state_tracker/st_cb_blit.c | 15 + 6 files changed, 39 insertions(+), 58 deletions(-) diff --git a/src/gallium/drivers/nv30/nv30_miptree.c b/src/gallium/drivers/nv30/nv30_miptree.c index 7e67729..cd6a814 100644 --- a/src/gallium/drivers/nv30/nv30_miptree.c +++ b/src/gallium/drivers/nv30/nv30_miptree.c @@ -153,7 +153,10 @@ nv30_resource_resolve(struct pipe_context *pipe, define_rect(info->src.res, 0, 0, info->src.x0, info->src.y0, info->src.x1 - info->src.x0, info->src.y1 - info->src.y0,&src); - define_rect(info->dst.res, info->dst.level, 0, info->dst.x0, info->dst.y0, + define_rect(info->dst.surface->texture, + info->dst.surface->u.tex.level, + info->dst.surface->u.tex.first_layer, + info->dst.x0, info->dst.y0, info->dst.x1 - info->dst.x0, info->dst.y1 - info->dst.y0,&dst); nv30_transfer_rect(nv30, BILINEAR,&src,&dst); diff --git a/src/gallium/drivers/nv50/nv50_surface.c b/src/gallium/drivers/nv50/nv50_surface.c index 0872f8d..ed5223b 100644 --- a/src/gallium/drivers/nv50/nv50_surface.c +++ b/src/gallium/drivers/nv50/nv50_surface.c @@ -436,6 +436,7 @@ struct nv50_blitctx unsigned num_samplers[3]; struct pipe_sampler_view *texture[2]; struct nv50_tsc_entry *sampler[2]; + enum pipe_format format; unsigned dirty; } saved; struct nv50_program vp; @@ -661,26 +662,19 @@ nv50_blitctx_get_color_mask_and_fp(struct nv50_blitctx *blit, } static void -nv50_blit_set_dst(struct nv50_context *nv50, - struct pipe_resource *res, unsigned level, unsigned layer) +nv50_blit_set_dst(struct nv50_context *nv50, struct pipe_surface *surf, + struct nv50_blitctx *blit) { - struct pipe_context *pipe =&nv50->base.pipe; - struct pipe_surface templ; + blit->saved.format = surf->format; - if (util_format_is_depth_or_stencil(res->format)) - templ.format = nv50_blit_zeta_to_colour_format(res->format); - else - templ.format = res->format; - - templ.usage = PIPE_USAGE_STREAM; - templ.u.tex.level = level; - templ.u.tex.first_layer = templ.u.tex.last_layer = layer; + if (util_format_is_depth_or_stencil(surf->format)) + surf->format = nv50_blit_zeta_to_colour_format(surf->format); - nv50->framebuffer.cbufs[0] = nv50_miptree_surface_new(pipe, res,&templ); + nv50->framebuffer.cbufs[0] = surf; nv50->framebuffer.nr_cbufs = 1; nv50->framebuffer.zsbuf = NULL; - nv50->framebuffer.width = nv50->framebuffer.cbufs[0]->width; - nv50->framebuffer.height = nv50->framebuffer.cbufs[0]->height; + nv50->framebuffer.width = surf->width; + nv50->framebuffer.height = surf->height; } static INLINE void @@ -822,7 +816,7 @@ nv50_blitctx_post_blit(struct nv50_context *nv50, struct nv50_blitctx *blit) { int s; - pipe_surface_reference(&nv50->framebuffer.cbufs[0], NULL); + nv50->framebuffer.cbufs[0]->format = blit->saved.format; nv50->framebuffer.width = blit->saved.fb.width; nv50->framebuffer.height = blit->saved.fb.height; @@ -862,7 +856,7 @@ nv50_resource_resolve(struct pipe_context *pipe, struct nv50_blitctx *blit = screen->blitctx; struct nouveau_pushbuf *push = nv50->base.pushbuf; struct pipe_resource *src = info->src.res; - struct pipe_resource *dst = info->dst.res; + struct pipe_resource *dst = info->dst.surface->texture; float x0, x1, y0, y1, z; float x_range, y_range; @@ -872,8 +866,8 @@ nv50_resource_resolve(struct pipe_context *pipe, nv50_blitctx_pre_blit(blit, nv50); - nv50_blit_set_dst(nv50, dst, info->dst.level, info->dst.layer); - nv50_blit_set_src(nv50, src, 0, info->src.layer); + nv50_blit_set_dst(nv50, info->dst.surface, blit); + nv50_blit_set_src(nv50, src, 0, info->src.layer); nv50_blitctx_prepare_state(blit); diff --git a/src/gallium/drivers/nvc0/nvc0_surface.c b/src/gallium/drivers/nvc0/nvc0_surface.c index 607b02e..6773f96 100644 --- a/src/gallium/drivers/nvc0/nvc0_surface.c +++ b/src/gallium/drivers/nvc0/nvc0_surface.c @@ -457,6 +457,7 @@ struct nvc0_blitctx unsigned num_samplers[5]; struct pipe_sampler_view *texture[2]; struct nv50_tsc_entry *sampler[2]; + enum pipe_format format; unsigned dirty; } sav
Re: [Mesa-dev] Check the compilation problems in mesa-user
On 07/23/2012 07:06 PM, Juhana Sadeharju wrote: Hello. Would you please check the compilation problem posted at mesa-user? Could you repost the issue here where more developers can see it? Several days passed and no software renderer. I rather would like to test the llvmpipe than fix the compiler... What is the status with OSMesa and llvmpipe? OSMesa only works with the legacy swrast driver, not llvmpipe. One thing on my to-do list is to write a gallium state tracker to implement OSMesa for gallium drivers. But I don't know when I'll get to that. How to compile Mesa so that gtkglext can be used with llvmpipe? What other choises than gtkglext? Is gtkglext up-to-date? I used it previously with Mesa 5.0 or the like. I suspect that gtkglext uses the GLX interface so if you compile llvmpipe normally you'll get a libGL.so with the GLX interface and llvmpipe (and softpipe) driver(s). It should work fine. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Fix build with clang.
On 07/25/2012 12:06 AM, Vinson Lee wrote: Signed-off-by: Vinson Lee --- scons/gallium.py |3 ++- src/gallium/winsys/svga/drm/SConscript |2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/scons/gallium.py b/scons/gallium.py index 001a5de..458651b 100755 --- a/scons/gallium.py +++ b/scons/gallium.py @@ -140,6 +140,7 @@ def generate(env): env['gcc'] = 'gcc' in os.path.basename(env['CC']).split('-') env['msvc'] = env['CC'] == 'cl' env['suncc'] = env['platform'] == 'sunos' and os.path.basename(env['CC']) == 'cc' +env['clang'] = env['CC'] == 'clang' if env['msvc'] and env['toolchain'] == 'default' and env['machine'] == 'x86_64': # MSVC x64 support is broken in earlier versions of scons @@ -482,7 +483,7 @@ def generate(env): env.Append(SHLINKFLAGS = shlinkflags) # We have C++ in several libraries, so always link with the C++ compiler -if env['gcc']: +if env['gcc'] or env['clang']: env['LINK'] = env['CXX'] # Default libs diff --git a/src/gallium/winsys/svga/drm/SConscript b/src/gallium/winsys/svga/drm/SConscript index ee782c8..2d511d2 100644 --- a/src/gallium/winsys/svga/drm/SConscript +++ b/src/gallium/winsys/svga/drm/SConscript @@ -4,7 +4,7 @@ env = env.Clone() env.PkgUseModules('DRM') -if env['gcc']: +if env['gcc'] or env['clang']: env.Append(CCFLAGS = ['-fvisibility=hidden']) env.Append(CPPDEFINES = [ 'HAVE_STDINT_H', Looks OK to me. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 47375] Blender crash on startup after upgrade to mesa 8.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=47375 --- Comment #13 from Brian Paul 2012-07-25 13:53:09 PDT --- Sorry, I misread your update too quickly and thought that you had added some assertions. I think we still need to get to the root cause of those before trying to diagnose performance problems. The "unexpected type in get_row()" error is probably related to the failed assertion and will hopefully be fixed when the first problem is fixed. Unfortunately, I can't reproduce this here. I have blender 2.63a and tested it with swrast. I forced Mesa to take the _mesa_meta_DrawPixels() path but it's not calling _swrast_DrawPixels(). The 'fallback' variable is false while it seems to be true for you. Maybe you could find out why 'fallback' is getting set. I also tried forcing fallback=1 so that _swrast_DrawPixels() gets called but I didn't see any failed assertions. I'm using the Mesa 8.0.x branch. I don't have a r200 gpu to try that driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 52369] [softpipe] piglit mipmap-setup regression
https://bugs.freedesktop.org/show_bug.cgi?id=52369 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Brian Paul 2012-07-25 13:48:12 PDT --- Fixed with commit fa76d04aeaf249956072c023661b1e2cda103584 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] mesa: remove _math_matrix_alloc_inv()
Always allocate space for the inverse matrix in _math_matrix_ctr() since we were always calling _math_matrix_alloc_inv() anyway. --- src/mesa/main/matrix.c|4 +-- src/mesa/math/m_matrix.c | 51 - src/mesa/math/m_matrix.h |5 +--- src/mesa/program/prog_statevars.c |1 - 4 files changed, 13 insertions(+), 48 deletions(-) diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c index f479a22..b09fa4d 100644 --- a/src/mesa/main/matrix.c +++ b/src/mesa/main/matrix.c @@ -658,8 +658,7 @@ void _mesa_update_modelview_project( struct gl_context *ctx, GLuint new_state ) * \param dirtyFlag dirty flag. * * Allocates an array of \p maxDepth elements for the matrix stack and calls - * _math_matrix_ctr() and _math_matrix_alloc_inv() for each element to - * initialize it. + * _math_matrix_ctr() for each element to initialize it. */ static void init_matrix_stack( struct gl_matrix_stack *stack, @@ -674,7 +673,6 @@ init_matrix_stack( struct gl_matrix_stack *stack, stack->Stack = (GLmatrix *) CALLOC(maxDepth * sizeof(GLmatrix)); for (i = 0; i < maxDepth; i++) { _math_matrix_ctr(&stack->Stack[i]); - _math_matrix_alloc_inv(&stack->Stack[i]); } stack->Top = stack->Stack; } diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c index ffbdcdb..58a691c 100644 --- a/src/mesa/math/m_matrix.c +++ b/src/mesa/math/m_matrix.c @@ -296,19 +296,15 @@ static void print_matrix_floats( const GLfloat m[16] ) void _math_matrix_print( const GLmatrix *m ) { + GLfloat prod[16]; + _mesa_debug(NULL, "Matrix type: %s, flags: %x\n", types[m->type], m->flags); print_matrix_floats(m->m); _mesa_debug(NULL, "Inverse: \n"); - if (m->inv) { - GLfloat prod[16]; - print_matrix_floats(m->inv); - matmul4(prod, m->m, m->inv); - _mesa_debug(NULL, "Mat * Inverse:\n"); - print_matrix_floats(prod); - } - else { - _mesa_debug(NULL, " - not available\n"); - } + print_matrix_floats(m->inv); + matmul4(prod, m->m, m->inv); + _mesa_debug(NULL, "Mat * Inverse:\n"); + print_matrix_floats(prod); } /*@}*/ @@ -1141,9 +1137,7 @@ void _math_matrix_set_identity( GLmatrix *mat ) { memcpy( mat->m, Identity, 16*sizeof(GLfloat) ); - - if (mat->inv) - memcpy( mat->inv, Identity, 16*sizeof(GLfloat) ); + memcpy( mat->inv, Identity, 16*sizeof(GLfloat) ); mat->type = MATRIX_IDENTITY; mat->flags &= ~(MAT_DIRTY_FLAGS| @@ -1444,17 +1438,9 @@ void _math_matrix_copy( GLmatrix *to, const GLmatrix *from ) { memcpy( to->m, from->m, sizeof(Identity) ); + memcpy(to->inv, from->inv, sizeof(from->inv)); to->flags = from->flags; to->type = from->type; - - if (to->inv != 0) { - if (from->inv == 0) { -matrix_invert( to ); - } - else { -memcpy(to->inv, from->inv, sizeof(GLfloat)*16); - } - } } /** @@ -1486,7 +1472,9 @@ _math_matrix_ctr( GLmatrix *m ) m->m = (GLfloat *) _mesa_align_malloc( 16 * sizeof(GLfloat), 16 ); if (m->m) memcpy( m->m, Identity, sizeof(Identity) ); - m->inv = NULL; + m->inv = (GLfloat *) _mesa_align_malloc( 16 * sizeof(GLfloat), 16 ); + if (m->inv) + memcpy( m->inv, Identity, sizeof(Identity) ); m->type = MATRIX_IDENTITY; m->flags = 0; } @@ -1511,23 +1499,6 @@ _math_matrix_dtr( GLmatrix *m ) } } -/** - * Allocate a matrix inverse. - * - * \param m matrix. - * - * Allocates the matrix inverse, GLmatrix::inv, and sets it to Identity. - */ -void -_math_matrix_alloc_inv( GLmatrix *m ) -{ - if (!m->inv) { - m->inv = (GLfloat *) _mesa_align_malloc( 16 * sizeof(GLfloat), 16 ); - if (m->inv) - memcpy( m->inv, Identity, 16 * sizeof(GLfloat) ); - } -} - /*@}*/ diff --git a/src/mesa/math/m_matrix.h b/src/mesa/math/m_matrix.h index e8e48aa..9f4ea25 100644 --- a/src/mesa/math/m_matrix.h +++ b/src/mesa/math/m_matrix.h @@ -74,7 +74,7 @@ enum GLmatrixtype { */ typedef struct { GLfloat *m; /**< 16 matrix elements (16-byte aligned) */ - GLfloat *inv; /**< optional 16-element inverse (16-byte aligned) */ + GLfloat *inv; /**< 16-element inverse (16-byte aligned) */ GLuint flags;/**< possible values determined by (of \link * MatFlags MAT_FLAG_* flags\endlink) */ @@ -91,9 +91,6 @@ extern void _math_matrix_dtr( GLmatrix *m ); extern void -_math_matrix_alloc_inv( GLmatrix *m ); - -extern void _math_matrix_mul_matrix( GLmatrix *dest, const GLmatrix *a, const GLmatrix *b ); extern void diff --git a/src/mesa/program/prog_statevars.c b/src/mesa/program/prog_statevars.c index 98ab9d0..2517908 100644 --- a/src/mesa/program/prog_statevars.c +++ b/src/mesa/program/prog_statevars.c @@ -322,7 +322,6 @@ _mesa_fetch_state(struct gl_context *ctx, const gl_state_index state[], modifier == STATE_MATRIX_INVTRANS) { /* Be sure inverse is up to
[Mesa-dev] [PATCH] mesa: loosen small matrix determinant check
When computing a matrix inverse, if the determinant is too small we could hit a divide by zero. There's a check to prevent this (we basically give up on computing the inverse and return the identity matrix.) This patch loosens this test to fix a lighting bug reported by Lars Henning Wendt. v2: use abs(det) to handle negative values NOTE: This is a candidate for the 8.0 branch. --- src/mesa/math/m_matrix.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c index 02aedba..ffbdcdb 100644 --- a/src/mesa/math/m_matrix.c +++ b/src/mesa/math/m_matrix.c @@ -513,7 +513,7 @@ static GLboolean invert_matrix_3d_general( GLmatrix *mat ) det = pos + neg; - if (det*det < 1e-25) + if (FABSF(det) < 1e-25) return GL_FALSE; det = 1.0F / det; -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: specify resource_resolve destination via a pipe_surface
The format member of pipe_surface may differ from that of the pipe_resource, which is used to communicate, for instance, whether sRGB encode should be enabled in the resolve operation or not. Fixes resolve to sRGB surfaces in mesa/st when GL_FRAMEBUFFER_SRGB is disabled. --- src/gallium/drivers/nv30/nv30_miptree.c |5 +++- src/gallium/drivers/nv50/nv50_surface.c | 32 -- src/gallium/drivers/nvc0/nvc0_surface.c | 32 -- src/gallium/drivers/r300/r300_render.c |7 +- src/gallium/include/pipe/p_state.h |6 +--- src/mesa/state_tracker/st_cb_blit.c | 15 + 6 files changed, 39 insertions(+), 58 deletions(-) diff --git a/src/gallium/drivers/nv30/nv30_miptree.c b/src/gallium/drivers/nv30/nv30_miptree.c index 7e67729..cd6a814 100644 --- a/src/gallium/drivers/nv30/nv30_miptree.c +++ b/src/gallium/drivers/nv30/nv30_miptree.c @@ -153,7 +153,10 @@ nv30_resource_resolve(struct pipe_context *pipe, define_rect(info->src.res, 0, 0, info->src.x0, info->src.y0, info->src.x1 - info->src.x0, info->src.y1 - info->src.y0, &src); - define_rect(info->dst.res, info->dst.level, 0, info->dst.x0, info->dst.y0, + define_rect(info->dst.surface->texture, + info->dst.surface->u.tex.level, + info->dst.surface->u.tex.first_layer, + info->dst.x0, info->dst.y0, info->dst.x1 - info->dst.x0, info->dst.y1 - info->dst.y0, &dst); nv30_transfer_rect(nv30, BILINEAR, &src, &dst); diff --git a/src/gallium/drivers/nv50/nv50_surface.c b/src/gallium/drivers/nv50/nv50_surface.c index 0872f8d..ed5223b 100644 --- a/src/gallium/drivers/nv50/nv50_surface.c +++ b/src/gallium/drivers/nv50/nv50_surface.c @@ -436,6 +436,7 @@ struct nv50_blitctx unsigned num_samplers[3]; struct pipe_sampler_view *texture[2]; struct nv50_tsc_entry *sampler[2]; + enum pipe_format format; unsigned dirty; } saved; struct nv50_program vp; @@ -661,26 +662,19 @@ nv50_blitctx_get_color_mask_and_fp(struct nv50_blitctx *blit, } static void -nv50_blit_set_dst(struct nv50_context *nv50, - struct pipe_resource *res, unsigned level, unsigned layer) +nv50_blit_set_dst(struct nv50_context *nv50, struct pipe_surface *surf, + struct nv50_blitctx *blit) { - struct pipe_context *pipe = &nv50->base.pipe; - struct pipe_surface templ; + blit->saved.format = surf->format; - if (util_format_is_depth_or_stencil(res->format)) - templ.format = nv50_blit_zeta_to_colour_format(res->format); - else - templ.format = res->format; - - templ.usage = PIPE_USAGE_STREAM; - templ.u.tex.level = level; - templ.u.tex.first_layer = templ.u.tex.last_layer = layer; + if (util_format_is_depth_or_stencil(surf->format)) + surf->format = nv50_blit_zeta_to_colour_format(surf->format); - nv50->framebuffer.cbufs[0] = nv50_miptree_surface_new(pipe, res, &templ); + nv50->framebuffer.cbufs[0] = surf; nv50->framebuffer.nr_cbufs = 1; nv50->framebuffer.zsbuf = NULL; - nv50->framebuffer.width = nv50->framebuffer.cbufs[0]->width; - nv50->framebuffer.height = nv50->framebuffer.cbufs[0]->height; + nv50->framebuffer.width = surf->width; + nv50->framebuffer.height = surf->height; } static INLINE void @@ -822,7 +816,7 @@ nv50_blitctx_post_blit(struct nv50_context *nv50, struct nv50_blitctx *blit) { int s; - pipe_surface_reference(&nv50->framebuffer.cbufs[0], NULL); + nv50->framebuffer.cbufs[0]->format = blit->saved.format; nv50->framebuffer.width = blit->saved.fb.width; nv50->framebuffer.height = blit->saved.fb.height; @@ -862,7 +856,7 @@ nv50_resource_resolve(struct pipe_context *pipe, struct nv50_blitctx *blit = screen->blitctx; struct nouveau_pushbuf *push = nv50->base.pushbuf; struct pipe_resource *src = info->src.res; - struct pipe_resource *dst = info->dst.res; + struct pipe_resource *dst = info->dst.surface->texture; float x0, x1, y0, y1, z; float x_range, y_range; @@ -872,8 +866,8 @@ nv50_resource_resolve(struct pipe_context *pipe, nv50_blitctx_pre_blit(blit, nv50); - nv50_blit_set_dst(nv50, dst, info->dst.level, info->dst.layer); - nv50_blit_set_src(nv50, src, 0, info->src.layer); + nv50_blit_set_dst(nv50, info->dst.surface, blit); + nv50_blit_set_src(nv50, src, 0, info->src.layer); nv50_blitctx_prepare_state(blit); diff --git a/src/gallium/drivers/nvc0/nvc0_surface.c b/src/gallium/drivers/nvc0/nvc0_surface.c index 607b02e..6773f96 100644 --- a/src/gallium/drivers/nvc0/nvc0_surface.c +++ b/src/gallium/drivers/nvc0/nvc0_surface.c @@ -457,6 +457,7 @@ struct nvc0_blitctx unsigned num_samplers[5]; struct pipe_sampler_view *texture[2]; struct nv50_tsc_entry *sampler[2]; + enum pipe_format format; unsigned dirty; } saved; struct nvc0_program vp; @@ -727,26 +728,19 @@ nvc0_blitctx_get_co
Re: [Mesa-dev] [PATCH] sp_tex_sample: Fix stupid copy/paste error.
[Sorry, mail was down yesterday] On Tue, Jul 24, 2012 at 10:06:05AM -0600, Brian Paul wrote: > Does this fix bug 52369? Yes. > Do you need me to commit this for you? Yes please. Perhaps I should see about getting a fdo account. Best, OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev