Re: [Mesa3d-dev] regression in r600g with a22aba4eae9b29db731487bce90e8292f7e82c72
On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie airl...@gmail.com wrote: Hi Brian, st/mesa: check image size before copy_image_data_to_texture() This causes a regression with NPOT textures in fbo-generate-mipmaps on r600g. FWIW r300g and softpipe are broken too. The issue seems to be driver-independent. Marek -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa-dev] [PATCH 0/6] ARB_texture_float
There won't be any other way. It should be the Linux distributors' decision whether their users can use it or not. Marek On Fri, Apr 1, 2011 at 5:14 PM, Philipp Klaus Krause p...@spth.de wrote: Am 01.04.2011 15:56, schrieb Marek Olšák: Hi, please read on. This patch series adds the last pieces of ARB_texture_float support to Mesa and Gallium. The thing is Mesa and Gallium more or less already support float textures and renderbuffers in master. Gallium has full floating-point support in the interface and if it was a public API, people could just expose it and not care. There is clearly a need for a configure switch which can hide float renderbuffers from any interface, public or private, and driver developers should use such a switch. Would there be a way to make this switch easier to flip by the user? As you state it this looks like a lot of work to users that want to have it enabled, at least when compared to the effort to get S3TC support. Philipp -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model
On Fri, Dec 17, 2010 at 4:32 PM, Brian Paul bri...@vmware.com wrote: Christoph, I don't see a patch for the st/mesa program translation code to check that we don't exceed the limit. Were you doing to take care of that too? I guess we're assuming that the max number of generic inputs == max number of generic outputs. I think that's OK until a counter case appears. The way I understand it is that the max number of generic outputs is equal to the max number of generic inputs in the next shader stage (the same logic applies to some other shader caps too). I guess we need to use get_param to determine which shader stages are supported by the driver to know which one is next. The name *PIPE_SHADER_CAP_MAX_GENERIC_INPUT_INDEX* would be less ambiguous (still not perfect though). However I don't believe in usefulness of this new cap, at least not without some serious state tracker work. I don't consider failing to translate a shader if some CAP is too low particularly useful. (posting to mesa-dev as well) Marek -Brian On 12/17/2010 05:28 AM, Keith Whitwell wrote: Christoph, This looks good. Thanks for bringing this back to life. Keith On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote: On 12/14/2010 12:36 PM, Keith Whitwell wrote: On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote: I want to warm this up again adding nvc0 and GL_ARB_separate_shader_objects to the picture. The latter extends GL_EXT_separate_shader_objects to support user defined varyings and guarantees well defined behaviour only if - varyings are declared inside the gl_PerVertex/gl_PerFragment block the blocks match exactly in name, type, qualification, and (most significantly) declaration order. - varyings are assigned matching location qualifiers: like: layout(location = 3) in vec4 normal The number of input locations available to a shader is limited. So, I propose to (loosely) identify GENERIC semantic indices with these location qualifiers and let the pipe driver set a limit on the allowed maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at least support 219 of them - nvc0 offsers 0x200 bytes for generic inputs/outputs). This sounds fine actually. We kicked this around before I was basically ok with the last iteration of the proposal, but this seems ok too. As far as I can tell from a gallium perspective you're really just proposing a new pipe cap _MAX_INPUTS (actually _MAX_GENERIC_INDEX would be clearer), which the state tracker thereafter has to respect? That would be fine with me. First attempt at a patch introducing such a cap attached. My motivation is mostly that the hardware routing table for shader varyings that was present on nv50 has been removed with nvc0 (Fermi). And I'm glad, because filling 4 routing tables (since we have 5 shader types now) is somewhat annoying. And so applying relocations to shaders - it can be done, it's probably not too time consuming, but it's just plain *unnecessary* (and thus stupid) for OpenGL. Now about d3d9 ... 1. don't care, I don't see a d3d9 state tracker 2. http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx says n is an optional integer between 0 and the number of resources supported - what supported means here isn't clear to me, but, I didn't find any example where someone used something OpenGL doesn't have (like COLOR2). 3. http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics says Input semantics are similar to the values in the D3DDECLUSAGE. and DECLUSAGE sounds like you're limited to sane values. I think you're on the right track with (1)... It's fairly pointless trying to discuss code here which isn't public I don't think people need to be worrying about what may or may not be important for code they can't see. I know this idea previously got tied up with speculation about what a DX9 state tracker might or might not require, but in retrospect I wish I'd been able to steer conversation away from that. The work on closed components may drive a lot of the feature development and new interfaces, but there's usually enough flexibility that this sort of cleanup isn't a big deal. Keith Not sure if anyone wants to think about this issue at this time (since implementation of ARB_separate_shader_objects is probably far in the GL4 future), but I'd be happy about any comments. Regards, Christoph On 04/13/2010 12:55 PM, Luca Barbieri wrote: This patch series is intended to resolve the issue of semantic-based shader linkage in Gallium. It can also be found in the RFC-gallium-semantics branch. It does not change the current Gallium design, but rather formalizes some limitations to it, and provides infrastructure to implement this model more easily in drivers, along with a full nv30/nv40 implementation.
Re: [Mesa3d-dev] RFC: allow resource_copy_region between different (yet compatabile) formats
On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca jfons...@vmware.com wrote: I'd like to know if there's any objection to change the resource_copy_region semantics to allow copies between different yet compatible formats, where the definition of compatible formats is: formats for which copying the bytes from the source resource unmodified to the destination resource will achieve the same effect of a textured quad blitter There is an helper function util_is_format_compatible() to help making this decision, and these are the non-trivial conversions that this function currently recognizes, (which was produced by u_format_compatible_test.c): b8g8r8a8_unorm - b8g8r8x8_unorm This specific case (and others) might not work, because there are no 0/1 swizzles when blending pixels with the framebuffer, e.g. see this sequence of operations: - Blit from b8g8r8a8 to b8g8r8x8. - x8 now contains a8. - Bind b8g8r8x8 as a colorbuffer. - Use blending with the destination alpha channel. - The original a8 is read instead of 1 (x8) because of lack of swizzles. The blitter and other util functions just need to be extended to explicitly write 1 instead of copying the alpha channel. Something likes this is already done in st/mesa, see the function compatible_src_dst_formats. Marek a8r8g8b8_unorm - x8r8g8b8_unorm b5g5r5a1_unorm - b5g5r5x1_unorm b4g4r4a4_unorm - b4g4r4x4_unorm l8_unorm - r8_unorm i8_unorm - l8_unorm i8_unorm - a8_unorm i8_unorm - r8_unorm l16_unorm - r16_unorm z24_unorm_s8_uscaled - z24x8_unorm s8_uscaled_z24_unorm - x8z24_unorm r8g8b8a8_unorm - r8g8b8x8_unorm a8b8g8r8_srgb - x8b8g8r8_srgb b8g8r8a8_srgb - b8g8r8x8_srgb a8r8g8b8_srgb - x8r8g8b8_srgb a8b8g8r8_unorm - x8b8g8r8_unorm r10g10b10a2_uscaled - r10g10b10x2_uscaled r10sg10sb10sa2u_norm - r10g10b10x2_snorm Note that format compatibility is not commutative. For software drivers this means that memcpy/util_copy_rect() will achieve the correct result. For hardware drivers this means that a VRAM-VRAM 2D blit engine will also achieve the correct result. So I'd expect no implementation change of resource_copy_region() for any driver AFAICT. But I'd like to be sure. Jose -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: allow resource_copy_region between different (yet compatabile) formats
On Mon, Sep 6, 2010 at 9:57 PM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-09-06 at 10:22 -0700, Marek Olšák wrote: On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca jfons...@vmware.com wrote: I'd like to know if there's any objection to change the resource_copy_region semantics to allow copies between different yet compatible formats, where the definition of compatible formats is: formats for which copying the bytes from the source resource unmodified to the destination resource will achieve the same effect of a textured quad blitter There is an helper function util_is_format_compatible() to help making this decision, and these are the non-trivial conversions that this function currently recognizes, (which was produced by u_format_compatible_test.c): b8g8r8a8_unorm - b8g8r8x8_unorm This specific case (and others) might not work, because there are no 0/1 swizzles when blending pixels with the framebuffer, e.g. see this sequence of operations: - Blit from b8g8r8a8 to b8g8r8x8. - x8 now contains a8. - Bind b8g8r8x8 as a colorbuffer. - Use blending with the destination alpha channel. - The original a8 is read instead of 1 (x8) because of lack of swizzles. This is not correct. Or at least not my interpretation. The x in b8g8r8x8 means padding (potentially with with unitialized data). There is no implicit guarantee that it will contain 0xff or anything. When blending to b8g8r8x8, destination alpha is by definition 1.0. It is an implicit swizzle (see e.g., u_format.csv). If the hardware's fixed function blending doesn't understand bgrx formats natively, then the pipe driver should internally replace the destination alpha factor factor with one. It's really simple. See for The dst blending parameter is just a factor the real dst value is multiplied by (except for min/max). There is no way to multiply an arbitrary value by a constant and get 1.0. But you can force 0, of course. I don't think there is hardware which supports such flexible swizzling in the blender. If x8 is just padding as you say, the value of it should be undefined and every operation using the padding bits should be undefined too except for texture sampling. It's not like I have any other choice. Marek -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
On Mon, May 3, 2010 at 1:57 PM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote: I am trying to understand the s3tc init code as nv50 gallium has a problem with that. It looks like some drivers (r300g and llvmpipe) actually inits s3tc in two places : ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() Here is an extract of the backtrace calls while loading fgfs on llvmpipe : driCreateScreen - llvmpipe_create_screen - util_format_s3tc_init driCreateContext - st_create_context - _mesa_create_context_for_api - init_attrib_groups - _mesa_init_texture_s3tc These two functions seem to do more or less the same job, and apparently, the classic mesa init is unused for a gallium driver. So I suppose that init is not necessary, but it happens because gallium and mesa are tightly tied together, and create context is handled similarly, but it shouldn't hurt ? Both inits are necessary. The same .so is used for both paths, but given that gallium and mesa do not depend on each other that's the way to do it. Gallium and mesa also have seperate format translation functions. At least until we start factoring code into a separate library. (I said I'd do it, but stuff came up and I couldn't do when I thought, and I don't know when I'll be able to do it...) Additionally r300g and llvmpipe added util_format_s3tc_init to their create_screen functions, and util/u_format_s3tc.c apparently contains all the functions that a gallium driver uses. So I suppose that nvfx and nv50 should do the same ? If that's correct, the patch below might not be completely wrong. On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry chantry.xav...@gmail.com wrote: flightgear now dies with : Mesa warning: external dxt library not available: texstore_rgba_dxt3 util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' failed. I don't really understand what these stubs are about, they were introduced by following commit : commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 Author: José Fonseca jfons...@vmware.com Date: Wed Apr 7 20:47:38 2010 +0100 util: Use stubs for the dynamically loaded S3TC functions. Loosely based on Luca Barbieri's commit 52e9b990a192a9329006d5f7dd2ac222effea5a5. Looking at llvm and r300 code and trying to guess, I came up with the following patch that allows flightgear to start again. But I don't really understand that stuff so it could be wrong. nvfx is probably affected as well. diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c b/src/gallium/drivers/nouveau/nouveau_screen.c index 233a91a..a91b00b 100644 --- a/src/gallium/drivers/nouveau/nouveau_screen.c +++ b/src/gallium/drivers/nouveau/nouveau_screen.c @@ -5,6 +5,7 @@ #include util/u_memory.h #include util/u_inlines.h #include util/u_format.h +#include util/u_format_s3tc.h #include stdio.h #include errno.h @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev) pscreen-fence_signalled = nouveau_screen_fence_signalled; pscreen-fence_finish = nouveau_screen_fence_finish; + util_format_s3tc_init(); + return 0; } diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c index 2dd1042..0d74c90 100644 --- a/src/gallium/drivers/nv50/nv50_screen.c +++ b/src/gallium/drivers/nv50/nv50_screen.c @@ -20,6 +20,7 @@ * SOFTWARE. */ +#include util/u_format_s3tc.h #include pipe/p_screen.h #include nv50_context.h @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen, case PIPE_FORMAT_A8_UNORM: case PIPE_FORMAT_I8_UNORM: case PIPE_FORMAT_L8A8_UNORM: - case PIPE_FORMAT_DXT1_RGB: - case PIPE_FORMAT_DXT1_RGBA: - case PIPE_FORMAT_DXT3_RGBA: - case PIPE_FORMAT_DXT5_RGBA: case PIPE_FORMAT_S8_USCALED_Z24_UNORM: case PIPE_FORMAT_Z24_UNORM_S8_USCALED: case PIPE_FORMAT_Z32_FLOAT: @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen, case PIPE_FORMAT_R16G16_SNORM: case PIPE_FORMAT_R16G16_UNORM: return TRUE; + case PIPE_FORMAT_DXT1_RGB: + case PIPE_FORMAT_DXT1_RGBA: + case PIPE_FORMAT_DXT3_RGBA: + case PIPE_FORMAT_DXT5_RGBA: + return util_format_s3tc_enabled; default: break; } You should only advertise PIPE_FORMAT_DXT* for BIND_SAMPLER_VIEW, or you may end up in very
Re: [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.comwrote: This commit breaks compiz completely here on nvidia G50 (Geforce 8400M) Compiz shows dark screen. (Using nouveau drivers) Without this commit compiz works almost perfectly. The error messages from compiz: debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE debug_get_bool_option: DRAW_FSE = FALSE debug_get_bool_option: DRAW_NO_FSE = FALSE debug_get_bool_option: GALLIUM_DUMP_VS = FALSE Mesa: Mesa 7.9-devel DEBUG build May 1 2010 19:02:06 Mesa warning: software DXTn compression/decompression available debug_get_bool_option: MESA_MVP_DP4 = FALSE debug_get_flags_option: ST_DEBUG = 0x0 Mesa: User error: GL_OUT_OF_MEMORY in glTexImage compiz (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage The commit also causes surface_copy to be called with S3TC textures, breaking loading of such textures in r300g. I am working on a fix for r300g but I haven't expected to get such weird formats in surface_copy. FYI Maxim, please use mesa-...@lists.freedesktop.org instead. -Marek -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell kei...@vmware.com wrote: OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a mapped range, the current behavior in debug build doesn't allow to flush its subrange if it doesn't touch the last byte of the range. The attached patch fixes that and changes u_uploadmgr for the mapped and flushed ranges to match. Please review. Other than that, it's stable as master. Thank you very much. -Marek From d351a37e320dcb027c43311dc620d44fdffa0a6d Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com Date: Sat, 3 Apr 2010 07:58:34 +0200 Subject: [PATCH] util: fix assertion failures in pipe_buffer_flush_mapped_range --- src/gallium/auxiliary/util/u_inlines.h|2 +- src/gallium/auxiliary/util/u_upload_mgr.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/util/u_inlines.h b/src/gallium/auxiliary/util/u_inlines.h index b1f2285..f9cd4e1 100644 --- a/src/gallium/auxiliary/util/u_inlines.h +++ b/src/gallium/auxiliary/util/u_inlines.h @@ -223,7 +223,7 @@ pipe_buffer_flush_mapped_range(struct pipe_context *pipe, assert(length); assert(transfer-box.x = offset); - assert(transfer-box.x + transfer-box.width = offset + length); + assert(offset + length = transfer-box.x + transfer-box.width); /* Match old screen-buffer_flush_mapped_range() behaviour, where * offset parameter is relative to the start of the buffer, not the diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c b/src/gallium/auxiliary/util/u_upload_mgr.c index f8c3954..75d4443 100644 --- a/src/gallium/auxiliary/util/u_upload_mgr.c +++ b/src/gallium/auxiliary/util/u_upload_mgr.c @@ -95,7 +95,7 @@ my_buffer_write(struct pipe_context *pipe, assert(dirty_size = size); assert(size); - map = pipe_buffer_map_range(pipe, buf, offset, size, + map = pipe_buffer_map_range(pipe, buf, offset, dirty_size, PIPE_TRANSFER_WRITE | PIPE_TRANSFER_FLUSH_EXPLICIT | PIPE_TRANSFER_DISCARD | -- 1.6.3.3 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resourceshttp://cgit.freedesktop.org/%7Emareko/mesa/log/?h=gallium-resources With this, r300g works again. Hmm, I think the second of the patches (flush range relative to mapped range vs whole buffer) may be addressing a regression that has creeped into the -resources branch regarding this behaviour - ie. I think the code you modified was actually correct, but that pipe_flush_mapped_buffer_range() has changed to do the wrong thing. I'll try and figure out what should be happening. I've pushed a change which hopefully corrects the behaviour of the buffer_range inlines. Can you give it a try? Now glean/bufferObject fails on softpipe and r300g. I haven't tested other drivers. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Gallium: ARB_half_float_vertex
Hi devs, I (and Luca mostly) have made some simple patches which add GL_ARB_half_float_vertex to Gallium. Author: Marek Olšák mar...@gmail.com r300g: enable half float vertex st/mesa: query for half float vertex support Author: Luca Barbieri l...@luca-barbieri.com st/mesa: half float vertex support Please review the commits here: http://cgit.freedesktop.org/~mareko/mesa/log/?h=half-float-vertexhttp://cgit.freedesktop.org/%7Emareko/mesa/log/?h=half-float-vertex Please let me know whether I may push this. Cheers -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex
On Sun, Apr 4, 2010 at 9:41 PM, Luca Barbieri luca.barbi...@gmail.comwrote: There was some talk about doing the query with a vertex buffer target for is_format_supported. Does it mean there will be format fallbacks? Because dword-unaligned but still pretty common (i.e. GL1.1) vertex formats aren't supported by r300, most often we hit R16G16B16. What will happen when is_format_supported says NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3, which every in-tree state tracker ignores. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium: ARB_half_float_vertex
On Sun, Apr 4, 2010 at 10:28 PM, Luca Barbieri luca.barbi...@gmail.comwrote: Does it mean there will be format fallbacks? Because dword-unaligned but still pretty common (i.e. GL1.1) vertex formats aren't supported by r300, most often we hit R16G16B16. What will happen when is_format_supported says NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3, which every in-tree state tracker ignores. I'm not sure I understand correctly what you are saying. The idea is to do like you did in your patch, but instead of calling screen-get_param(screen, PIPE_CAP_HALF_FLOAT_VERTEX), calling screen-is_format_supported(screen, PIPE_FORMAT_R16G16B16G16, PIPE_BUFFER, ..., ...). The PIPE_BUFFER target is supported in gallium-resources, but I'm not sure whether this way of querying vertex formats is supported; it would probably need to be added first. If you mean that r300 doesn't support R16G16B16, I suppose you can just use R16G16B16A16 and ignore the extra fetched w element (the vertex buffer stride will make this work properly). I've tried to do it this way, it locks up (unless I am missing something). However, if non-dword-aligned vertex buffer strides or vertex element offsets are not supported, I think you have a serious problem, which is however independent of half float vertices since I don't think OpenGL places any alignment constraints on those values (correct me if I'm wrong). You're right. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Gallium: EXT_gpu_program_parameters
Hi devs, this extensions is extensively used in Wine for obvious performance reasons and is quite popular in the GL community, therefore we should advertise it. All needed code seems to be already in mesa/main, so unless I overlooked something, the patch below is sufficient. Any comments, please? -Marek diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 0118c60..ae5e62b 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -183,6 +183,7 @@ void st_init_extensions(struct st_context *st) ctx-Extensions.EXT_framebuffer_object = GL_TRUE; ctx-Extensions.EXT_framebuffer_multisample = GL_TRUE; ctx-Extensions.EXT_fog_coord = GL_TRUE; + ctx-Extensions.EXT_gpu_program_parameters = GL_TRUE; ctx-Extensions.EXT_multi_draw_arrays = GL_TRUE; ctx-Extensions.EXT_pixel_buffer_object = GL_TRUE; ctx-Extensions.EXT_point_parameters = GL_TRUE; -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources With this, r300g works again. -Marek On Fri, Apr 2, 2010 at 4:17 PM, Roland Scheidegger srol...@vmware.comwrote: I'm planning on merging the gallium-resources branch shortly (after easter). Due to the amount of code changed, it wouldn't be unexpected if some drivers break here and there. So it would be nice if the respective driver authors could take a look at that branch now. If you've missed the discussion about this branch and what this is about, here it is: http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12726.html I've also removed the video interfaces completely, as they weren't ported to the interface changes and actually some of the video code missed some earlier interface changes so didn't build anyway. Video related work should be done on pipe-video branch which had newer stuff (for video) already. Roland -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler
On Sun, Apr 4, 2010 at 12:10 AM, Zack Rusin za...@vmware.com wrote: I thought the initial proposal was likely a lot more feasible for a GSOC (of course there one has to point out that Mesa's GLSL compiler already does unroll loops and in general simplifies control-flow so the points #1 and #2 are largely no-ops, but surely there's enough work on Gallium Radeon's drivers left to keep Tom busy). Otherwise having a well-defined and reduced scope with clear deliverables would be rather necessary for LLVM-TGSI code because that is not something that you could get rock solid over a summer. It doesn't seem to simplify branches or unroll loops that much, if at all. It fails even for the simplest cases like this one: if (gl_Vertex.x 30.0) gl_FrontColor = vec4(1.0, 0.0, 0.0, 0.0); else gl_FrontColor = vec4(0.0, 1.0, 0.0, 0.0); This gets translated to TGSI as is, which is fairly... you know what. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler
On Sat, Apr 3, 2010 at 9:31 AM, Tom Stellard tstel...@gmail.com wrote: 1. Enable branch emulation for Gallium drivers: The goal of this task will be to create an optional optimization pass over the TGSI code to translate branch instructions into instructions that are supported by cards without hardware branching. The basic strategy for doing this translation will be: A. Copy values of in scope variables to a temporary location before executing the conditional statement. B. Execute the if true branch. C. Test the conditional expression. If it evaluates to false, rollback all values that were modified in the if true branch. D. Repeat step 2 with the if false branch, and then step 3, but this time only rollback if the conditional expression evaluates to true. The TGSI instructions SLT, SNE, SGE, SEQ will be used to test the conditional expression and the instruction CND will be used to rollback the values. There will be two phases to this task. For phase 1, I will implement a simple translator that will be able to translate the branch instructions with only one pass through the TGSI code. This simple translator will copy all in scope variables to a temporary location before executing the conditional statement, even if those variables will not not be modified in either of the branches. Phase 2 will add a preliminary pass before to the code translation pass that will mark variables that might be modified by the conditional statement. Then, during the translation pass, only the variables that could potentially be modified inside either of the conditional branches will be copied before the conditional statement is executed. First I really appreciate you're looking into this. I'd like to propose something doable in GSoC timeframe. Since Nicolai has already implemented the branch emulation and some other optimizations, it would be nice to take over his work. I tried to use the branch emulation on vertex shaders and it did not work correctly, I guess it needs little fixing. See this branch in his repo: http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glslhttp://cgit.freedesktop.org/%7Enh/mesa/log/?h=r300g-glsl Especially this commit implements exactly what you propose (see comments in the code): http://cgit.freedesktop.org/~nh/mesa/commit/?h=r300g-glslid=71c8d4c745da23b0d4f3974353b19fad89818d7fhttp://cgit.freedesktop.org/%7Enh/mesa/commit/?h=r300g-glslid=71c8d4c745da23b0d4f3974353b19fad89818d7f Reusing this code for Gallium seems more reasonable to me than reinventing the wheel and doing basically the same thing elsewhere. I recommend implementing a TGSI backend in the r300 compiler, which will make possible using it with TGSI shaders. So basically a TGSI shader would be converted to the RC representation the way it's done in r300g right now, and code for converting RC - hw code would get replaced by conversion RC - TGSI. Both RC and TGSI are very similar so it'll be pretty straightforward. With a TGSI backend, another step would be to make a nice hw-independent and configurable interface on top of it which should go to util. So far it's simple, now comes some real work: fixing the branch emulation and continuing from (2) in your list. Then it'll be up to developers of other drivers whether they want to implement their own hw-specific optimization passes and lowering transformations. Even linking various shaders would be much easier done with the compiler (and more efficient with its elimination of dead-code due to removed shader outputs/inputs), this is used in classic r300 and I recall Luca wanted such a feature in nouveau drivers. There is also an emulation of shadow samplers, WPOS, and an emulation of various instructions, so this is a nice and handy tool. (I would do it but I have a lot of more important stuff to do.) This may really help Gallium drivers until a real optimization framework emerges. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler
On Sun, Apr 4, 2010 at 1:07 AM, Luca Barbieri luca.barbi...@gmail.comwrote: So basically the r300 optimization work looks doomed from the beginning to be eventually obsoleted. Please consider there are hw-specific optimizations in place which I think no other compiler framework provides, and I believe this SSA thing will do even better job for superscalar r600. So yes, we need both LLVM to do global optimizations and RC to efficiently map code to hw. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] RFC: GSOC Proposal: R300/Gallium GLSL Compiler
On Sun, Apr 4, 2010 at 6:14 AM, Tom Stellard tstel...@gmail.com wrote: On Sun, Apr 04, 2010 at 01:09:51AM +0200, Marek Olšák wrote: Since Nicolai has already implemented the branch emulation and some other optimizations, it would be nice to take over his work. I tried to use the branch emulation on vertex shaders and it did not work correctly, I guess it needs little fixing. See this branch in his repo: http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glslhttp://cgit.freedesktop.org/%7Enh/mesa/log/?h=r300g-glsl http://cgit.freedesktop.org/%7Enh/mesa/log/?h=r300g-glsl Especially this commit implements exactly what you propose (see comments in the code): http://cgit.freedesktop.org/~nh/mesa/commit/?h=r300g-glslid=71c8d4c745da23b0d4f3974353b19fad89818d7fhttp://cgit.freedesktop.org/%7Enh/mesa/commit/?h=r300g-glslid=71c8d4c745da23b0d4f3974353b19fad89818d7f http://cgit.freedesktop.org/%7Enh/mesa/commit/?h=r300g-glslid=71c8d4c745da23b0d4f3974353b19fad89818d7f Reusing this code for Gallium seems more reasonable to me than reinventing the wheel and doing basically the same thing elsewhere. I recommend implementing a TGSI backend in the r300 compiler, which will make possible using it with TGSI shaders. So basically a TGSI shader would be converted to the RC representation the way it's done in r300g right now, and code for converting RC - hw code would get replaced by conversion RC - TGSI. Both RC and TGSI are very similar so it'll be pretty straightforward. With a TGSI backend, another step would be to make a nice hw-independent and configurable interface on top of it which should go to util. So far it's simple, now comes some real work: fixing the branch emulation and continuing from (2) in your list. I am not sure if I follow you here, so let me know if I am understanding this correctly. What you are suggesting is to take Nicolai's branch, which right now does TGSI - RC - Branch Emulation in RC - hw code and instead of converting from RC to hw code convert from RC back into TGSI. That's right. Then, pull the TGSI - RC - Branch Emulation in RC - TGSI path out of the r300 compiler and place it in gallium/auxillary/util so it can be used by other Gallium drivers that want to emulate branches. Is this correct? Sorry I should have been more clear. The whole RC may stay in src/mesa/drivers/dri/r300/compiler as it is now. I think these are parts that should go to util: - TGSI - RC conversion - RC - TGSI conversion - Hw-independent interface to the compiler, i.e. one function (or more) which takes a TGSI shader and returns a TGSI shader. It should do both conversions above and use r300/compiler directly. In the long-term, the compiler should probably be moved to src/compiler or something like that (since both classic and gallium drivers may use it), but you don't need to care about that if you don't want to. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Tue, Mar 30, 2010 at 7:09 AM, Tom Stellard tstel...@gmail.com wrote: On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote: From the driver point of view, we don't have to work on the GLSL compiler itself. The Mesa state tracker compiles GLSL to an assembler-like language called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader representation. The more TGSI we handle, the more GLSL support we get. Is adding support for the TGSI opcodes that are currently ignored by r300_tgsi_to_rc.c something that needs to be done? If so, are there some opcodes you would prefer to see done first? One of the goals might be to pass all relevant piglit tests including glean/glsl1 which exercises various opcodes but it's not so important and I'd be surprised if you would make it in your timeframe. You may use it for testing though. So now the status. r300g GLSL is missing the following features: 1) Branching and looping This is the most important one and there are 3 things which need to be done. * Unrolling loops and converting conditionals to multiplications. This is crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases but should be fine for the most common ones. This is kind of a standard in all proprietary drivers supporting shaders 2.0. It would be nice have it work with pure TGSI shaders so that drivers like nvfx can reuse it too and I personally prefer to have this feature first before going on. Would you be able to provide a small example of how to convert the conditionals to multiplications? I understand the basic idea is to mask values based on the result of the conditional, but it would help me to see an example. On IRC, eosie mentioned an alternate technique for emulating conditionals: Save the values of variables that might be affected by the conditional statement. Then, after executing both the if and the else branches, roll back the variables that were affected by the branch that was not supposed to be taken. Would this technique work as well? Well, I am eosie, thanks for the info, it's always cool to be reminded what I've written on IRC. ;) Another idea was to convert TGSI to a SSA form. That would make unrolling branches much easier as the Phi function would basically become a linear interpolation, loops and subroutines with conditional return statements might be trickier. The r300 compiler already uses SSA for its optimization passes so maybe you wouldn't need to mess with TGSI that much... Is the conditional translation something that only needs to be done in the Gallium drivers, or would it be useful to apply the translation before the Mesa IR is converted into TGSI? Are any of the other drivers (Gallium or Mesa) currently doing this kind of translation? Not that I know of. You may do it wherever you want theoretically, even in the r300 compiler and leaving TGSI untouched, but I think most people would appreciate if these translation were done in TGSI. * Teaching the R300 compiler loops and conditionals for R500 fragment shaders. Note that R500 supports the jump instruction so besides adding new opcodes, the compiler optimization passes should be updated too (I think they haven't been designed with loops in mind). * The same but for R500 vertex shaders. The difference is conditionals must be implemented using predication opcodes and predication writes (stuff gets masked out). I think this only affects the conversion to machine code at the end of the pipeline. 2) Derivatives instructions fix It's implemented but broken. From docs: If src0 is computed in the previous instruction, then a NOP needs to be inserted between the two instructions. Do this by setting the NOP flag in the previous instruction. This is not required if the previous instruction is a texture lookup. .. and that should be the fix. Is the only problem here that NOP is being inserted after texture lookups when it shouldn't be? Well the derivatives don't work and NOP is not being inserted anywhere. The quoted statement from the docs was supposed to give you a clue. NOP after a texture lookup is *not required*, that means it would be just silly to put it there but it shouldn't break anything. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Tue, Mar 30, 2010 at 10:26 AM, Nicolai Haehnle nhaeh...@gmail.comwrote: On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák mar...@gmail.com wrote: Another idea was to convert TGSI to a SSA form. That would make unrolling branches much easier as the Phi function would basically become a linear interpolation, loops and subroutines with conditional return statements might be trickier. The r300 compiler already uses SSA for its optimization passes so maybe you wouldn't need to mess with TGSI that much... Note that my Git repository already contains an implementation of branch emulation and some additional optimizations, see here: http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glslhttp://cgit.freedesktop.org/%7Enh/mesa/log/?h=r300g-glsl Shame on me for abandoning it - I should really get around to make sure it fits in with recent changes and merge it to master. The main problem is that it produces somewhat inefficient code. Adding and improving peephole and similar optimizations should help tremendously. Well it's either this or nothing so I guess I am not the only one to prefer to get it merged. ;) However that kinda slightly changes Tom's plan for the GSoC project. On a different note, considering that the r300 compiler has basically 2 frontends (Mesa IR and TGSI) and 3 backends (r300 VS FS, r500 FS), would it be feasible to add yet another backend - TGSI? That would turn the compiler into a generic Gallium shader optimizer with the lowering tools it already has (or will have) and more people would be interested in adding new features and improvements in it. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] glsl: optimize sqrt
We were talking a bit on IRC that the GLSL compiler implements the sqrt
function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as is
in the original code, the proposed patch uses just rsq+mul. Please see the
patch log for further explanation, and please review.
-Marek
From 9b834a79a1819f3b4b9868be3e2696667791c83e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sat, 27 Mar 2010 13:49:09 +0100
Subject: [PATCH] glsl: optimize sqrt
The new version can be derived from sqrt as follows:
sqrt(x) =
sqrt(x)^2 / sqrt(x) =
x / sqrt(x) =
x * rsqrt(x)
Also the need for the CMP instruction is gone because there is no division
by zero.
---
.../shader/slang/library/slang_common_builtin.gc | 22 +++
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/src/mesa/shader/slang/library/slang_common_builtin.gc b/src/mesa/shader/slang/library/slang_common_builtin.gc
index a25ca55..3f6596c 100644
--- a/src/mesa/shader/slang/library/slang_common_builtin.gc
+++ b/src/mesa/shader/slang/library/slang_common_builtin.gc
@@ -602,50 +602,36 @@ vec4 exp2(const vec4 a)
float sqrt(const float x)
{
- const float nx = -x;
float r;
__asm float_rsq r, x;
- __asm float_rcp r, r;
- __asm vec4_cmp __retVal, nx, r, 0.0;
+ __retVal = r * x;
}
vec2 sqrt(const vec2 x)
{
- const vec2 nx = -x, zero = vec2(0.0);
vec2 r;
__asm float_rsq r.x, x.x;
__asm float_rsq r.y, x.y;
- __asm float_rcp r.x, r.x;
- __asm float_rcp r.y, r.y;
- __asm vec4_cmp __retVal, nx, r, zero;
+ __retVal = r * x;
}
vec3 sqrt(const vec3 x)
{
- const vec3 nx = -x, zero = vec3(0.0);
vec3 r;
__asm float_rsq r.x, x.x;
__asm float_rsq r.y, x.y;
__asm float_rsq r.z, x.z;
- __asm float_rcp r.x, r.x;
- __asm float_rcp r.y, r.y;
- __asm float_rcp r.z, r.z;
- __asm vec4_cmp __retVal, nx, r, zero;
+ __retVal = r * x;
}
vec4 sqrt(const vec4 x)
{
- const vec4 nx = -x, zero = vec4(0.0);
vec4 r;
__asm float_rsq r.x, x.x;
__asm float_rsq r.y, x.y;
__asm float_rsq r.z, x.z;
__asm float_rsq r.w, x.w;
- __asm float_rcp r.x, r.x;
- __asm float_rcp r.y, r.y;
- __asm float_rcp r.z, r.z;
- __asm float_rcp r.w, r.w;
- __asm vec4_cmp __retVal, nx, r, zero;
+ __retVal = r * x;
}
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Tue, Mar 23, 2010 at 8:46 PM, Tom Stellard tstel...@gmail.com wrote: On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote: On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard tstel...@gmail.com wrote: Thanks for the information. After spending some time learning about the Gallium driver architecture, I think it might be better to set a goal to implement or improve a specific feature of the Gallium R300 driver rather than trying to get a specific game or application to work. Is there a feature that is currently missing from the R300 driver that might make a good project for the summer? Good question. There's a handful of things. Passing piglit might be a good goal. Bumping the GL version further up, or solidifying the GLSL support, might be good too. I think the GLSL compiler would be an interesting project for me to work on. What is the current status of GLSL on R300 cards? From the driver point of view, we don't have to work on the GLSL compiler itself. The Mesa state tracker compiles GLSL to an assembler-like language called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader representation. The more TGSI we handle, the more GLSL support we get. So now the status. r300g GLSL is missing the following features: 1) Branching and looping This is the most important one and there are 3 things which need to be done. * Unrolling loops and converting conditionals to multiplications. This is crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases but should be fine for the most common ones. This is kind of a standard in all proprietary drivers supporting shaders 2.0. It would be nice have it work with pure TGSI shaders so that drivers like nvfx can reuse it too and I personally prefer to have this feature first before going on. * Teaching the R300 compiler loops and conditionals for R500 fragment shaders. Note that R500 supports the jump instruction so besides adding new opcodes, the compiler optimization passes should be updated too (I think they haven't been designed with loops in mind). * The same but for R500 vertex shaders. The difference is conditionals must be implemented using predication opcodes and predication writes (stuff gets masked out). I think this only affects the conversion to machine code at the end of the pipeline. 2) Derivatives instructions fix It's implemented but broken. From docs: If src0 is computed in the previous instruction, then a NOP needs to be inserted between the two instructions. Do this by setting the NOP flag in the previous instruction. This is not required if the previous instruction is a texture lookup. .. and that should be the fix. 3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing I think this is specific to the rasterizer (RS) block in hw ([3]). [1] src/gallium/drivers/r300/r300_tgsi_to_rc.c [2] src/mesa/drivers/dri/r300/compiler/ [3] src/gallium/drivers/r300/r300_state_derived.c Would something like passing a subset of the GLSL piglit tests, or being able to correctly handle a certain version of GLSL be a good goal for the summer? I guess this question is for Corbin. ;) -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] configure.ac: Bump LIBDRM_RADEON_REQUIRED to 2.4.19
Fixed in master without requiring new libdrm. -Marek On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek sedat.di...@googlemail.comwrote: Fixes here latest issues with mesa master GIT [1]. -- Sedat [1] http://marc.info/?l=mesa3d-devm=126934502904478w=2 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
I've updated the TODO list with the stuff from my private one, in case you guys think there are too few things to do. ;) http://dri.freedesktop.org/wiki/R300ToDo?action=diff -Marek On Tue, Mar 23, 2010 at 8:16 AM, Corbin Simpson mostawesomed...@gmail.comwrote: On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson mostawesomed...@gmail.com wrote: Good question. There's a handful of things. Passing piglit might be a good goal. Bumping the GL version further up, or solidifying the GLSL support, might be good too. Oh, and how could I forget this? We have a sizeable todo list: http://dri.freedesktop.org/wiki/R300ToDo ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h
Please do git pull --rebase origin instead of git pull origin to avoid Merge branch 'master' of ... commits. -Marek On Sun, Mar 21, 2010 at 2:40 PM, George Sapountzis gsapount...@gmail.comwrote: That was commit 9ec29e31919e85f9230867f43841c0e74be930d3 when doing a pristine build. I reverted it for now. On Sun, Mar 21, 2010 at 2:31 PM, STEVE555 stevenward...@hotmail.com wrote: Hi Chia-I Wu, I've just updated my copy of Mesa master today after your merge and the latest commits(from about 11:30 am GMT).I build Mesa with these configure options: ./configure --prefix=/usr --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096 --with-max-height=4096 --enable-debug. I've used both gmake and make after ./configure,and Mesa keeps hitting this error when it tries to build the svga state-tracker: gmake[4]: Entering directory `/opt/mesa/src/gallium/drivers/svga' rm -f depend touch depend /usr/bin/makedepend -fdepend -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/gallium/drivers/svga/include -std=gnu99 -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H svgadump/svga_shader_dump.c svgadump/svga_shader_op.c svgadump/svga_dump.c svga_cmd.c svga_context.c svga_draw.c svga_draw_arrays.c svga_draw_elements.c svga_pipe_blend.c svga_pipe_blit.c svga_pipe_clear.c svga_pipe_constants.c svga_pipe_depthstencil.c svga_pipe_draw.c svga_pipe_flush.c svga_pipe_fs.c svga_pipe_misc.c svga_pipe_query.c svga_pipe_rasterizer.c svga_pipe_sampler.c svga_pipe_vertex.c svga_pipe_vs.c svga_screen.c svga_screen_buffer.c svga_screen_texture.c svga_screen_cache.c svga_state.c svga_state_need_swtnl.c svga_state_constants.c svga_state_framebuffer.c svga_state_rss.c svga_state_tss.c svga_state_vdecl.c svga_state_fs.c svga_state_vs.c svga_swtnl_backend.c svga_swtnl_draw.c svga_swtnl_state.c svga_tgsi.c svga_tgsi_decl_sm20.c svga_tgsi_decl_sm30.c svga_tgsi_insn.c2 /dev/null gmake[4]: *** No rule to make target `depend', needed by `default'. Stop. gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/svga' gmake[3]: *** [default] Error 1 gmake[3]: Leaving directory `/opt/mesa/src/gallium/drivers' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/opt/mesa/src/gallium' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/opt/mesa/src' make: *** [default] Error 1 Regards, STEVE555 Sedat Dilek wrote: On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu olva...@gmail.com wrote: On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek sedat.di...@googlemail.com wrote: [...] Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps (master GIT incl. gallium-st-api-dri merge) $ cat oa_benchmark.txt s...@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 21 | egrep -e '[0-9]+ frames' 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms Thanks for your work! Unless I have some magic power that I am not aware of, the boost should be attributed to r300g developers. I think, it is helpful to benchmark from time to time. I was comparing the both branches 7.8 and 7.9-devel in general and especiall r300g dri/st. Indeed, Chapeau to all contributors to r300g development. -- Sedat -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- View this message in context: http://old.nabble.com/New-branch-to-switch-st-dri-to-st_api.h-tp27940955p27975796.html Sent from the mesa3d-dev mailing list archive at Nabble.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT
On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek sedat.di...@googlemail.comwrote: Hi, the last days I was testing Alex Deucher's power-management-2 patches for radeon OSS driver. While testing I saw that especially r300g dri/statetracker with OpenArena have problems with mesa 7.8/master GIT branch. Mesa r300 classic (KMS/DRI2) is working fine here on RV515. 7.8 GIT: Scenes have a red-ish background. There should be a fix in master. But I can't remember when and which patch fixed it, but Dave Airlied noticed the same color corruptions. Apply this one from master: 821c830f11fc1c3529a186ace1d1ba3ddeab4957http://cgit.freedesktop.org/mesa/mesa/commit/?id=821c830f11fc1c3529a186ace1d1ba3ddeab4957 If it helps, someone could cherry-pick the commit to the 7.8 branch. master GIT (merged gallium-st-api-dri into it): Some objects in the scene are not displayed with correct colors - objects look/have like turquoise and black triangles. What levels have this issue? How can I reproduce it? There is a breakage with Dave's screen/winsys rework ( 68e58a96e80865878e6881dc4d34fcc3ec24eb19http://cgit.freedesktop.org/mesa/mesa/commit/?id=68e58a96e80865878e6881dc4d34fcc3ec24eb19), especially in these piglit tests: cubemap, gen-teximage, levelclamp, lodclamp, texredefine. Could you please check if the incorrect rendering in openarena has anything to do with the rework? -Marek commit 8e1768cfd32a4fa47dd5d4e8f5434fafc3b3120 gallium/docs: Fix a couple ReST errors. I played a bit with glxinfo (output see file-attachment): $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa glxinfo glxinfo.txt The log of OA got big (dunno if you are interested in): $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa openarena 2openarena.log Any hints for digging deeper into this? Kind Regards, - Sedat - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?
On Thu, Mar 11, 2010 at 4:41 PM, Luca Barbieri l...@luca-barbieri.comwrote: I've looked into the issue, and found a workaround by looking at what st_renderbuffer_alloc_storage (which is called to create the depth buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does. Adding: if(ctx) ctx-NewState |= _NEW_BUFFERS; at the end of st_set_framebuffer_surface seems to solve the warsow problem with no other regressions. Brian, is this the right fix? Marek, does it fix your r300g problems too? Mesa master merged with 7.8 fixes all the glean regressions. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] util_format cleanup leftover: Gallium BGRA vertex swizzles
Please see this commit: http://cgit.freedesktop.org/~mareko/mesa/commit/?id=177a4432aa88fc68d83895ae71b7ad2c86a1e7e3 Subject: [PATCH] gallium: fix BGRA vertex color swizzles The mapping for vertex_array_bgra: (gl - st - translate) GL_RGBA - PIPE_FORMAT_R8G8B8A8 (RGBA) - no swizzle (XYZW) GL_BGRA - PIPE_FORMAT_A8R8G8B8 (ARGB) - ZYXW (BGRA again??) Iẗ́'s pretty clear that PIPE_FORMAT_A8R8G8B8 here is wrong. This commit fixes the pipe format and removes obvious workarounds in util/translate. Tested with: softpipe, llvmpipe, r300g. Please review. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?
I second that. The commit breaks 6 glean tests (api2, clipFlat, fragProg1, occluQry, pointAtten, texCombine4) with r300g. -Marek On Wed, Mar 10, 2010 at 10:50 PM, Luca Barbieri l...@luca-barbieri.comwrote: In mesa_7_7_branch, 52d83efdbc4735d721e6fc9b44f29bdd432d4d73 reverts commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd. How about cherry-picking that commit into master, until a fix for the bugs the revert commit introduces are found? The reverted commit currently breaks the Warsow main menu for me, making it show garbage. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] dri-extension branch - clean up advertising extensions in Gallium
Alright, I will add driInitExtensions(ctx, NULL, TRUE) at the end of st_init_extensions. Anything else I missed or is it OK? -Marek On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger srol...@vmware.comwrote: On 08.03.2010 14:22, Joakim Sindholt wrote: On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote: On 07.03.2010 20:26, Marek Olšák wrote: This branch is aimed to address the following issues: * Extensions are advertised in both st/mesa and st/dri, doing the same thing in two places. * The inability to disable extensions in pipe_screen::get_param because st/dri overrides the decisions of st/mesa. Here's the branch: http://cgit.freedesktop.org/~mareko/mesa/log/?h=dri-extensionshttp://cgit.freedesktop.org/%7Emareko/mesa/log/?h=dri-extensions The first commit moves the differences between st/dri and st/mesa to the latter and removes dri_init_extensions from st/dri. It doesn't remove any extensions from the list except for those not advertised by pipe_screen. The second commit enables texture_rectangle by default in Gallium. To my knowledge any Gallium hardware can do this and I suspect it was dependent on NPOT textures by accident. All this is of course tested with piglit and glean. Please review. In case it's not OK, please let me know what needs to be done. The second commit looks fine to me. The first one, I'm not sure. Maybe that's ok, but if so I'm wondering why, since this skips all the mapping business driInitExtensions did and just sets the extension enable bits to true. At least I'm fairly sure it was needed in the past... Roland I believe airlied pointed out earlier that http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72fixed that problem. But even with that commit, all drivers still call driInitExtensions at least once, though the parameter list can be NULL. I don't see that happening here. Roland -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r300g color bug with VBO
Yes, this is a known issue. The problem is that GL_RGBA and GL_BGRA map to PIPE_FORMAT_R8G8B8A8 (RGBA) and PIPE_FORMAT_A8R8G8B8 (ARGB), respectively, which is wrong. The attached patch fixes it for r300g but breaks other drivers which depend on Draw (softpipe, llvmpipe). The reason is that Draw seems to interpret A8R8G8B8 as BGRA, clearly hiding the bug. The possibilites are: - implement the same hack in r300g - fix Draw (I'd prefer this one) I hope I'll find some time this week to resolve this issue if no one else do it. -Marek On Tue, Mar 9, 2010 at 1:29 AM, Tom t...@riseup.net wrote: Hi people, With the r300g driver (git ~today) drawing tris with color pointer like so: glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(struct vtx_data), blah); Seems to invert the RGBA - ABGR. This short program shows the bug. It should display a yellow tri, and instead on r300g it shows a blue tri. http://tom.noflag.org.uk/misc/r300g_color_bug.c Not sure if you want user bug reports of this kind yet, but anyway... -- Tom -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c index 32b9a47..4b48c16 100644 --- a/src/mesa/state_tracker/st_draw.c +++ b/src/mesa/state_tracker/st_draw.c @@ -183,7 +183,7 @@ st_pipe_vertex_format(GLenum type, GLuint size, GLenum format, /* this is an odd-ball case */ assert(type == GL_UNSIGNED_BYTE); assert(normalized); - return PIPE_FORMAT_A8R8G8B8_UNORM; + return PIPE_FORMAT_B8G8R8A8_UNORM; } -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r300g color bug with VBO
Also I've fixed GL_RGBA in master so now only GL_BGRA remains unresolved... On Tue, Mar 9, 2010 at 1:29 AM, Tom t...@riseup.net wrote: Hi people, With the r300g driver (git ~today) drawing tris with color pointer like so: glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(struct vtx_data), blah); Seems to invert the RGBA - ABGR. This short program shows the bug. It should display a yellow tri, and instead on r300g it shows a blue tri. http://tom.noflag.org.uk/misc/r300g_color_bug.c Not sure if you want user bug reports of this kind yet, but anyway... -- Tom -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] dri-extension branch - clean up advertising extensions in Gallium
This branch is aimed to address the following issues: * Extensions are advertised in both st/mesa and st/dri, doing the same thing in two places. * The inability to disable extensions in pipe_screen::get_param because st/dri overrides the decisions of st/mesa. Here's the branch: http://cgit.freedesktop.org/~mareko/mesa/log/?h=dri-extensions The first commit moves the differences between st/dri and st/mesa to the latter and removes dri_init_extensions from st/dri. It doesn't remove any extensions from the list except for those not advertised by pipe_screen. The second commit enables texture_rectangle by default in Gallium. To my knowledge any Gallium hardware can do this and I suspect it was dependent on NPOT textures by accident. All this is of course tested with piglit and glean. Please review. In case it's not OK, please let me know what needs to be done. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.
The attached patches change softpipe and llvmpipe so that they never provoke
the first vertex for quads. Please review. I think that these and the
Corbin's one could be pushed by now, couldn't they?
-Marek
On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul bri...@vmware.com wrote:
Corbin Simpson wrote:
From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001
From: Corbin Simpson mostawesomed...@gmail.com
Date: Wed, 10 Feb 2010 10:39:18 -0800
Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking
vertex.
Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out
how to test it in this new API world. :T
---
src/mesa/state_tracker/st_extensions.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index d5f5854..e2d871b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st)
/* XXX separate query for early function return? */
st-ctx-Shader.EmitContReturn =
screen-get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED);
+
+ /* Quads always follow GL provoking rules. */
+ c-QuadsFollowProvokingVertexConvention = GL_FALSE;
}
This causes the glean clipFlat test to fail with softpipe. The
gallium softpipe driver _does_ implement the quad follows provoking
vertex convention.
I don't have time right now to update the softpipe driver so this
patch will have to wait a while. Maybe someone else can look at it
sooner.
-Brian
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
From 861dd9a4e5d2fc3e0892d76d8f0ac929e186a88a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sun, 7 Mar 2010 04:54:43 +0100
Subject: [PATCH 1/2] llvmpipe: do not follow the provoking vertex convention for quads
---
src/gallium/drivers/llvmpipe/lp_setup_vbuf.c | 129 +++--
1 files changed, 36 insertions(+), 93 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
index 24291da..671e744 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
@@ -231,57 +231,29 @@ lp_setup_draw(struct vbuf_render *vbr, const ushort *indices, uint nr)
break;
case PIPE_PRIM_QUADS:
- if (setup-flatshade_first) {
- for (i = 3; i nr; i += 4) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-3], stride) );
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-0], stride),
- get_vert(vertex_buffer, indices[i-3], stride) );
- }
- }
- else {
- for (i = 3; i nr; i += 4) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-3], stride),
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-0], stride) );
+ for (i = 3; i nr; i += 4) {
+ setup-triangle( setup,
+ get_vert(vertex_buffer, indices[i-3], stride),
+ get_vert(vertex_buffer, indices[i-2], stride),
+ get_vert(vertex_buffer, indices[i-0], stride) );
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-0], stride) );
- }
+ setup-triangle( setup,
+ get_vert(vertex_buffer, indices[i-2], stride),
+ get_vert(vertex_buffer, indices[i-1], stride),
+ get_vert(vertex_buffer, indices[i-0], stride) );
}
break;
case PIPE_PRIM_QUAD_STRIP:
- if (setup-flatshade_first) {
- for (i = 3; i nr; i += 2) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-0], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
-
Re: [Mesa3d-dev] Mesa (master): mesa: Export GL_EXT_texture_cube_map.
I can see this extension in ATI Catalyst 9.3. -Marek On Sat, Mar 6, 2010 at 1:16 AM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jose Fonseca wrote: Module: Mesa Branch: master Commit: 744994a9c6b972a737e432cf1b699f232e2c5bfd URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=744994a9c6b972a737e432cf1b699f232e2c5bfd Author: José Fonseca jfons...@vmware.com Date: Sat Feb 13 15:10:24 2010 + mesa: Export GL_EXT_texture_cube_map. Still used by some applications. Holy smokes. Just out of curiosity, which applications? I didn't think anyone ever actually shipped this extension. I guess Nvidia might have.. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRnucACgkQX1gOwKyEAw/IDwCcCTnVTTHB2QOLZbDEVZmniYq/ mHkAmwaXt1ZzjGigifaqdyhkzf3/fxQ8 =umX/ -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Does DX9 SM3 - VMware svga with arbitrary semantics work? How?
On Tue, Mar 2, 2010 at 10:20 PM, Luca Barbieri l...@luca-barbieri.comwrote: On Tue, Mar 2, 2010 at 10:00 PM, Corbin Simpson mostawesomed...@gmail.com wrote: FYI r300 only supports 24 interpolators: 16 linear and 8 perspective. (IIRC; not in front of the docs right now.) r600 supports 256 fully configurable interpolators. Yes, but if you raised ATTR_GENERIC_COUNT, the current driver would support higher semantic indices right? (of course, with a limit of 8/24 different semantic indices used at once). That's right. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse gli...@freedesktop.orgwrote: On Mon, Mar 01, 2010 at 12:24:19PM +, Keith Whitwell wrote: On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote: On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote: On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote: On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote: On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote: Hi, I am a bit puzzled, how a pipe driver should handle draw callback failure ? On radeon (pretty sure nouveau or intel hit the same issue) we can only know when one of the draw_* context callback is call if we can do the rendering or not. The failure here is dictated by memory constraint, ie if user bind big texture, big vbo ... we might not have enough GPU address space to bind all the desired object (even for drawing a single triangle) ? What should we do ? None of the draw callback can return a value ? Maybe for a GL stack tracker we should report GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line is i think pipe driver are missing something here. Any idea ? Thought ? Is there already a plan to address that ? :) Gallium draw calls had return codes before. They were used for the fallover driver IIRC and were recently deleted. Either we put the return codes back, or we add a new pipe_context::validate() that would ensure that all necessary conditions to draw successfully are met. Putting return codes on bind time won't work, because one can't set all atoms simultaneously -- atoms are set one by one, so when one's setting the state there are state combinations which may exceed the available resources but that are never drawn with. E.g. you have a huge VB you finished drawing, and then you switch to drawing with a small VB with a huge texture, but in between it may happen that you have both bound simultaneously. If ignoring is not an alternative, then I'd prefer a validate call. Whether to fallback to software or not -- it seems to me it's really a problem that must be decided case by case. Drivers are supposed to be useful -- if hardware is so limited that it can't do anything useful then falling back to software is sensible. I don't think that a driver should support every imaginable thing -- apps should check errors, and users should ensure they have enough hardware resources for the workloads they want. Personally I think state trackers shouldn't emulate anything with CPU beyond unsupported pixel formats. If a hardware is so limited that in need CPU assistence this should taken care transparently by the pipe driver. Nevertheless we can and should provide auxiliary libraries like draw to simplify the pipe driver implementation. My opinion on this is similar: the pipe driver is responsible for getting the rendering done. If it needs to pull in a fallback module to achieve that, it is the pipe driver's responsibility to do so. Understanding the limitations of hardware and the best ways to work around those limitations is really something that the driver itself is best positioned to handle. The slight quirk of OpenGL is that there are some conditions where theoretically the driver is allowed to throw an OUT_OF_MEMORY error (or similar) and not render. This option isn't really available to gallium drivers, mainly because we don't know inside gallium whether the API permits this. Unfortunately, even in OpenGL, very few applications actually check the error conditions, or do anything sensible when they fail. I don't really like the idea of pipe drivers being able to fail render calls, as it means that every state tracker and every bit of utility code that issues a pipe-draw() call will have to check the return code and hook in fallback code on failure. One interesting thing would be to consider creating a layer that exposes a pipe_context interface to the state tracker, but revives some of the failover ideas internally - maybe as a first step just lifting the draw module usage up to a layer above the actual hardware driver. Keith So you don't like the pipe_context::validate() of Jose ? My taste goes to the pipe_context::validate() and having state tracker setting the proper flag according to the API they support (GL_OUT_OF_MEMORY for GL), this means just drop rendering command that we can't do. I think it's useful as a method for implementing GL_OUT_OF_MEMORY, but the pipe driver should: a) not rely on validate() being called - ie it is
Re: [Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge
Hi Michal, This branch breaks 2 piglit tests with r300g: depthrange-clear texdepth However I haven't investigated these and won't get to them until the weekend. I personally don't mind fixing the regressions after the merge (but I'm not the maintainer of r300g). Anyway I'm glad to see bypass_vs_clip_and_viewport dying. -Marek On Mon, Mar 1, 2010 at 5:08 PM, michal mic...@vmware.com wrote: Hi, This branch removes bypass_vs_clip_and_viewport flag from pipe rasterizer state. The benefits of having this bit around were dubious for everybody and burdensome for driver writers. All the utility code that relied on this flag have been rewritten to pass vertex positions in clip space and set clip and viewport state. I would like to ask the maintainers of u_blitter module to please test my changes and provide feedback. Please review. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge
Ahhh, I am a bad liar. The attached patch fixes the regressions. -Marek On Tue, Mar 2, 2010 at 2:08 AM, Marek Olšák mar...@gmail.com wrote: Hi Michal, This branch breaks 2 piglit tests with r300g: depthrange-clear texdepth However I haven't investigated these and won't get to them until the weekend. I personally don't mind fixing the regressions after the merge (but I'm not the maintainer of r300g). Anyway I'm glad to see bypass_vs_clip_and_viewport dying. -Marek On Mon, Mar 1, 2010 at 5:08 PM, michal mic...@vmware.com wrote: Hi, This branch removes bypass_vs_clip_and_viewport flag from pipe rasterizer state. The benefits of having this bit around were dubious for everybody and burdensome for driver writers. All the utility code that relied on this flag have been rewritten to pass vertex positions in clip space and set clip and viewport state. I would like to ask the maintainers of u_blitter module to please test my changes and provide feedback. Please review. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev From fe8c9e902b3cb6392979aeecf03b17d303210eba Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com Date: Tue, 2 Mar 2010 02:37:45 +0100 Subject: [PATCH] util/blitter: Fix the viewport transformation for Z coordinates When clearing buffers, the depth is specified in the range [0, 1] and should be passed through blitter as is. --- src/gallium/auxiliary/util/u_blitter.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/util/u_blitter.c b/src/gallium/auxiliary/util/u_blitter.c index f93c69d..0ba09d3 100644 --- a/src/gallium/auxiliary/util/u_blitter.c +++ b/src/gallium/auxiliary/util/u_blitter.c @@ -320,11 +320,11 @@ static void blitter_set_rectangle(struct blitter_context_priv *ctx, /* viewport */ ctx-viewport.scale[0] = 0.5f * width; ctx-viewport.scale[1] = 0.5f * height; - ctx-viewport.scale[2] = 0.5f; + ctx-viewport.scale[2] = 1.0f; ctx-viewport.scale[3] = 1.0f; ctx-viewport.translate[0] = 0.5f * width; ctx-viewport.translate[1] = 0.5f * height; - ctx-viewport.translate[2] = 0.5f; + ctx-viewport.translate[2] = 0.0f; ctx-viewport.translate[3] = 0.0f; ctx-pipe-set_viewport_state(ctx-pipe, ctx-viewport); -- 1.6.3.3 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300/compiler: Assert that array index is not negative.
We actually hit this assertion when we get:
FRAG
DCL IN[0], COLOR, PERSPECTIVE
0: END
See piglit/glsl-bug-22603.
-Marek
On Fri, Feb 26, 2010 at 10:18 AM, Corbin Simpson
mostawesomed...@gmail.comwrote:
Module: Mesa
Branch: master
Commit: e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
Author: Vinson Lee vlee at vmware.com
Date: Fri Feb 26 00:17:03 2010 -0800
r300/compiler: Assert that array index is not negative.
---
.../drivers/dri/r300/compiler/r500_fragprog_emit.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
index 829f028..710cae7 100644
--- a/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
+++ b/src/mesa/drivers/dri/r300/compiler/r500_fragprog_emit.c
@@ -469,6 +469,8 @@ void r500BuildFragmentProgramHwCode(struct
r300_fragment_program_compiler *compi
if (compiler-Base.Error)
return;
+ assert(code-inst_end = 0);
+
if ((code-inst[code-inst_end].inst0 R500_INST_TYPE_MASK) !=
R500_INST_TYPE_OUT) {
/* This may happen when dead-code elimination is disabled or
* when most of the fragment program logic is leading to a KIL */
Sorry, is this actually a problem? If this assertion is actually being
hit, it sure would be nice to hear about it since it. Empty shaders
shouldn't just be handled with debugging code.
--
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
Corbin Simpson
mostawesomed...@gmail.com
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] st/mesa: do not advertise S3TC if the external lib is not available
Hi,
S3TC shouldn't be advertised without the external lib and the attached patch
fixes that. Please review.
-Marek
From 94c58ff449b3818a378ad4ab5787151bc0a9ea6f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sat, 27 Feb 2010 03:20:58 +0100
Subject: [PATCH] st/mesa: do not advertise S3TC if the external lib is not available
---
src/mesa/state_tracker/st_extensions.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
index d5f5854..7b720b3 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -298,7 +298,8 @@ void st_init_extensions(struct st_context *st)
}
/* s3tc support */
- if (screen-is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA,
+ if (ctx-Mesa_DXTn
+ screen-is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA,
PIPE_TEXTURE_2D,
PIPE_TEXTURE_USAGE_SAMPLER, 0)) {
ctx-Extensions.EXT_texture_compression_s3tc = GL_TRUE;
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] st/mesa: do not advertise S3TC if the external lib is not available
OK thanks, I pushed what you suggested. -Marek On Sat, Feb 27, 2010 at 9:44 PM, José Fonseca jfons...@vmware.com wrote: On Sat, 2010-02-27 at 09:15 -0800, Marek Olšák wrote: Hi, S3TC shouldn't be advertised without the external lib and the attached patch fixes that. Please review. Hi Marek, Actually it is a bit more subtle. S3TC can and should be advertised if the pipe driver supports ST3C decompression and *compression*. No real hardware has circuitry for S3TC compression, granted. But the vwmare svga gallium driver does it, by deferring everything to the host. It was the best solution we found to supporting S3TC without having to rely on closed source or questionable bits in the guest. So the right fix should be: screen-is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA, PIPE_TEXTURE_2D, PIPE_TEXTURE_USAGE_SAMPLER, 0) (ctx-Mesa_DXTn || screen-is_format_supported(screen, PIPE_FORMAT_DXT5_RGBA, PIPE_TEXTURE_2D, PIPE_TEXTURE_USAGE_RENDERTARGET, 0) Jose -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default
On Tue, Feb 23, 2010 at 2:49 AM, Marek Olšák mar...@gmail.com wrote: On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul brian.e.p...@gmail.comwrote: On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, the attached patch modifies st/dri to not enable EXT_draw_buffers2 by default because r300g and most probably even some other drivers can't support this extension. The drivers reporting support of PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch. Please review. Hmm, I believe the extensions listed in dri_extensions.c are those that _may_ be supported by drivers. But its the st_extensions.c code that queries the driver for various caps (such as PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if applicable. I stand corrected. I was actually right the first time. The list in dri_extensions.c is being advertised *regardless* of what a driver reports (tested and debugged). None of the extensions on the list can be disabled using pipe_screen::get_param, making the majority of feature caps useless. However, I can enable/disable any extension which is *not* on the list using appropriate caps (if they exist). -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium format swizzles (Was: util: fix swizzles in the format table for 8-bits-per-channel formats)
I am basically ok with anything that would let me correctly convert the
format description into hardware-specific bits with *no* workarounds (for
both vertex data and samplers).
On Tue, Feb 23, 2010 at 6:20 PM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
Hi José,
the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since r300g started supporting pretty much every
texture format except SCALED ones, a few regressions have showed up.
This patch resolves all issues I had, especially with the SRGB formats
but I decided to clean it up all. git log:
util: fix swizzles in the format table for 8-bits-per-channel
formats
The 8-bits-per-channel formats having the same channel order had
completely
different swizzles, and at the same time, the same swizzles were
used for
completely different channel orders of 8bpc formats.
This made the whole table self-contradicting, caused headaches,
and last
but not least, incorrent rendering for the drivers relying on
these swizzles.
I hope I got it right. I didn't make a special distinction between the
array and arith layouts. All I did was to make sure that if I grep
e.g. A8R8G8B8, I'll get the same swizzles and not entirely different
ones.
Hi Marek,
I'll need a bit more time to investigate this.
One problem is that the interpretation of the swizzle varies with array
vs arith. The ordering for array is the lowest significant word to the
highest significant word (where word for 8bit formats is a byte), where
for arith it goes from least significant bit to the highest significant
bit. This is the same difference as array indexation and bit shifts.
There is also the problem of byte order which affects the bit shift
interpretation...
I admit thet the current format description table is terribly
underdocumented/confusing and likely broken in several ways. I wrote it
to be able to code generate pixel format translation (which is wroking
reasonably) and never expected people to use it for hardware drivers as
well, although it is perfectly legitimate use.
I have my own interpretation of these concepts, you and others hw driver
writers have their own different interpretation. Furthermore in
draw/translate/util modules there are some inconsistencies in these
interpretations too. So I need to read the GL and DX10 specs very well,
see how current drivers are using the descriptions, and come up with
something that makes sense for everybody.
So please hold on to your patch for a couple of days.
I'd appreciate if the interested parties could take a good look to
u_format.h comments, and summarize what they think the format semantics
should be.
Jose
There are two inconsistencies in formats ATM:
a) the notation used in PIPE_FORMAT_xxx, and
b) the values in util_format_description::swizzles .
There's a D3D9 - D3D10 format conversion table in
http://msdn.microsoft.com/en-us/library/ee415668(VS.85).aspx#Porting_Contenthttp://msdn.microsoft.com/en-us/library/ee415668%28VS.85%29.aspx#Porting_Content
and D3D9 - GL format table in
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/utils.c;hb=HEAD.
D3D10 dropped all arithmetically encoded formats, and inverted the
swizzle notation (e.g., D3DFMT_A2B10G10R10 and DXGI_FORMAT_R10G10B10A2
are equivalent).
Gallium has to represent both kinds and mixes both notations (the
MSB-LSB notation traditionally used for texture formats, the LSB-MSB
for vertex declarations). So instead of the current inconsistencies,
both on p_format.h and u_format.csv, I suggest we all normalize on one
notation, lets say MSB-LSB for pixel/vertex formats.
For example, the vertex format
struct vertex {
float x;
float y;
};
should be described the format PIPE_FORMAT_G32R32_FLOAT (not the current
PIPE_FORMAT_R32G32_FLOAT), which is equivalent:
- D3D9's D3DFMT_G32R32F texture format
- D3D9's D3DDECLTYPE_FLOAT2 vertex declaration type
- D3D10's DXGI_FORMAT_R32G32_FLOAT
- OpenGL's GL_RG32F format
- OpenGL's glVertexAttrib2f attribute
- OpenGL's glVertexPointer(2, GL_FLOAT, 0, 0);
- etc.
For the util_format_description::swizzles I suggest we always refer the
swizzles from LSB-MSB.
Leaving the interface change aside for now (Keith is away this week),
unless somebody has a better suggestion I'll update at least the meaning
of util_format_description::swizzles and u_format.csv to be consistent
with this.
Does everybody agree this is a sensible thing to do?
Jose
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed
Re: [Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default
On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul brian.e.p...@gmail.com wrote: On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote: Hi, the attached patch modifies st/dri to not enable EXT_draw_buffers2 by default because r300g and most probably even some other drivers can't support this extension. The drivers reporting support of PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch. Please review. Hmm, I believe the extensions listed in dri_extensions.c are those that _may_ be supported by drivers. But its the st_extensions.c code that queries the driver for various caps (such as PIPE_CAP_INDEP_BLEND_ENABLE) and then turns on the extension if applicable. I stand corrected. Is GL_EXT_draw_buffers2 really being advertised by glxinfo with r300g? Unfortunately yes, it is. -Marek -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] util: fix swizzles in the format table for 8-bits-per-channel formats
Hi José, the attached patch fixes incorrect swizzles in u_format.csv. There are basically just 2 drivers which depend on the swizzles in this table: llvmpipe and r300g. Since r300g started supporting pretty much every texture format except SCALED ones, a few regressions have showed up. This patch resolves all issues I had, especially with the SRGB formats but I decided to clean it up all. git log: util: fix swizzles in the format table for 8-bits-per-channel formats The 8-bits-per-channel formats having the same channel order had completely different swizzles, and at the same time, the same swizzles were used for completely different channel orders of 8bpc formats. This made the whole table self-contradicting, caused headaches, and last but not least, incorrent rendering for the drivers relying on these swizzles. I hope I got it right. I didn't make a special distinction between the array and arith layouts. All I did was to make sure that if I grep e.g. A8R8G8B8, I'll get the same swizzles and not entirely different ones. Please review. Best regards Marek From 53b1acea3cd5386d1f81a186f959d32b25c62f42 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com Date: Sat, 20 Feb 2010 18:36:16 +0100 Subject: [PATCH 1/2] util: fix swizzles in the format table for 8-bits-per-channel formats The 8-bits-per-channel formats having the same channel order had completely different swizzles, and at the same time, the same swizzles were used for completely different channel orders of 8bpc formats. This made the whole table self-contradicting, caused headaches, and last but not least, incorrent rendering for the drivers relying on these swizzles. --- src/gallium/auxiliary/util/u_format.csv | 44 +++--- 1 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/gallium/auxiliary/util/u_format.csv b/src/gallium/auxiliary/util/u_format.csv index 01f7931..6139e16 100644 --- a/src/gallium/auxiliary/util/u_format.csv +++ b/src/gallium/auxiliary/util/u_format.csv @@ -67,37 +67,37 @@ PIPE_FORMAT_R8G8B8_UNORM , array , 1, 1, un8 , un8 , un8 , , zyx1, PIPE_FORMAT_R8G8B8A8_UNORM, array , 1, 1, un8 , un8 , un8 , un8 , wzyx, rgb PIPE_FORMAT_R8G8B8X8_UNORM, array , 1, 1, un8 , un8 , un8 , un8 , wzy1, rgb PIPE_FORMAT_R8_USCALED, array , 1, 1, u8 , , , , x001, rgb -PIPE_FORMAT_R8G8_USCALED , array , 1, 1, u8 , u8 , , , xy01, rgb -PIPE_FORMAT_R8G8B8_USCALED, array , 1, 1, u8 , u8 , u8 , , xyz1, rgb -PIPE_FORMAT_R8G8B8A8_USCALED , array , 1, 1, u8 , u8 , u8 , u8 , xyzw, rgb -PIPE_FORMAT_R8G8B8X8_USCALED , array , 1, 1, u8 , u8 , u8 , u8 , xyz1, rgb +PIPE_FORMAT_R8G8_USCALED , array , 1, 1, u8 , u8 , , , yx01, rgb +PIPE_FORMAT_R8G8B8_USCALED, array , 1, 1, u8 , u8 , u8 , , zyx1, rgb +PIPE_FORMAT_R8G8B8A8_USCALED , array , 1, 1, u8 , u8 , u8 , u8 , wzyx, rgb +PIPE_FORMAT_R8G8B8X8_USCALED , array , 1, 1, u8 , u8 , u8 , u8 , wzy1, rgb PIPE_FORMAT_R8_SNORM , array , 1, 1, sn8 , , , , x001, rgb -PIPE_FORMAT_R8G8_SNORM, array , 1, 1, sn8 , sn8 , , , xy01, rgb -PIPE_FORMAT_R8G8B8_SNORM , array , 1, 1, sn8 , sn8 , sn8 , , xyz1, rgb -PIPE_FORMAT_R8G8B8A8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , xyzw, rgb -PIPE_FORMAT_R8G8B8X8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , xyz1, rgb +PIPE_FORMAT_R8G8_SNORM, array , 1, 1, sn8 , sn8 , , , yx01, rgb +PIPE_FORMAT_R8G8B8_SNORM , array , 1, 1, sn8 , sn8 , sn8 , , zyx1, rgb +PIPE_FORMAT_R8G8B8A8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , wzyx, rgb +PIPE_FORMAT_R8G8B8X8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , wzy1, rgb PIPE_FORMAT_B6G5R5_SNORM , arith , 1, 1, sn5 , sn5 , sn6 , , xyz1, rgb -PIPE_FORMAT_A8B8G8R8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , wzyx, rgb -PIPE_FORMAT_X8B8G8R8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , wzy1, rgb +PIPE_FORMAT_A8B8G8R8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , xyzw, rgb +PIPE_FORMAT_X8B8G8R8_SNORM, array , 1, 1, sn8 , sn8 , sn8 , sn8 , xyz1, rgb PIPE_FORMAT_R8_SSCALED, array , 1, 1, s8 , , , , x001, rgb -PIPE_FORMAT_R8G8_SSCALED , array , 1, 1, s8 , s8 , , , xy01, rgb -PIPE_FORMAT_R8G8B8_SSCALED, array , 1, 1, s8 , s8 , s8 , , xyz1, rgb -PIPE_FORMAT_R8G8B8A8_SSCALED , array , 1, 1, s8 , s8 , s8 , s8 , xyzw, rgb -PIPE_FORMAT_R8G8B8X8_SSCALED , array , 1, 1, s8 , s8 , s8 , s8 , xyz1, rgb +PIPE_FORMAT_R8G8_SSCALED , array , 1, 1, s8 , s8 , , , yx01, rgb +PIPE_FORMAT_R8G8B8_SSCALED, array , 1, 1, s8 , s8 , s8 , , zyx1, rgb +PIPE_FORMAT_R8G8B8A8_SSCALED , array , 1, 1, s8 , s8 , s8 , s8 , wzyx, rgb
[Mesa3d-dev] [PATCH] st/dri: don't enable EXT_draw_buffers2 by default
Hi,
the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
default because r300g and most probably even some other drivers can't
support this extension. The drivers reporting support of
PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.
Please review.
Marek
From ddda2c19b74780263f848ffafe10809bd6385d01 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sun, 21 Feb 2010 01:27:09 +0100
Subject: [PATCH 2/2] st/dri: don't enable EXT_draw_buffers2 by default
---
src/gallium/state_trackers/dri/dri_extensions.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri_extensions.c b/src/gallium/state_trackers/dri/dri_extensions.c
index 1259813..7f8ceef 100644
--- a/src/gallium/state_trackers/dri/dri_extensions.c
+++ b/src/gallium/state_trackers/dri/dri_extensions.c
@@ -99,7 +99,6 @@ static const struct dri_extension card_extensions[] = {
{GL_EXT_blend_minmax, GL_EXT_blend_minmax_functions},
{GL_EXT_blend_subtract, NULL},
{GL_EXT_cull_vertex, GL_EXT_cull_vertex_functions},
- {GL_EXT_draw_buffers2, GL_EXT_draw_buffers2_functions},
{GL_EXT_fog_coord, GL_EXT_fog_coord_functions},
{GL_EXT_framebuffer_object, GL_EXT_framebuffer_object_functions},
{GL_EXT_multi_draw_arrays, GL_EXT_multi_draw_arrays_functions},
--
1.6.3.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: remove L8_UNORM from colorbuffer formats
I still think st/xorg should use R8, which is well defined as to which component to store, rather than L8. That's also the reason L8 is not renderable in OpenGL. 2010/2/19 Corbin Simpson mostawesomed...@gmail.com Yeah, I would have nak'd this. Will revert when I get home. Posting from a mobile, pardon my terseness. ~ C. On Feb 19, 2010 12:56 AM, Michel Dänzer mic...@daenzer.net wrote: On Thu, 2010-02-18 at 19:24 -0800, Marek Olk wrote: Module: Mesa Branch: master Commit: fc427d23439a2702068209957f08990ea29fe21b URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=fc427d23439a2702068209957f08990ea29fe21b Author: Marek Olšák mar...@gmail.com Date: Fri Feb 19 04:23:06 2010 +0100 r300g: remove L8_UNORM from colorbuffer formats Not renderable in OpenGL anyway. The Xorg state tracker uses it though. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] piglit statistics of swrast, softpipe, r300c, and r300g
Hi, I noticed that quite a lot of piglit tests fail with swrast and softpipe. I was asked for sending my stats to ML so that people working on the software rasterizers are aware of that (I guess they already know). Please see this page: http://storm.unas.cz/drivers_compared/ The parser tests and some pretty long tests are not included. The ratio pass/all is highest for r300c and lowest for more feature-rich r300g but swrast is worse than softpipe which is a shame. Tested with git master on 6th February 2010. r300g stats are the only ones not tested with pure git master but with my own additional patches in my private (localhost) repo. Best regards Marek -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements
Eric,
yes, it does.
I decided to resolve my precision issues using glDisable(GL_DITHER). The two
patches disable dithering, the former in piglit and the latter in glean. I
see no point in separating them to smaller ones but I can do that if you
like. Since it's tricky to test dithering anyway, disabling it is
preferable. Could you please push the first one if there are no objections?
Brian,
Could you please push the second one into glean if there are no objections?
-Marek
On Thu, Feb 11, 2010 at 1:42 AM, Eric Anholt e...@anholt.net wrote:
On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák mar...@gmail.com wrote:
The attached patch series relaxes precision requirements for 6 tests to
pass
on r300g.
Please review/push.
I just pushed a change to do the r300relax type path always on cubemap
and fbo-cubemap. It sounds like the decision was that the dithering at
32bpp was doing strange things and the solution was to just disable it
in that case -- right? If so, does that leave any patches still to be
committed for the piglit side of things?
From dc274f1caf050f23f8489f316c52621df679e87b Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Wed, 10 Feb 2010 02:00:17 +0100
Subject: [PATCH 1/4] copytexsubimage,fbo-pbo-readpixels-small,tex3d: disable dithering
---
tests/fbo/fbo-pbo-readpixels-small.c |2 ++
tests/texturing/copytexsubimage.c|2 ++
tests/texturing/tex3d.c |2 ++
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/tests/fbo/fbo-pbo-readpixels-small.c b/tests/fbo/fbo-pbo-readpixels-small.c
index 09740d2..1f50700 100644
--- a/tests/fbo/fbo-pbo-readpixels-small.c
+++ b/tests/fbo/fbo-pbo-readpixels-small.c
@@ -161,4 +161,6 @@ void piglit_init(int argc, char **argv)
{
piglit_require_extension(GL_EXT_framebuffer_object);
piglit_require_extension(GL_ARB_pixel_buffer_object);
+
+ glDisable(GL_DITHER);
}
diff --git a/tests/texturing/copytexsubimage.c b/tests/texturing/copytexsubimage.c
index 481c731..2e79174 100644
--- a/tests/texturing/copytexsubimage.c
+++ b/tests/texturing/copytexsubimage.c
@@ -264,6 +264,8 @@ static void display(void)
static void init(void)
{
+ glDisable(GL_DITHER);
+
glMatrixMode( GL_PROJECTION );
glPushMatrix();
glLoadIdentity();
diff --git a/tests/texturing/tex3d.c b/tests/texturing/tex3d.c
index c3854f9..1647d82 100644
--- a/tests/texturing/tex3d.c
+++ b/tests/texturing/tex3d.c
@@ -226,6 +226,8 @@ piglit_init(int argc, char **argv)
glutReshapeFunc(Reshape);
+ glDisable(GL_DITHER);
+
glGenTextures(1, Texture);
glBindTexture(GL_TEXTURE_3D, Texture);
Reshape(piglit_width, piglit_height);
--
1.6.3.3
From 7e9a5849689b78f0ac0275e9fde6b4b78f1aab1d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Thu, 11 Feb 2010 00:16:56 +0100
Subject: [PATCH 4/4] glean/clipFlat,fbo,texture_srgb: disable dithering
---
tests/glean/tclipflat.cpp |1 +
tests/glean/tfbo.cpp |2 ++
tests/glean/ttexture_srgb.cpp |2 ++
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/glean/tclipflat.cpp b/tests/glean/tclipflat.cpp
index a2798c0..db5726d 100644
--- a/tests/glean/tclipflat.cpp
+++ b/tests/glean/tclipflat.cpp
@@ -200,6 +200,7 @@ ClipFlatTest::setup(void)
glFrontFace(GL_CW);
glCullFace(GL_FRONT);
glEnable(GL_CULL_FACE);
+ glDisable(GL_DITHER);
provoking_vertex_first = GLUtils::haveExtension(GL_EXT_provoking_vertex);
diff --git a/tests/glean/tfbo.cpp b/tests/glean/tfbo.cpp
index d76fc2d..fda1da0 100644
--- a/tests/glean/tfbo.cpp
+++ b/tests/glean/tfbo.cpp
@@ -85,6 +85,8 @@ FBOTest::setup(void)
glDrawBuffer(GL_FRONT);
glReadBuffer(GL_FRONT);
+glDisable(GL_DITHER);
+
// compute error tolerances (may need fine-tuning)
int bufferBits[5];
diff --git a/tests/glean/ttexture_srgb.cpp b/tests/glean/ttexture_srgb.cpp
index e27081b..7a85a3d 100644
--- a/tests/glean/ttexture_srgb.cpp
+++ b/tests/glean/ttexture_srgb.cpp
@@ -172,6 +172,8 @@ TextureSRGBTest::testTextureFormat(GLenum intFormat, GLint components,
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
glEnable(GL_TEXTURE_2D);
+ glDisable(GL_DITHER);
+
glDrawBuffer(GL_FRONT);
glReadBuffer(GL_FRONT);
--
1.6.3.3
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements
On Mon, Feb 8, 2010 at 6:48 PM, Eric Anholt e...@anholt.net wrote: On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák mar...@gmail.com wrote: The attached patch series relaxes precision requirements for 6 tests to pass on r300g. Please review/push. Have you tried getting the glean components pushed to the glean project? I'd rather not carry functional differences from glean where we don't have to. I was under the impression that glean has been merged into piglit. Is there any reason to keep it separate? Intel has issues on the cubemap tests at 2x2 and lower as well. I'm wondering -- are closed drivers the same in this respect? Unfortunately yes, they are. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
On Sun, Jan 31, 2010 at 1:37 AM, Roland Scheidegger srol...@vmware.comwrote: 7) Is there more information on the dual-source blend modes? I'm not sure if I can do them; might have to bug AMD for the register values. I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not present in Direct3D 10.1. MS must have a good reason to remove it. Where did you see that it's removed in 10.1? Here's a list of blend ops in d3d11: http://msdn.microsoft.com/en-us/library/ee416042(VS.85).aspxhttp://msdn.microsoft.com/en-us/library/ee416042%28VS.85%29.aspx Note this feature can be present (via cap bits in some limited form) in D3D9Ex too, and I thought windows actually used it for (antialiased) text rendering (but don't quote me on that). You're right. My source was incorrect (OpenGL.org forums). -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Grab bag of random questions (whoo)
Hi Corbin, On Sat, Jan 30, 2010 at 1:06 PM, Corbin Simpson mostawesomed...@gmail.comwrote: 5) ... Also, on the topic of framebuffers, is it okay to refuse to render if no MRTs or Z buffer are present? Do you mean color-only and depth-only rendering? This is a must. Shadow mapping heavily relies on depth-only rendering. OTOH post-processing effects like HDR, bloom, depth of field, later parts of deferred-rendering methods, and many other advanced methods require color-only rendering. The FBO extensions allows either no color attachment or no depth-stencil attachment. I know there are inter-CSO depedencies in r300g because of this, but I don't see any other way around it. 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in the fragment constants reads, Since Gallium doesn't support GL_ARB_shadow_ambient, this is always (0,0,0,0), right? I think the extension could be added to Gallium since the r300 compiler can generate code for it. Another comment reads, Gallium doesn't provide us with any information regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE, above the texture compare modes. I don't really like that section of code, but it probably can't get cleaner, right? Even though this is a rarely used feature in OpenGL nowadays, it should get fixed if we want to be GL-compliant. That means adding depth texture modes in pipe_sampler_state and setting them in the Mesa state tracker. The R300 compiler can already generate code for these modes as well. 7) Is there more information on the dual-source blend modes? I'm not sure if I can do them; might have to bug AMD for the register values. I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not present in Direct3D 10.1. MS must have a good reason to remove it. BTW I looked at some of your patches and r3xx-r5xx cards don't even support separate blend enables, therefore the cap should be 0. Or are you going to emulate this using independent color channel masks and two rendering passes? That could be done in the state tracker. Also, I think the indep. color masks are r5xx-only. Cheers. Marek -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration
Hi Brian,
On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul bri...@vmware.com wrote:
The second patch enables hardware-accelerated CopyTex[Sub]Image in cases
when the RGB and RGBA destination formats are used regardless of source
formats. The idea is that if the colorbuffer is of RGB or RGBA format, the
format conversion for copying between two different surfaces is basically
done in texture units (using swizzles), therefore there is no reason to use
software fallback. Without this patch, openarena fallbacks to software when
bloom is enabled.
Did you read the comment at line 1498? I remember specifically adding this
check to fix some issues when copying an RGBA framebuffer to a RGB texture.
The behavior of copying an RGBA framebuffer to an RGB texture is not changed
by this patch, it is only generalized to support other formats. I agree the
diff file is a little bit confusing. See the code before:
else if (srcFormat == GL_RGBA
dstLogicalFormat == GL_RGB) {
/* Add a single special case to cope with RGBA-RGB transfers,
* setting A to 1.0 to cope with situations where the RGB
* destination is actually stored as RGBA.
*/
return TGSI_WRITEMASK_XYZ; /* A == 1.0 */
}
else {
The code after:
else if (dstLogicalFormat == GL_RGBA) {
/* In theory, any format can be converted to GL_RGBA.
*/
return TGSI_WRITEMASK_XYZW;
}
else if (dstLogicalFormat == GL_RGB) {
/* Add a special case to cope with transfers into RGB,
* setting A to 1.0 to cope with situations where the RGB
* destination is actually stored as RGBA.
*/
return TGSI_WRITEMASK_XYZ; /* A == 1.0 */
}
else {
Are you ok with that?
BTW could you please push the first patch (and the second one if you agree)?
My account hasn't been created yet. Thank you.
Best regards.
Marek
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration
Yes, your patch solves my problem. Thanks.
Marek
On Wed, Jan 20, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote:
Marek Olšák wrote:
Hi Brian,
On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul bri...@vmware.com mailto:
bri...@vmware.com wrote:
The second patch enables hardware-accelerated CopyTex[Sub]Image
in cases when the RGB and RGBA destination formats are used
regardless of source formats. The idea is that if the
colorbuffer is of RGB or RGBA format, the format conversion for
copying between two different surfaces is basically done in
texture units (using swizzles), therefore there is no reason to
use software fallback. Without this patch, openarena fallbacks
to software when bloom is enabled.
Did you read the comment at line 1498? I remember specifically
adding this check to fix some issues when copying an RGBA
framebuffer to a RGB texture.
The behavior of copying an RGBA framebuffer to an RGB texture is not
changed by this patch, it is only generalized to support other formats. I
agree the diff file is a little bit confusing. See the code before:
else if (srcFormat == GL_RGBA
dstLogicalFormat == GL_RGB) {
/* Add a single special case to cope with RGBA-RGB transfers,
* setting A to 1.0 to cope with situations where the RGB
* destination is actually stored as RGBA.
*/
return TGSI_WRITEMASK_XYZ; /* A == 1.0 */
}
else {
The code after:
else if (dstLogicalFormat == GL_RGBA) {
/* In theory, any format can be converted to GL_RGBA.
*/
return TGSI_WRITEMASK_XYZW;
}
else if (dstLogicalFormat == GL_RGB) {
/* Add a special case to cope with transfers into RGB,
* setting A to 1.0 to cope with situations where the RGB
* destination is actually stored as RGBA.
*/
return TGSI_WRITEMASK_XYZ; /* A == 1.0 */
}
else {
Are you ok with that?
No. But don't feel bad, I think my original code is broken too. :(
See the attached patch. It has a bunch of comments that explain what's
going on.
If you can test this and it seems to solve your problem, I'll commit it.
BTW could you please push the first patch (and the second one if you
agree)? My account hasn't been created yet. Thank you.
Yes, done.
-Brian
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
Hi Luca,
I think this is not necessary and fixing the rasterizer setup in the driver
would by better than fixing the state tracker.
In r300g, we dynamically allocate rasterizer units based on vertex shader
outputs. If the vertex shader uses slots 1, 5, 20, 100, the driver maps
them to units 1,2,3,4.
Marek
On Sun, Jan 17, 2010 at 8:05 PM, Luca Barbieri l...@luca-barbieri.comwrote:
The current GLSL linker puts varyings in slots starting from *_VAR0,
leaving the *_TEX slots used only for gl_TexCoord[i].
This results in TGSI programs that start using generic input/outputs
with index 10.
Unfortunately, some drivers (e.g. pre-nv50 nouveau) support only 8
vertex program outputs, and this causes GLSL to not work at all.
On other cards, GLSL works, but 8 varying slots are lost.
This patch solves the problem by modifying the GLSL linker to allocate
varyings in texcoord slots that neither vertex nor fragment shader uses.
Note that the GLSL linker is the only place where this can be done,
because it is the only place that sees both the vertex and fragment
programs at once.
The only known issue is that if the GLSL program has an indirect
reference to gl_TexCoord[i], no varyings will be put in texcoord slots.
This may or may not be desirable.
This makes (a subset of) GLSL work on NV30/NV40 and improves the
chances of complex programs working on other cards.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
src/mesa/shader/slang/slang_link.c | 62
++-
1 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/src/mesa/shader/slang/slang_link.c
b/src/mesa/shader/slang/slang_link.c
index ed27821..889a811 100644
--- a/src/mesa/shader/slang/slang_link.c
+++ b/src/mesa/shader/slang/slang_link.c
@@ -99,9 +99,9 @@ bits_agree(GLbitfield flags1, GLbitfield flags2,
GLbitfield bit)
*/
static GLboolean
link_varying_vars(GLcontext *ctx,
- struct gl_shader_program *shProg, struct gl_program
*prog)
+ struct gl_shader_program *shProg, struct gl_program
*prog, GLbyte* varying_slots)
{
- GLuint *map, i, firstVarying, newFile;
+ GLuint *map, i, firstTex, firstVarying, newFile;
GLbitfield *inOutFlags;
map = (GLuint *) _mesa_malloc(prog-Varying-NumParameters *
sizeof(GLuint));
@@ -114,13 +114,15 @@ link_varying_vars(GLcontext *ctx,
* Also, replace File=PROGRAM_VARYING with File=PROGRAM_INPUT/OUTPUT.
*/
if (prog-Target == GL_VERTEX_PROGRAM_ARB) {
- firstVarying = VERT_RESULT_VAR0;
+ firstTex = VERT_RESULT_TEX0;
+ firstVarying = VERT_RESULT_VAR0 - 8;
newFile = PROGRAM_OUTPUT;
inOutFlags = prog-OutputFlags;
}
else {
assert(prog-Target == GL_FRAGMENT_PROGRAM_ARB);
- firstVarying = FRAG_ATTRIB_VAR0;
+ firstTex = FRAG_ATTRIB_TEX0;
+ firstVarying = FRAG_ATTRIB_VAR0 - 8;
newFile = PROGRAM_INPUT;
inOutFlags = prog-InputFlags;
}
@@ -173,9 +175,12 @@ link_varying_vars(GLcontext *ctx,
{
GLint sz = var-Size;
while (sz 0) {
-inOutFlags[firstVarying + j] = var-Flags;
+int v = varying_slots[j];
+v += ((v 8) ? firstTex : firstVarying);
+inOutFlags[v] = var-Flags;
/*printf(Link varying from %d to %d\n, i, j);*/
-map[i++] = j++;
+map[i++] = v;
+++j;
sz -= 4;
}
i--; /* go back one */
@@ -192,13 +197,13 @@ link_varying_vars(GLcontext *ctx,
if (inst-DstReg.File == PROGRAM_VARYING) {
inst-DstReg.File = newFile;
- inst-DstReg.Index = map[ inst-DstReg.Index ] + firstVarying;
+ inst-DstReg.Index = map[ inst-DstReg.Index ];
}
for (j = 0; j 3; j++) {
if (inst-SrcReg[j].File == PROGRAM_VARYING) {
inst-SrcReg[j].File = newFile;
-inst-SrcReg[j].Index = map[ inst-SrcReg[j].Index ] +
firstVarying;
+inst-SrcReg[j].Index = map[ inst-SrcReg[j].Index ];
}
}
}
@@ -790,14 +795,39 @@ _slang_link(GLcontext *ctx,
ASSERT(shProg-FragmentProgram-Base.RefCount == 1);
}
- /* link varying vars */
- if (shProg-VertexProgram) {
- if (!link_varying_vars(ctx, shProg, shProg-VertexProgram-Base))
- return;
- }
- if (shProg-FragmentProgram) {
- if (!link_varying_vars(ctx, shProg, shProg-FragmentProgram-Base))
- return;
+ {
+ GLuint texcoord_mask = 0;
+ GLbyte varying_slots[MAX_VARYING];
+ GLuint next_varying = 0;
+
+ if(shProg-VertexProgram)
+ {
+_slang_update_inputs_outputs(shProg-VertexProgram-Base);
+texcoord_mask |= (shProg-VertexProgram-Base.OutputsWritten
VERT_RESULT_TEX0) 0xff;
+ }
+ if(shProg-FragmentProgram)
+ {
+_slang_update_inputs_outputs(shProg-FragmentProgram-Base);
+texcoord_mask |=
Re: [Mesa3d-dev] Running with scissors
It was NOT intended to be a performance optimization, it's a fix. I added it because kernel would have rejected the command stream if everything had been culled by scissoring. Marek On Mon, Jan 11, 2010 at 4:39 PM, Corbin Simpson mostawesomed...@gmail.comwrote: Pardon the subject pun, it was totally necessary at this early hour. :3 If the scissor test is enabled, and the scissors obscure the entire framebuffer, should drawing calls still be run? Talking on IRC, it seems like there's a valid use-case for performance testing, and I'm of the mind that anybody that deliberately sets up the pipeline and scissor that way probably intended for it. I just want a clarification so I know whether I should revert bfcafbe15dc, and also I wanted to document it. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] geometry shading patches
Zack, to be honest, Direct3D 11 can report geometry shaders are not supported through so-called feature levels. There are six levels to my knowledge (9_1, 9_2, 9_3, 10_0, 10_1, 11_0). i915 is 9_1, R300 is 9_2, R500 is 9_3, and so on. Direct3D 11 is indeed accelerated on those pieces of hardware and, though the feature set is a little limited, the hardware support is covered well. Is Direct3D 11 generations past because of that? No, it isn't. Let's say I have R500 and I want to use geometry shaders in Direct3D 11. What are my options? I can't use my R500 and I must manually switch to the device called WARP (Windows Advanced Rasterization Platform), which reports the 10_1 feature level. This kind of device is very similar to llvmpipe in Gallium. In the past you said we should do it the same way as Direct3D, so why should Gallium be different now? Moreover, if applications decide to use geometry shaders to emulate point sprites or wide lines, we'll be screwed. If they decide to do texture fetches in geometry shaders, we'll be screwed even more because we'll have to move textures out of VRAM and that will be a total performance killer. So I agree with Corbin that the CAP for geometry shaders should be added and we should let drivers decide what's best for them. Marek On Fri, Dec 25, 2009 at 5:11 PM, Zack Rusin za...@vmware.com wrote: On Friday 25 December 2009 07:03:02 Corbin Simpson wrote: Isn't this incredibly at odds with our previous discussion, in which we generally agreed to not advertise support for unaccelerated things? No, it's really not. We don't have caps for core features, e.g we don't have caps for vertex shaders and this goes hand in hand with that. Geometry shaders are optional in the pipeline meaning that unlike fragment shaders they can be absent in which case the pipeline behaves just like it would if the api didn't have geometry shaders exposed at all i.e. vertex shader outputs go directly do the fragment shader. So for games/apps that don't use geometry shaders this won't matter at all. And games/app that are so new that they actually check for geometry shaders will already be slow on i915 and r300 not because of geometry shaders, but because they're running on it on i915 or r300 =) Not to mention that this is not a fringe feature that will be present only in super high-end and futuristic hardware. All in all it's a bit like fixed-point hardware - programmable hardware is not a cap because it's what Gallium models. We can't just keep the Gallium interface at i915 level and mark everything above that as a cap, it'd be silly given that we're generations past that now. z -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
I am not very fond of the idea having another layer of function-call indirections and state management between a driver and a state tracker. I kinda succeed in making the failover driver work with some hacks and limitations (e.g. no textures). Even if I use it as a simple pass-through driver, it results in 40% performance drop in glxgears and 10% performance drop in progs/perf/draw_overhead. The driver overhead is a real issue here and it might be much higher with a full-blown fallback driver, and nobody wants the performance to suck so much. Also I'd like the applications which don't hit any fallback path to not be affected by this additional overhead, so putting a fallback driver on top of a real driver should be deferred if possible which makes this whole thing non-trivial. In the meantime I think we could lie that NPOTs are supported and implement only the functionality state trackers really want (2D textures with the repeat wrap mode and bilinear filtering done in the shader [0]). That would make all state trackers happy except the Mesa one, but doing software fallback instead would not make it happy either. We're talking about turning unavailable features to unusable ones, is it worth it? [0] I think I could do it if someone tells me how to easily replace TEX instructions with my own code in TGSI. Marek On Mon, Dec 21, 2009 at 6:57 PM, Jakob Bornecrantz ja...@vmware.com wrote: To be honest I'm way more in favor off doing 4 and/or with a env variable to switch between incorrect rendering and software fallbacks, but maybe we can do 3 but with another solution. At some point the Gallium interface was a expression of what hardware could do not a interface to program against. Another guiding rule was that it should be easy to write a pipe driver, putting all the hard stuff in the state tracker. Now we are starting to see a lot of state trackers and its becoming harder and harder to implement all the work around for the different caps. Even tho the fallback/workaround code is in a module that can be shared its still a pain to integrate and a lot of boiler plate code needs to be written and maintained. Maybe we should revive the fallback module or make a another module like it that takes care of all these shortcomings of the hardware. But it is optional to the state tracker. That it is optional to the state tracker is the big thing. So an usecase: The mesa state tracker takes a look at the pipe caps of the r300 driver and notices something bad no CAP_NPOT but CAP_TEXRECT. It then wraps the pipe driver with the fallback pipe driver and uses that. And all the NPOT badness is hidden from the state tracker. The code to switch between software and and hardwware rendering only needs to be written once this includes the code to detect IF we should switch to software and code to select between different modes of handling of different type of errors, like FALLBACK_CONFORM, FALLBACK_BAD_RENDERING. The good part with this is that the fallback module is optional and for state trackers that can handle some of the possible shortcomings or doesn't need all of the functionality don't need to wrap the pipe driver. We get clean drivers, clean state tracker but a heap of code in the fallback module... I could also see the blitter module getting sucked into the fallback module. Comments please? Cheers Jakob. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Mystery of u_format.csv
Hi, I noticed that gallium/auxiliary/util/u_format.csv contains some weird swizzling, for example see this: $ grep zyxw u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 , zyxw, rgb PIPE_FORMAT_A4R4G4B4_UNORM, arith , 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_A8B8G8R8_SNORM, arith , 1, 1, sn8 , sn8 , sn8 , sn8 , zyxw, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb It's hard to believe that ARGB, ABGR, and BGRA have the same swizzling. Let's continue our journey: $ grep A8R8G8B8 u_format.csv PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , zyxw, rgb PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , wxyz, srgb Same formats, different swizzling? Also: $ grep B8G8R8A8 u_format.csv PIPE_FORMAT_B8G8R8A8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 , yzwx, rgb PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 , u8 , zyxw, srgb Same formats, different swizzling? I don't really get it. And there's much more cases like these. Could someone tell me what the intended order of channels should be? (or possibly propose a fix) The meaning of the whole table is self-contradictory and it's definitely the source of some r300g bugs. Marek -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
Hi,
GL_ARB_provoking_vertex states that quads are not required to abide
the provoking vertex convention, and the actual hardware and/or driver
behavior can be queried with
GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION.
I'd like to add a new PIPE_CAP_* to query for this capability in
Gallium, as it appears R3xx-R5xx hardware doesn't support the first
vertex convention for quads and I'd like the driver to behave
correctly. Fortunately, other primitive types are supported.
I decided to use the name quads follow flatshade_first convention
instead of provoking vertex convention because the actual state
variable in pipe_rasterizer_state is called flatshade_first.
The attached patch:
- adds PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
- adds the query in the Mesa state tracker
- and updates softpipe and llvmpipe to return 1 when this cap is
queried, and r300g to explicitly return 0
Please review/push.
Cheers.
Marek
From bbf279f81e03a6872507cbf533b382748c4ae015 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Fri, 18 Dec 2009 05:10:27 +0100
Subject: [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
---
src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
src/gallium/drivers/r300/r300_screen.c |2 ++
src/gallium/drivers/softpipe/sp_screen.c |2 ++
src/gallium/include/pipe/p_defines.h |1 +
src/mesa/state_tracker/st_extensions.c |4
5 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c
index 9b47415..fa786f9 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -110,6 +110,8 @@ llvmpipe_get_param(struct pipe_screen *screen, int param)
return 1;
case PIPE_CAP_BLEND_EQUATION_SEPARATE:
return 1;
+ case PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION:
+ return 1;
default:
return 0;
}
diff --git a/src/gallium/drivers/r300/r300_screen.c b/src/gallium/drivers/r300/r300_screen.c
index c2ea9b6..0b75ecf 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -138,6 +138,8 @@ static int r300_get_param(struct pipe_screen* pscreen, int param)
return 0;
case PIPE_CAP_BLEND_EQUATION_SEPARATE:
return 1;
+case PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION:
+return 0;
default:
debug_printf(r300: Implementation error: Bad param %d\n,
param);
diff --git a/src/gallium/drivers/softpipe/sp_screen.c b/src/gallium/drivers/softpipe/sp_screen.c
index bd3532d..510150b 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -91,6 +91,8 @@ softpipe_get_param(struct pipe_screen *screen, int param)
return 1;
case PIPE_CAP_BLEND_EQUATION_SEPARATE:
return 1;
+ case PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION:
+ return 1;
default:
return 0;
}
diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
index fe1390d..6a37893 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -393,6 +393,7 @@ enum pipe_transfer_usage {
#define PIPE_CAP_MAX_PREDICATE_REGISTERS 30
#define PIPE_CAP_MAX_COMBINED_SAMPLERS 31 /* Maximum texture image units accessible from vertex
and fragment shaders combined */
+#define PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION 32
/**
diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
index ef3cbc5..db3380b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -125,6 +125,10 @@ void st_init_limits(struct st_context *st)
= CLAMP(screen-get_param(screen, PIPE_CAP_MAX_RENDER_TARGETS),
1, MAX_DRAW_BUFFERS);
+ c-QuadsFollowProvokingVertexConvention
+ = CLAMP(screen-get_param(screen, PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION),
+ 0, 1);
+
/* Is TGSI_OPCODE_CONT supported? */
/* XXX separate query for early function return? */
st-ctx-Shader.EmitContReturn =
--
1.6.3.3
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: flush CS if a buffer being deleted is referenced by it
2009/12/16 Michel Dänzer mic...@daenzer.net:
On Tue, 2009-12-15 at 19:04 -0800, Corbin Simpson wrote:
Module: Mesa
Branch: master
Commit: 417ce06306962a9355cbb35cefcdea1951b0ce85
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=417ce06306962a9355cbb35cefcdea1951b0ce85
Author: Marek Olšák mar...@gmail.com
Date: Sat Dec 12 23:44:02 2009 +0100
r300g: flush CS if a buffer being deleted is referenced by it
[...]
diff --git a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
index 2a8daed..76acc99 100644
--- a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
+++ b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
@@ -131,6 +132,11 @@ static void radeon_buffer_del(struct pipe_buffer
*buffer)
{
struct radeon_pipe_buffer *radeon_buffer =
(struct radeon_pipe_buffer*)buffer;
+ struct radeon_winsys_priv *priv = radeon_buffer-ws-priv;
+
+ if (radeon_bo_is_referenced_by_cs(radeon_buffer-bo, priv-cs)) {
+ priv-cs-space_flush_fn(priv-cs-space_flush_data);
+ }
Why would this be necessary?
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
Oh, it doesn't seem to be needed at all. Feel free to revert this commit.
Marek
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Fwd: gallium: add blitter
On Tue, Dec 15, 2009 at 10:28 AM, Keith Whitwell kei...@vmware.com wrote: On Mon, 2009-12-14 at 16:31 -0800, Marek Olšák wrote: On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson mostawesomed...@gmail.com wrote: As far as immediate verts, why don't we just add support to r300g to switch to immediate mode for small VBOs? Posting from a mobile, pardon my terseness. ~ C. Corbin, that seems reasonable, and it's the reason I killed the draw_quad function. BTW immediate mode doubles the performance in glxgears. Shouldn't gears upload its vertices one time only and then leave them resident in VRAM? Keith I meant the clear path with a quad using immediate mode, that made the difference in comparison with a straightforward VBO path. Marek -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium: add blitter
On Tue, Dec 15, 2009 at 11:27 AM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2009-12-15 at 01:49 -0800, Marek Olšák wrote: On Tue, Dec 15, 2009 at 10:28 AM, Keith Whitwell kei...@vmware.com wrote: On Mon, 2009-12-14 at 16:31 -0800, Marek Olšák wrote: On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson mostawesomed...@gmail.com wrote: As far as immediate verts, why don't we just add support to r300g to switch to immediate mode for small VBOs? Posting from a mobile, pardon my terseness. ~ C. Corbin, that seems reasonable, and it's the reason I killed the draw_quad function. BTW immediate mode doubles the performance in glxgears. Shouldn't gears upload its vertices one time only and then leave them resident in VRAM? Keith I meant the clear path with a quad using immediate mode, that made the difference in comparison with a straightforward VBO path. OK, understood. I'm interested to understand why the VBO path is slow. Is it the allocation of the VBO itself? Mapping uploading the vertices? Command submission (the extra reloc)? It seems to me that none of these should be taking half your time. In fact, it makes me wonder if there wasn't something else going on -- eg. was the same buffer getting reused to hold those 4 vertices frame after frame, resulting in a sync when the driver tried to map the buffer? That could be happening in the state tracker or in the driver, I guess. Keith Yes, the same buffer was getting reused every frame causing sync when mapping the buffer. However, it will no longer be an issue once immediate mode gets implemented. Using DONT_WAIT would probably also help here. Please, could you possibly look at the patches I sent to you approximately 16 hours ago? (there are 7 of them) Marek -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium: add blitter
On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson mostawesomed...@gmail.com wrote: As far as immediate verts, why don't we just add support to r300g to switch to immediate mode for small VBOs? Posting from a mobile, pardon my terseness. ~ C. Corbin, that seems reasonable, and it's the reason I killed the draw_quad function. BTW immediate mode doubles the performance in glxgears. To others: I noticed that there is a weird optimization in u_gen_mipmaps. It allocates a large vertex buffer and uses small chunks of it to render consecutive quads (one for each mipmap level and cubemap face). If we implement switching to immediate mode, it would be nice for VBOs to be as small as possible so that the driver can easily recognize the most efficient path. The simplest solution (4 vertices in a VBO) may end up being the fastest one here. Marek -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium: let drivers fallback on framebuffer clearing
Hi,
Because some hardware under some circumstances (e.g. disabled tiling)
may not be able to use a hardware-specific clear path, it would be
nice to let a state tracker do the clearing by drawing a
screen-aligned quad. I am proposing to change the pipe_context-clear
function to return TRUE if buffers were cleared by the driver, and
FALSE if the state tracker should do the clearing by taking a generic
path.
As an example, r300g can use the fast clearing only if colorbuffers
and zbuffers are micro-tiled, otherwise it must draw a screen-aligned
quad and doing it in the driver is really messy.
The attached patch implements this interface change and adapts all
state trackers and drivers.
I noticed that a lot of drivers still use slow util_clear, so they
will greatly benefit from this patch. It's up to their maintainers
whether they enable it, I suspect some unstable drivers may not be
able to draw a quad without visual errors.
Please review.
Best regards
Marek Olšák
From a6d16e7bce330900d496593054ec6aeb3ed51a2f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Mon, 7 Dec 2009 00:33:17 +0100
Subject: [PATCH] gallium: let drivers fallback on framebuffer clearing
A driver can either clear a framebuffer by itself or can tell the state tracker
to draw a screen-aligned quad if a hardware-specific clear path is not
available.
---
src/gallium/drivers/cell/ppu/cell_clear.c|4 +++-
src/gallium/drivers/cell/ppu/cell_clear.h|3 ++-
src/gallium/drivers/i915/i915_clear.c|3 ++-
src/gallium/drivers/i915/i915_context.h |4 ++--
src/gallium/drivers/identity/id_context.c| 12 ++--
src/gallium/drivers/llvmpipe/lp_clear.c |4 +++-
src/gallium/drivers/llvmpipe/lp_clear.h |2 +-
src/gallium/drivers/nv04/nv04_clear.c| 10 ++
src/gallium/drivers/nv04/nv04_context.h |4 ++--
src/gallium/drivers/nv10/nv10_clear.c|3 ++-
src/gallium/drivers/nv10/nv10_context.h |2 +-
src/gallium/drivers/nv20/nv20_clear.c|3 ++-
src/gallium/drivers/nv20/nv20_context.h |2 +-
src/gallium/drivers/nv30/nv30_clear.c|3 ++-
src/gallium/drivers/nv30/nv30_context.h |2 +-
src/gallium/drivers/nv40/nv40_clear.c|3 ++-
src/gallium/drivers/nv40/nv40_context.h |2 +-
src/gallium/drivers/nv50/nv50_clear.c|4 +++-
src/gallium/drivers/nv50/nv50_context.h |2 +-
src/gallium/drivers/r300/r300_clear.c| 11 ++-
src/gallium/drivers/r300/r300_clear.h| 12 +++-
src/gallium/drivers/softpipe/sp_clear.c |5 +++--
src/gallium/drivers/softpipe/sp_clear.h |2 +-
src/gallium/drivers/svga/svga_context.h | 10 +-
src/gallium/drivers/svga/svga_pipe_clear.c |3 ++-
src/gallium/drivers/trace/tr_context.c |7 +--
src/gallium/include/pipe/p_context.h |4 +++-
src/gallium/state_trackers/vega/api_masks.c | 11 +++
src/gallium/state_trackers/vega/vg_context.c |6 +-
src/gallium/state_trackers/vega/vg_tracker.c |8 ++--
src/gallium/state_trackers/xorg/xorg_exa.c |7 +--
src/mesa/state_tracker/st_cb_clear.c | 12 +---
32 files changed, 107 insertions(+), 63 deletions(-)
diff --git a/src/gallium/drivers/cell/ppu/cell_clear.c b/src/gallium/drivers/cell/ppu/cell_clear.c
index 79ad687..553d924 100644
--- a/src/gallium/drivers/cell/ppu/cell_clear.c
+++ b/src/gallium/drivers/cell/ppu/cell_clear.c
@@ -48,7 +48,7 @@
/**
* Called via pipe-clear()
*/
-void
+boolean
cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
double depth, unsigned stencil)
{
@@ -89,4 +89,6 @@ cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
clr-surface = surfIndex;
clr-value = clearValue;
}
+
+ return TRUE;
}
diff --git a/src/gallium/drivers/cell/ppu/cell_clear.h b/src/gallium/drivers/cell/ppu/cell_clear.h
index 08e091a..9fc3a01 100644
--- a/src/gallium/drivers/cell/ppu/cell_clear.h
+++ b/src/gallium/drivers/cell/ppu/cell_clear.h
@@ -29,11 +29,12 @@
#ifndef CELL_CLEAR_H
#define CELL_CLEAR_H
+#include pipe/p_compiler.h
struct pipe_context;
-extern void
+extern boolean
cell_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
double depth, unsigned stencil);
diff --git a/src/gallium/drivers/i915/i915_clear.c b/src/gallium/drivers/i915/i915_clear.c
index 90530f2..21528e5 100644
--- a/src/gallium/drivers/i915/i915_clear.c
+++ b/src/gallium/drivers/i915/i915_clear.c
@@ -39,10 +39,11 @@
* Clear the given buffers to the specified values.
* No masking, no scissor (clear entire buffer).
*/
-void
+boolean
i915_clear(struct pipe_context *pipe, unsigned buffers, const float *rgba,
double depth, unsigned stencil)
{
util_clear(pipe, i915_context(pipe)-framebuffer, buffers, rgba, depth
Re: [Mesa3d-dev] st_shader-varients merge tomorrow
Hi Roland, r300g doesn't use *semantic_index at all and due to this some shaders are broken on it. Merging the branch probably can't make it worse, so go for it. I already have fixes for this driver here and I am about to send them soon. Marek On Wed, Nov 25, 2009 at 4:47 AM, Roland Scheidegger srol...@vmware.comwrote: I'm planning to merge st_shader-varients branch to master tomorrow. This should not adversely affect drivers, unless they rely on generics inputs/outputs semantic_index always starting at 0 without holes (something that they shouldn't do but it would have worked previously). Feedback for hw drivers welcome, I'll try i915 myself, but I can't test the others, though some quick glance seemed to suggest they should be ok. Roland -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer
Hi Brian,
I tried your patch and it solves the buffer-mapping issue.
I attached a new patch that fixes the clipping issue. Please, review/push.
Best regards
Marek Olšák
On Mon, Nov 2, 2009 at 6:12 PM, Brian Paul bri...@vmware.com wrote:
Marek Olšák wrote:
Hi,
the attached patch fixes a possible crash in function draw_stencil_pixels
in mesa/state_tracker. I've also updated the list of formats we read from to
prevent an assertion failing later in the code.
This makes glean/depthStencil work on r300g and softpipe.
Best regards
Marek Olšák
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 0a6bfcd..0699404 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -669,6 +669,12 @@ draw_stencil_pixels(GLcontext *ctx, GLint x, GLint y,
strb = st_renderbuffer(ctx-DrawBuffer-
Attachment[BUFFER_STENCIL].Renderbuffer);
+ /* Do not draw outside the drawbuffer */
+ if (x + width ctx-DrawBuffer-Width)
+ width = ctx-DrawBuffer-Width - x;
+ if (y + height ctx-DrawBuffer-Height)
+ height = ctx-DrawBuffer-Height - y;
I think you can use _mesa_clip_drawpixels() here instead. See swrast or
other drivers for example usage.
The second change should be a totally separate patch since it's independent
of the drawpixels clipping issue.
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 878a40f..6f287ff 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
target, GLint level,
srcX, srcY,
width, height);
- if (baseFormat == GL_DEPTH_COMPONENT
+ if ((baseFormat == GL_DEPTH_COMPONENT ||
+baseFormat == GL_DEPTH24_STENCIL8)
pf_is_depth_and_stencil(stImage-pt-format))
transfer_usage = PIPE_TRANSFER_READ_WRITE;
else
I think there's a few things wrong with the depth/stencil path in this
code. Can you try the attached patch?
I also suspec that util_blit_pixels_writemask() isn't working properly when
blitting depth/stencil pixels.
-Brian
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index 878a40f..00a0e4c 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
target, GLint level,
srcX, srcY,
width, height);
- if (baseFormat == GL_DEPTH_COMPONENT
+ if ((baseFormat == GL_DEPTH_COMPONENT ||
+baseFormat == GL_DEPTH_STENCIL)
pf_is_depth_and_stencil(stImage-pt-format))
transfer_usage = PIPE_TRANSFER_READ_WRITE;
else
@@ -1322,7 +1323,7 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum
target, GLint level,
destX, destY, width, height);
if (baseFormat == GL_DEPTH_COMPONENT ||
- baseFormat == GL_DEPTH24_STENCIL8) {
+ baseFormat == GL_DEPTH_STENCIL) {
const GLboolean scaleOrBias = (ctx-Pixel.DepthScale != 1.0F ||
ctx-Pixel.DepthBias != 0.0F);
GLint row, yStep;
@@ -1455,7 +1456,7 @@ st_copy_texsubimage(GLcontext *ctx,
struct gl_texture_image *texImage =
_mesa_select_tex_image(ctx, texObj, target, level);
struct st_texture_image *stImage = st_texture_image(texImage);
- const GLenum texBaseFormat = texImage-InternalFormat;
+ const GLenum texBaseFormat = texImage-_BaseFormat;
struct gl_framebuffer *fb = ctx-ReadBuffer;
struct st_renderbuffer *strb;
struct pipe_context *pipe = ctx-st-pipe;
@@ -1476,12 +1477,9 @@ st_copy_texsubimage(GLcontext *ctx,
/* determine if copying depth or color data */
if (texBaseFormat == GL_DEPTH_COMPONENT ||
- texBaseFormat == GL_DEPTH24_STENCIL8) {
+ texBaseFormat == GL_DEPTH_STENCIL) {
strb = st_renderbuffer(fb-_DepthBuffer);
}
- else if (texBaseFormat == GL_DEPTH_STENCIL_EXT) {
- strb = st_renderbuffer(fb-_StencilBuffer);
- }
else {
/* texBaseFormat == GL_RGB, GL_RGBA, GL_ALPHA, etc */
strb = st_renderbuffer(fb-_ColorReadBuffer);
From 23a8a4fdc2848be822c9884d2b758909287e9a6e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Tue, 3 Nov 2009 16:16:05 +0100
Subject: [PATCH] mesa/st: clip pixels in draw_stencil_pixels to avoid crash
---
src/mesa/state_tracker/st_cb_drawpixels.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c b/src/mesa/state_tracker/st_cb_drawpixels.c
index 0a6bfcd..1d33e81 100644
--- a/src
[Mesa3d-dev] [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer
Hi,
the attached patch fixes a possible crash in function draw_stencil_pixels in
mesa/state_tracker. I've also updated the list of formats we read from to
prevent an assertion failing later in the code.
This makes glean/depthStencil work on r300g and softpipe.
Best regards
Marek Olšák
From 2b79c8adc5a92410cdfe4ae8c15880a73f839159 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sat, 31 Oct 2009 19:38:29 +0100
Subject: [PATCH] mesa/st: fix crash when drawing stencil pixels outside the drawbuffer
Also, add a missing depth-stencil format to the list of formats we want
to read from.
---
src/mesa/state_tracker/st_cb_drawpixels.c |6 ++
src/mesa/state_tracker/st_cb_texture.c|3 ++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c b/src/mesa/state_tracker/st_cb_drawpixels.c
index 0a6bfcd..0699404 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -669,6 +669,12 @@ draw_stencil_pixels(GLcontext *ctx, GLint x, GLint y,
strb = st_renderbuffer(ctx-DrawBuffer-
Attachment[BUFFER_STENCIL].Renderbuffer);
+ /* Do not draw outside the drawbuffer */
+ if (x + width ctx-DrawBuffer-Width)
+ width = ctx-DrawBuffer-Width - x;
+ if (y + height ctx-DrawBuffer-Height)
+ height = ctx-DrawBuffer-Height - y;
+
if (st_fb_orientation(ctx-DrawBuffer) == Y_0_TOP) {
y = ctx-DrawBuffer-Height - y - height;
}
diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c
index 878a40f..6f287ff 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1309,7 +1309,8 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum target, GLint level,
srcX, srcY,
width, height);
- if (baseFormat == GL_DEPTH_COMPONENT
+ if ((baseFormat == GL_DEPTH_COMPONENT ||
+baseFormat == GL_DEPTH24_STENCIL8)
pf_is_depth_and_stencil(stImage-pt-format))
transfer_usage = PIPE_TRANSFER_READ_WRITE;
else
--
1.6.3.3
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
