Re: [Mesa3d-dev] vgCreateFont
On Mon, 2010-12-06 at 00:09 -0800, Chia-I Wu wrote: On Fri, Dec 3, 2010 at 2:21 PM, Chia-I Wu olva...@gmail.com wrote: On Fri, Dec 3, 2010 at 3:39 AM, José Fonseca jfons...@vmware.com wrote: Hi Olv, Vega state tracker started failing to build on windows when I enabled Win32 threads everywhere. The problem is that windows.h defines CreateFont as CreateFontA. I looked at the code, but it was very hard to understand how to tackle this, due to the mixture of both C-preprocessor and Python scripted code generation makes things very obfuscated. Some ideas for the future: - The point of APIs like OpenVG having unique prefixes like vg is to prevent this sort of name collision, but these macros which concatenate the prefix/suffix end up defeating it. - Also given that we're using code generation, I think it would be better if we just generate everything from the python script without the c-preprocessor magic. Anyway, pretty nice seeing the VG state tracker getting love! I overlooked this issue while working on the dispatcher. I will make a switch to python scripts (or maybe simply use glapi). This should be fixed by 8f2a974cf2c9. The python script is rewritten to generate real C code. Excellent! Much easier to read and understand what the mapi_abi.py's output. Thanks. Jose -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] vgCreateFont
Hi Olv, Vega state tracker started failing to build on windows when I enabled Win32 threads everywhere. The problem is that windows.h defines CreateFont as CreateFontA. I looked at the code, but it was very hard to understand how to tackle this, due to the mixture of both C-preprocessor and Python scripted code generation makes things very obfuscated. Some ideas for the future: - The point of APIs like OpenVG having unique prefixes like vg is to prevent this sort of name collision, but these macros which concatenate the prefix/suffix end up defeating it. - Also given that we're using code generation, I think it would be better if we just generate everything from the python script without the c-preprocessor magic. Anyway, pretty nice seeing the VG state tracker getting love! Jose Forwarded Message mesa-mingw32 - Build # 4095 - Failure: Log: [...truncated 33 lines...] Compiling src/mapi/mapi/u_thread.c ... src/mapi/mapi/u_thread.c: In function ‘InsteadOf_exit’: src/mapi/mapi/u_thread.c:118: warning: unused variable ‘dwErr’ Compiling src/gallium/state_trackers/wgl/stw_context.c ... Linking build/windows-x86-debug/mapi/vgapi/libOpenVG.dll ... Compiling src/gallium/state_trackers/wgl/stw_device.c ... Compiling src/gallium/state_trackers/wgl/stw_ext_extensionsstring.c ... Compiling src/gallium/state_trackers/wgl/stw_ext_gallium.c ... Compiling src/gallium/state_trackers/wgl/stw_ext_pbuffer.c ... Compiling src/gallium/state_trackers/wgl/stw_ext_pixelformat.c ... Compiling src/gallium/state_trackers/wgl/stw_ext_swapinterval.c ... Compiling src/gallium/state_trackers/wgl/stw_framebuffer.c ... Compiling src/gallium/state_trackers/wgl/stw_getprocaddress.c ... Creating library file: build/windows-x86-debug/mapi/vgapi/liblibOpenVG.abuild/windows-x86-debug/mapi/vgapi/stub.o: In function `stub_fix_dynamic': /var/lib/hudson/jobs/mesa-mingw32/workspace/src/mapi/mapi/stub.c:180: undefined reference to `_vgCreateFontA' collect2: ld returned 1 exit status scons: *** [build/windows-x86-debug/mapi/vgapi/libOpenVG.dll] Error 1 scons: building terminated because of errors. [WARNINGS] Skipping publisher since build result is FAILURE Archiving artifacts Recording fingerprints Email was triggered for: Failure Sending email for trigger: Failure Changes: Changes for Build #4095 [José Fonseca] WIN32_THREADS - WIN32 -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ 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, 2010-09-06 at 16:31 -0700, Marek Olšák wrote: 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. Lets assume your hardware doesn't understand bgrx rendertargets formats natively, and you program it with the bgra format instead. If so then you must do these replacements in rgb_src_factor and rgb_dst_factor: PIPE_BLENDFACTOR_DST_ALPHA - PIPE_BLENDFACTOR_ONE; PIPE_BLENDFACTOR_INV_DST_ALPHA - PIPE_BLENDFACTOR_ZERO; PIPE_BLENDFACTOR_SRC_ALPHA_SATURATE - PIPE_BLENDFACTOR_ZERO; This will ensure that's written in the red, green, and blue components is consistent with a bgrx format (that is, destination alpha is always one -- incoming values are discarded). In this scenario, how you program alpha_src_factor/alpha_dst_factor is irrelevant, because they will only affect what's written in the padding bits, which is just padding -- it can and should be treated as gibberish. 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. IMO, there is no such thing as an operation using the padding bits. It is more like the contents of padding is undefined after/before any operation. And no operation should rely on it to have any particular value, by definition. Alpha blending of with a bgrx format should not (and needs not) to incorporate the padding bits for any computation. It may, however, write anything it feels like to the padding bits as a side effect. Now we could certainly impose the restriction in gallium that dst alpha blendfactors will produce undefined results for bgrx (and perhaps this is what you're arguing for). Then the burden of doing the replacements above shifts to the statetracker. I think Keith favors that stance. At any rate, going back to the original topic, I see no reason not to allow bgra - bgrx region_copy_regions. Also, for the record, in the moment arbitrary swizzles in the texture sampler bgrx formats became almost redundant. And I say almost because knowning that there is no alpha in the color buffer allows for certain optimizations (e.g., llvmpipe's swizzled layout separates the red, green, blue, and alpha channels into different 128bit words
[Mesa3d-dev] RFC: allow resource_copy_region between different (yet compatabile) formats
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 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 diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index 8250c30..5342fc2 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/context.rst @@ -263,9 +263,11 @@ apart from any 3D state in the context. Blitting functionality may be moved to a separate abstraction at some point in the future. ``resource_copy_region`` blits a region of a subresource of a resource to a -region of another subresource of a resource, provided that both resources have the -same format. The source and destination may be the same resource, but overlapping -blits are not permitted. +region of another subresource of a resource, provided that both resources have +the same format, or compatible formats, i.e., 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. The source and destination +may be the same resource, but overlapping blits are not permitted. ``resource_resolve`` resolves a multisampled resource into a non-multisampled one. Formats and dimensions must match. This function must be present if a driver -- 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, 2010-09-06 at 08:11 -0700, Roland Scheidegger wrote: On 06.09.2010 15:57, José Fonseca 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 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 José, this looks good to me. Note that the analogous function in d3d10, ResourceCopyRegion, only requires formats to be in the same typeless group (hence same number of bits for all components), which is certainly a broader set of compatible formats to what util_is_format_compatible() is outputting. As far as I can tell, no conversion is happening at all in d3d10, this is just like memcpy. I think we might want to support that in the future as well, but for now extending this to the formats you listed certainly sounds ok. Yes, that makes sense. Thanks for the feedback, Roland. 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
Re: [Mesa3d-dev] RFC: allow resource_copy_region between different (yet compatabile) formats
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 example llvmpipe (which needs to do that because the swizzled tile format is always bgra, so it needs to ignore destination alpha when bgrx surface is bound). I'm not sure what OpenGL defines, but DirectX/DCT definetely prescribes/enforces this behavior. 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. There is no alpha channel in b8g8r8x8 for anybody to write. The problem here is not what's written in the padding bits -- it is instead in making sure the padding bits are not interpreted as alpha. If the hardware *really* works better with 0xff in the padding bits, then that needs to be enforced not only in surface copy, but in transfers (i.e., when the transfer is unmapped, the pipe driver would need to fill padding bits with 0xff for every pixel. 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
Re: [Mesa3d-dev] RFC: allow resource_copy_region between different (yet compatabile) formats
On Mon, 2010-09-06 at 10:41 -0700, Luca Barbieri wrote: How about dropping the idea that resource_copy_region must be just a memcpy and have the driver instruct the hardware 2D blitter to write 1s in the alpha channel if supported by hw or have u_blitter do this in the shader? It's really different functionality. You're asking for a cast, as in b = (type)a; as in (int)1.0f = 1. Another thing is b = *(type *)a; as *(int *)1.0f = 0x3f80. This is my understanding of region_copy_region (previously known as surface_copy). And Roland provided a compelling argument for that. Both these functionality are exposed by APIs, and neither is a superset of the other. 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
Re: [Mesa3d-dev] LLVM and udis86 dependencies
On Mon, 2010-05-03 at 01:42 -0700, Török Edwin wrote: On 05/03/2010 11:36 AM, mesa3d-dev-requ...@lists.sourceforge.net wrote: From: Francis Galiegue fgalie...@gmail.com Subject: [Mesa3d-dev] LLVM and udis86 dependencies To: mesa3d-dev@lists.sourceforge.net Message-ID: x2zac542ca01004280420u3fbcee55rcab4ffd573fb...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 In the current HEAD, in configure.ac: 1182-[enable_gallium=yes]) 1183-if test x$enable_gallium = xyes; then 1184-SRC_DIRS=$SRC_DIRS gallium gallium/winsys gallium/targets 1185:AC_CHECK_HEADER([udis86.h], [HAS_UDIS86=yes], 1186-[HAS_UDIS86=no]) 1187-AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) 1188-fi -- 1340- LLVM_LIBS=`$LLVM_CONFIG --libs jit interpreter nativecodegen bitwriter` -lstdc++ 1341- 1342- if test x$HAS_UDIS86 != xno; then 1343: LLVM_LIBS=$LLVM_LIBS -ludis86 1344- DEFINES=$DEFINES -DHAVE_UDIS86 1345- fi 1346- LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` This means basically that the udis86 dependency is automagic if you elect to build with LLVM support. I have a case here of a miscompiled udis86 (missing -fPIC, preventing relocation) on a setup where LLVM was NOT compiled with udis86. Would it be possible to make the udis86 dependency optional (ie, --with-udis86 option to ./configure)? LLVM 2.7 includes a disassembler of its own (libEnhancedDisassembly.so), could that one be used instead of udis86? Yes, that would be nice. udis86 seems a bit unmaintained a the moment. I've sent a few patches for some SSE4 opcodes to the maintainer and they weren't checked in yet. I thought about bundling its source in mesa, but when I saw news of LLVM's disassembler plans I thought it was better to wait. But I don't have time to look into this myself. If you don't have time either then a simple patch to make udis86 optional should be good enough for now. Jose -- ___ 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, 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 weird paths. Same for YUV. Jose -- ___ Mesa3d-dev mailing
Re: [Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
On Mon, 2010-05-03 at 05:18 -0700, Marek Olšák wrote: 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
Re: [Mesa3d-dev] Mesa (gallium-msaa): gallium: interface changes for multisampling
Hi Roland,
Overall looks good. It's nice to finally have a way to export MSAA
capabilities, and see the pipe_surfaces use being more constrained.
A few comments inline, but no strong feelings so feel free to do as you
wish.
Jose
On Mon, 2010-04-26 at 11:05 -0700, Roland Scheidegger wrote:
Module: Mesa
Branch: gallium-msaa
Commit: aac2cfd701ae8d7ce0813c28c64498d4a076
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=aac2cfd701ae8d7ce0813c28c64498d4a076
Author: Roland Scheidegger srol...@vmware.com
Date: Mon Apr 26 19:50:57 2010 +0200
gallium: interface changes for multisampling
add function to set sample mask, and state for alpha-to-coverage and
alpha-to-one. Also make it possible to query for supported sample count
with is_msaa_supported().
Use explicit resource_resolve() to resolve a resource. Note that it is illegal
to bind a unresolved resource as a sampler view, must be resolved first (as
per
d3d10 and OGL APIs, binding unresolved resource would mean that special
texture
fetch functions need to be used which give explicit control over what samples
to fetch, which isn't supported yet).
Also change surface_fill() and surface_copy() to operate directly on
resources.
Blits should operate directly on resources, most often state trackers just
used
get_tex_surface() then did a blit. Note this also means the blit bind flags
are
gone, if a driver implements this functionality it is expected to handle it
for
all resources having depth_stencil/render_target/sampler_view bind flags
(might
even require it for all bind flags?).
Might want to introduce quality levels for MSAA later.
Might need to revisit this for hw which does instant resolve.
---
src/gallium/auxiliary/cso_cache/cso_context.c | 11 +
src/gallium/auxiliary/cso_cache/cso_context.h |2 +
src/gallium/docs/source/context.rst | 16 +--
src/gallium/docs/source/screen.rst| 13 +-
src/gallium/include/pipe/p_context.h | 51 +---
src/gallium/include/pipe/p_defines.h |2 -
src/gallium/include/pipe/p_screen.h | 11 +-
src/gallium/include/pipe/p_state.h|2 +
8 files changed, 82 insertions(+), 26 deletions(-)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 6d0b420..50736f0 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -98,6 +98,7 @@ struct cso_context {
struct pipe_framebuffer_state fb, fb_saved;
struct pipe_viewport_state vp, vp_saved;
struct pipe_blend_color blend_color;
+ unsigned sample_mask sample_mask;
This doesn't look correct. sample_mask appears twice.
struct pipe_stencil_ref stencil_ref, stencil_ref_saved;
};
@@ -984,6 +985,16 @@ enum pipe_error cso_set_blend_color(struct cso_context
*ctx,
return PIPE_OK;
}
+enum pipe_error cso_set_sample_mask(struct cso_context *ctx,
+unsigned sample_mask)
+{
+ if (ctx-sample_mask != sample_mask) {
+ ctx-sample_mask = sample_mask;
+ ctx-pipe-set_sample_mask(ctx-pipe, sample_mask);
+ }
+ return PIPE_OK;
+}
+
enum pipe_error cso_set_stencil_ref(struct cso_context *ctx,
const struct pipe_stencil_ref *sr)
{
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h
b/src/gallium/auxiliary/cso_cache/cso_context.h
index d6bcb1f..f0b07f7 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -159,6 +159,8 @@ void cso_restore_viewport(struct cso_context *cso);
enum pipe_error cso_set_blend_color(struct cso_context *cso,
const struct pipe_blend_color *bc);
+enum pipe_error cso_set_sample_mask(struct cso_context *cso,
+unsigned stencil_mask);
enum pipe_error cso_set_stencil_ref(struct cso_context *cso,
const struct pipe_stencil_ref *sr);
diff --git a/src/gallium/docs/source/context.rst
b/src/gallium/docs/source/context.rst
index c82e681..374711b 100644
--- a/src/gallium/docs/source/context.rst
+++ b/src/gallium/docs/source/context.rst
@@ -54,6 +54,7 @@ objects. They all follow simple, one-method binding calls,
e.g.
* ``set_stencil_ref`` sets the stencil front and back reference values
which are used as comparison values in stencil test.
* ``set_blend_color``
+* ``set_sample_mask``
* ``set_clip_state``
* ``set_polygon_stipple``
* ``set_scissor_state`` sets the bounds for the scissor test, which culls
@@ -255,15 +256,20 @@ Blitting
These methods emulate classic blitter controls. They are not guaranteed to be
available; if they are set to NULL, then they are not present.
-These methods operate directly on ``pipe_surface`` objects,
Re: [Mesa3d-dev] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags
On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote: On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote: On 09.04.2010 17:49, Keith Whitwell wrote: On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote: Module: Mesa Branch: gallium-resources Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf Author: Roland Scheidegger srol...@vmware.com Date: Fri Apr 9 17:44:24 2010 +0200 gallium: fix comments for changed USAGE flags --- src/gallium/auxiliary/util/u_simple_screen.h |9 + src/gallium/drivers/svga/svga_winsys.h| 10 -- src/gallium/include/pipe/p_screen.h |2 +- src/gallium/include/state_tracker/sw_winsys.h |2 +- 4 files changed, 11 insertions(+), 12 deletions(-) diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h index 0042277..1ba59af 100644 --- a/src/gallium/auxiliary/util/u_simple_screen.h +++ b/src/gallium/auxiliary/util/u_simple_screen.h @@ -73,9 +73,10 @@ struct pipe_winsys * window systems must then implement that interface (rather than the * other way around...). * -* usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This -* usage argument is only an optimization hint, not a guarantee, therefore -* proper behavior must be observed in all circumstances. +* usage is a bitmask of PIPE_BIND_*. +* XXX is this true? +* This usage argument is only an optimization hint, not a guarantee, +* therefore proper behavior must be observed in all circumstances. The new flags are no longer hints - they are supposed actually specify which operations are permitted on a resource. Unfortunately I don't think this is very well enforced yet -- I intend to add a debug layer to sit between state-tracker and driver, based on the drivers/identity layer, which will check for violations of this other rules. Ok, I thought this to be the case, but wasn't sure. I'll fix the comment. In the svga code, I actually couldn't figure out the usage flags when a winsys buffer is created. It looks like usage is always 0, except for queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a resource but a winsys buffer, but as far as I can tell this ends up in a pb_buffer usage flag. Not sure if that's ok or supposed to be like that... Jose has looked at this more recently than I have... pb_buffer sits between pipe driver and the winsys, and needs to pass custom buffer flags unmodified from svga to the winsys. SVGA_BUFFER_USAGE_PINNED is one of those usages. PIPE_BIND_* don't matter at this level. What matters at the pipebuffer level is CPU/GPU READ/WRITE flags. Perhaps it might make sense to modify pipebuffer and its users to use pipebuffer specifc PB_BUFFER_*** flags instead of the gallium ones. 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] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags
On Fri, 2010-04-09 at 09:22 -0700, José Fonseca wrote: On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote: On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote: On 09.04.2010 17:49, Keith Whitwell wrote: On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote: Module: Mesa Branch: gallium-resources Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf Author: Roland Scheidegger srol...@vmware.com Date: Fri Apr 9 17:44:24 2010 +0200 gallium: fix comments for changed USAGE flags --- src/gallium/auxiliary/util/u_simple_screen.h |9 + src/gallium/drivers/svga/svga_winsys.h| 10 -- src/gallium/include/pipe/p_screen.h |2 +- src/gallium/include/state_tracker/sw_winsys.h |2 +- 4 files changed, 11 insertions(+), 12 deletions(-) diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h index 0042277..1ba59af 100644 --- a/src/gallium/auxiliary/util/u_simple_screen.h +++ b/src/gallium/auxiliary/util/u_simple_screen.h @@ -73,9 +73,10 @@ struct pipe_winsys * window systems must then implement that interface (rather than the * other way around...). * -* usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This -* usage argument is only an optimization hint, not a guarantee, therefore -* proper behavior must be observed in all circumstances. +* usage is a bitmask of PIPE_BIND_*. +* XXX is this true? +* This usage argument is only an optimization hint, not a guarantee, +* therefore proper behavior must be observed in all circumstances. The new flags are no longer hints - they are supposed actually specify which operations are permitted on a resource. Unfortunately I don't think this is very well enforced yet -- I intend to add a debug layer to sit between state-tracker and driver, based on the drivers/identity layer, which will check for violations of this other rules. Ok, I thought this to be the case, but wasn't sure. I'll fix the comment. In the svga code, I actually couldn't figure out the usage flags when a winsys buffer is created. It looks like usage is always 0, except for queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a resource but a winsys buffer, but as far as I can tell this ends up in a pb_buffer usage flag. Not sure if that's ok or supposed to be like that... Jose has looked at this more recently than I have... pb_buffer sits between pipe driver and the winsys, and needs to pass custom buffer flags unmodified from svga to the winsys. SVGA_BUFFER_USAGE_PINNED is one of those usages. PIPE_BIND_* don't matter at this level. What matters at the pipebuffer level is CPU/GPU READ/WRITE flags. Perhaps it might make sense to modify pipebuffer and its users to use pipebuffer specifc PB_BUFFER_*** flags instead of the gallium ones. It's already done. Nevermind. 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] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags
On Fri, 2010-04-09 at 09:57 -0700, Roland Scheidegger wrote: On 09.04.2010 18:22, José Fonseca wrote: On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote: On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote: On 09.04.2010 17:49, Keith Whitwell wrote: On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote: Module: Mesa Branch: gallium-resources Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf Author: Roland Scheidegger srol...@vmware.com Date: Fri Apr 9 17:44:24 2010 +0200 gallium: fix comments for changed USAGE flags --- src/gallium/auxiliary/util/u_simple_screen.h |9 + src/gallium/drivers/svga/svga_winsys.h| 10 -- src/gallium/include/pipe/p_screen.h |2 +- src/gallium/include/state_tracker/sw_winsys.h |2 +- 4 files changed, 11 insertions(+), 12 deletions(-) diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h index 0042277..1ba59af 100644 --- a/src/gallium/auxiliary/util/u_simple_screen.h +++ b/src/gallium/auxiliary/util/u_simple_screen.h @@ -73,9 +73,10 @@ struct pipe_winsys * window systems must then implement that interface (rather than the * other way around...). * -* usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This -* usage argument is only an optimization hint, not a guarantee, therefore -* proper behavior must be observed in all circumstances. +* usage is a bitmask of PIPE_BIND_*. +* XXX is this true? +* This usage argument is only an optimization hint, not a guarantee, +* therefore proper behavior must be observed in all circumstances. The new flags are no longer hints - they are supposed actually specify which operations are permitted on a resource. Unfortunately I don't think this is very well enforced yet -- I intend to add a debug layer to sit between state-tracker and driver, based on the drivers/identity layer, which will check for violations of this other rules. Ok, I thought this to be the case, but wasn't sure. I'll fix the comment. In the svga code, I actually couldn't figure out the usage flags when a winsys buffer is created. It looks like usage is always 0, except for queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a resource but a winsys buffer, but as far as I can tell this ends up in a pb_buffer usage flag. Not sure if that's ok or supposed to be like that... Jose has looked at this more recently than I have... pb_buffer sits between pipe driver and the winsys, and needs to pass custom buffer flags unmodified from svga to the winsys. SVGA_BUFFER_USAGE_PINNED is one of those usages. So the svga winsys buffer_create function takes only custom flags, none of the PB_USAGE ones? Yep. That's right. All SVGA winsys buffers are identical in nature apart from the pinned vs unpinned. All winsys buffers allow for full CPU and GPU access, so these are ignored. This is the idea I got from the code (plus the custom flags would clearly overlap with the generic ones), and hence what I updated the comment to (which clearly was wrong). I'm not sure though this really works with the pb code I thought it might do some checks on the usage flags there but if you say it works then I better believe it... pb code does look into those flags. But I believe it pays more attention to the same kind of flags that are passed when mapping and validation time than the ones passed at buffer creation time. Anwyay, this is just from skimming the code. I did not have time to test gallium resources's svga pipe driver yet. 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
[Mesa3d-dev] RFC: Add missing D3D9 color formats
The attached patch adds missing D3D9 color formats. We've been going back and forward whether to add these or not, but the end conclusion seems there is no harm to add these formats, no matter how weird some are, as state tracker and pipe drivers are free to ignore them. The util module should support all formats however, for everybody's convenience. I'll submit more code for these once this patches go in. If I'm not mistaken, the only missing D3D9 formats are some depth stencil plus some video formats (e.g. NV12). I did not bother to add these yet, given I have no pressing need. Jose diff --git a/src/gallium/auxiliary/util/u_format.csv b/src/gallium/auxiliary/util/u_format.csv index f23352f..6b89a84 100644 --- a/src/gallium/auxiliary/util/u_format.csv +++ b/src/gallium/auxiliary/util/u_format.csv @@ -72,11 +72,13 @@ PIPE_FORMAT_B5G5R5A1_UNORM, plain, 1, 1, un5 , un5 , un5 , un1 , zyxw, r PIPE_FORMAT_B4G4R4A4_UNORM, plain, 1, 1, un4 , un4 , un4 , un4 , zyxw, rgb PIPE_FORMAT_B5G6R5_UNORM , plain, 1, 1, un5 , un6 , un5 , , zyx1, rgb PIPE_FORMAT_R10G10B10A2_UNORM , plain, 1, 1, un10, un10, un10, un2 , xyzw, rgb +PIPE_FORMAT_B10G10R10A2_UNORM , plain, 1, 1, un10, un10, un10, un2 , zyxw, rgb # Luminance/Intensity/Alpha formats PIPE_FORMAT_L8_UNORM , plain, 1, 1, un8 , , , , xxx1, rgb PIPE_FORMAT_A8_UNORM , plain, 1, 1, un8 , , , , 000x, rgb PIPE_FORMAT_I8_UNORM , plain, 1, 1, un8 , , , , , rgb +PIPE_FORMAT_L4A4_UNORM, plain, 1, 1, un4 , un4 , , , xxxy, rgb PIPE_FORMAT_L8A8_UNORM, plain, 1, 1, un8 , un8 , , , xxxy, rgb PIPE_FORMAT_L16_UNORM , plain, 1, 1, un16, , , , xxx1, rgb @@ -94,6 +96,7 @@ PIPE_FORMAT_X8R8G8B8_SRGB , plain, 1, 1, x8 , un8 , un8 , un8 , yzw1, s # Mixed-sign formats (typically used for bump map textures) PIPE_FORMAT_R8SG8SB8UX8U_NORM , plain, 1, 1, sn8 , sn8 , un8 , x8 , xyz1, rgb +PIPE_FORMAT_R10SG10SB10SA2U_NORM , plain, 1, 1, sn10, sn10, sn10, un2 , xyzw, rgb PIPE_FORMAT_R5SG5SB6U_NORM, plain, 1, 1, sn5 , sn5 , un6 , , xyz1, rgb # Depth-stencil formats @@ -121,6 +124,8 @@ PIPE_FORMAT_R10G10B10A2_USCALED , plain, 1, 1, u10 , u10 , u10 , u2 , x PIPE_FORMAT_R11G11B10_FLOAT , plain, 1, 1, f11 , f11 , f10 , , xyz1, rgb PIPE_FORMAT_R9G9B9E5_FLOAT, other, 1, 1, x32 , , , , xyz1, rgb PIPE_FORMAT_R1_UNORM , other, 8, 1, x8 , , , , x001, rgb +# A.k.a. D3DFMT_CxV8U8 +PIPE_FORMAT_R8G8Bx_SNORM , other, 1, 1, sn8 , sn8 , , , xyz1, rgb # Compressed formats # - http://en.wikipedia.org/wiki/S3_Texture_Compression @@ -171,10 +176,6 @@ PIPE_FORMAT_R32_SSCALED , plain, 1, 1, s32 , , , , x001, r PIPE_FORMAT_R32G32_SSCALED, plain, 1, 1, s32 , s32 , , , xy01, rgb PIPE_FORMAT_R32G32B32_SSCALED , plain, 1, 1, s32 , s32 , s32 , , xyz1, rgb PIPE_FORMAT_R32G32B32A32_SSCALED , plain, 1, 1, s32 , s32 , s32 , s32 , xyzw, rgb -PIPE_FORMAT_R32_FIXED , plain, 1, 1, h32 , , , , x001, rgb -PIPE_FORMAT_R32G32_FIXED , plain, 1, 1, h32 , h32 , , , xy01, rgb -PIPE_FORMAT_R32G32B32_FIXED , plain, 1, 1, h32 , h32 , h32 , , xyz1, rgb -PIPE_FORMAT_R32G32B32A32_FIXED, plain, 1, 1, h32 , h32 , h32 , h32 , xyzw, rgb PIPE_FORMAT_R16_FLOAT , plain, 1, 1, f16 , , , , x001, rgb PIPE_FORMAT_R16G16_FLOAT , plain, 1, 1, f16 , f16 , , , xy01, rgb PIPE_FORMAT_R16G16B16_FLOAT , plain, 1, 1, f16 , f16 , f16 , , xyz1, rgb @@ -211,3 +212,18 @@ PIPE_FORMAT_R8_SSCALED, plain, 1, 1, s8 , , , , x001, r PIPE_FORMAT_R8G8_SSCALED , plain, 1, 1, s8 , s8 , , , xy01, rgb PIPE_FORMAT_R8G8B8_SSCALED, plain, 1, 1, s8 , s8 , s8 , , xyz1, rgb PIPE_FORMAT_R8G8B8A8_SSCALED , plain, 1, 1, s8 , s8 , s8 , s8 , xyzw, rgb + +# GL-specific vertex buffer element formats +# A.k.a. GL_FIXED +PIPE_FORMAT_R32_FIXED , plain, 1, 1, h32 , , , , x001, rgb +PIPE_FORMAT_R32G32_FIXED , plain, 1, 1, h32 , h32 , , , xy01, rgb +PIPE_FORMAT_R32G32B32_FIXED , plain, 1, 1, h32 , h32 , h32 , , xyz1, rgb +PIPE_FORMAT_R32G32B32A32_FIXED, plain, 1, 1, h32 , h32 , h32 , h32 , xyzw, rgb + +# D3D9-specific vertex buffer element formats +# See also: +# - http://msdn.microsoft.com/en-us/library/bb172533.aspx +# A.k.a. D3DDECLTYPE_UDEC3 +PIPE_FORMAT_R10G10B10X2_USCALED , plain, 1, 1, u10 , u10 , u10 , x2 , xyz1, rgb +# A.k.a. D3DDECLTYPE_DEC3N +PIPE_FORMAT_R10G10B10X2_SNORM , plain, 1, 1, sn10, sn10, sn10 , x2 , xyz1, rgb diff --git a/src/gallium/include/pipe/p_format.h b/src/gallium/include/pipe/p_format.h index c7a90a0..a919809 100644 ---
Re: [Mesa3d-dev] GSOC: Gallium R300 driver
On Tue, 2010-03-30 at 08:37 -0700, Luca Barbieri 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... 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. It would be nice to have a driver-independent TGSI optimization module. It could either operate directly on TGSI (probably only good for simple optimization), or convert to LLVM IR, optimize, and convert back. This would allow to use this for all drivers: note that at least inlining and loop unrolling should generally be performed even for hardware with full control flow support. Lots of other optimizations would then be possible (using LLVM, with a single line of code to request the appropriate LLVM pass), and would automatically be available for all drivers, instead of being only available for r300 by putting them in the radeon compiler. Agreed. These were my thoughts too when watching Nicolai Haehnle's FOSDEM presentation. In my opinion the best would be to use a SSA form of TGSI, with possibility for annotations or ability to have hardware specific instructions, so that the drivers could faithfully represent all the oddities in certain hardware. There are several deep challenges in making TGSI - LLVM IR translation lossless -- I'm sure we'll get around to overcome them -- but I don't think that using LLVM is a requirement for this module. Having a shared IR for simple TGSI optimization module would go a long way by itself. 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] GSOC: Gallium R300 driver
On Tue, 2010-03-30 at 09:52 -0700, Luca Barbieri wrote: There are several deep challenges in making TGSI - LLVM IR translation lossless -- I'm sure we'll get around to overcome them -- but I don't think that using LLVM is a requirement for this module. Having a shared IR for simple TGSI optimization module would go a long way by itself. What are these challenges? - Control flow as you mentioned -- gets broken into jump spaghetti. - Predicates can't be represented -- you need to use AND / NAND masking. I know people have asked support for this in the LLVM list so it might change someday. - missing intrinsics -- TGSI has a much richer instruction set than LLVM's builtin instructions, so it would be necessary to add several llvm.tgsi.xxx instrinsics (e.g., for max, min, madd, exp2, log2, etc), and teach LLVM to do constant propagation for every single one of them. - Constants -- you often want to make specialized version of shaders for certain constants, especially when you have control flow statements whose arguments are constants (e.g., when doing TNL with a big glsl shader), and therefore should be factored out. You also may want to do factor out constant operations (e.g., MUL TEMP[1], CONST[0], CONST[1]) But LLVM can't help you with that given that for LLVM IR constants are ordinary memory, like the inputs. LLVM doesn't know that a shader will be invoked million of times with the same constants but varying inputs. If people can make this TGSI optimization module work quickly on top of LLVM then it's fine by me. I'm just pointing out that between the extreme of sharing nothing between each pipe driver compiler, and sharing everything with LLVM, there's a middle ground which is sharing between pipe drivers but not LLVM. Once that module exists having it use LLVM internally would then be pretty easy. It looks to me a better way to parallize the effort than to be blocked for quite some time on making TGSI - LLVM IR be lossless. At any rate, in my book whoever does the job gets to choose. I won't have any time to put into it unfortunately, so feel free to ignore me. 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] gallium cached bufmgr busy change
On Tue, 2010-03-23 at 02:07 -0700, Dave Airlie wrote:
On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca jfons...@vmware.com wrote:
Dave,
I don't oppose this new method -- it shouldn't be necessary to add fencing
just to use pb_cache --, but this method adds a new way of doing the same
thing.
Does the underlying buffer support PIPE_BUFFER_USAGE_DONT_BLOCK? If so what
about doing:
boolean
pb_cache_is_buffer_compat()
{
void map;
map = pb_map(buf-buffer, PIPE_BUFFER_USAGE_DONT_BLOCK | PIPE_BUFFER);
if (map) {
/* TODO: cache the map value for the first map */
pb_unmap(buf-buffer);
return TRUE;
}
return FALSE;
}
Hi Jose
I've used your scheme but I'm not sure 100% of its correctness since
we might expect
different behaviour from maps that are referenced in flushed command
streams and maps
referenced in the current command stream. I've pushed the r300g bits
that do it correctly and
we haven't seen any regressions.
Hi Dave,
I'm fine with adding an is_busy method as your original implementation
if you find it useful. And we could provide a default implementation
thatr uses PIPE_BUFFER_USAGE_DONT_BLOCK map/unmap to check.
So my next bit is to bail out after is_busy check to avoid kernel
overheads for checking all
the buffers, but I'm a bit worried it might change behaviour of the
fenced/cached use case,
so I'd appreciate a bit of a review of it.
It looks good to me.
It would benefit readability to split the is_busy parts of
pb_cache_is_buffer_compat() into a new pb_cache_is_buffer_busy()
function but it is purely cosmetic.
If this isn't possible I'm tempted to create pb_bufmgr_busy_cached and
do it all there,
I think nouveau could use something similiar.
I don't know if it's still relevant given your patch looks good to me,
but if so what would this pb_bufmgr_busy_cached function do exactly?
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] Separate demos repository
On Wed, 2010-03-24 at 15:11 -0700, Eric Anholt wrote: People that hang out on IRC have probably heard about my build system work. One of the first steps I've been working on finishing is splitting out the demos repository. We're currently distributing the Mesa progs/ separately from the main Mesa distribution, and most people aren't installing it, so from a distribution perspective it doesn't make sense to be in the same repository. On the other hand, for driver developers that are having to make clean on a regular basis, wiping out the programs (if you even use them) doesn't help since the programs aren't really changing. And if they are, when you're bisecting around trying an app, you don't want the app changing at the same time. I also think that separating the demos/tests is a sensible thing to do. One doesn't (re)build tests as often as the rest of the drivers, and GL, GL ES, VG, are all stable interfaces. So, I've made a branch in my Mesa repository for a split of the progs/ From Mesa. git://people.freedesktop.org/~anholt/mesa on the mesa-demos branch Open issues: Right now they don't install in general, but it would be easy to change if people are interested in a package that does. I've tested a bunch of them in tree and they seem fine. I've only tested the build on Linux with GL. The GLES stuff needs to get hooked up (I don't see a GLES implementation to test against or I would have). I don't know what to do about the progs/gallium. progs/gallium/unit looks like it should probably live in the Mesa tree next to the code that it's unit testing. progs/gallium/python/ though? Yes, all subdirs inside progs/gallium essentially have tests for gallium interfaces, so its contents should move to src/gallium/tests . None of the GLEW or GLUT is brought along with the apps. It looks to me like all OSes should have libGLEW and libfreeglut reasonably available. I'm not sure if we want the repository to contain all of previous Mesa history. Right now that history costs 145MB on disk for a deep checkout. If that's a problem for people, we could use the same tool that xcb did whose name I forget to to construct a history of just progs/ Probably git filter-branch. 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] Mesa (master): llvmpipe: fix up some questionable fence code
Brian,
Your fix is right. The last_fence variable was a remnant of some state
tracker code I based the change on, and had no place here.
Jose
On Wed, 2010-03-24 at 19:50 -0700, Brian Paul wrote:
Module: Mesa
Branch: master
Commit: 9a5241758231b2dd5ae757645158fa33051f5507
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9a5241758231b2dd5ae757645158fa33051f5507
Author: Brian Paul bri...@vmware.com
Date: Wed Mar 24 20:40:31 2010 -0600
llvmpipe: fix up some questionable fence code
Jose should probably review this since he wrote the original code.
---
src/gallium/drivers/llvmpipe/lp_flush.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_flush.c
b/src/gallium/drivers/llvmpipe/lp_flush.c
index 636d72a..782669a 100644
--- a/src/gallium/drivers/llvmpipe/lp_flush.c
+++ b/src/gallium/drivers/llvmpipe/lp_flush.c
@@ -111,7 +111,6 @@ llvmpipe_flush_texture(struct pipe_context *pipe,
boolean cpu_access,
boolean do_not_flush)
{
- struct pipe_fence_handle *last_fence = NULL;
unsigned referenced;
referenced = pipe-is_texture_referenced(pipe, texture, face, level);
@@ -142,7 +141,7 @@ llvmpipe_flush_texture(struct pipe_context *pipe,
pipe-flush(pipe, flush_flags, fence);
- if (last_fence) {
+ if (fence) {
pipe-screen-fence_finish(pipe-screen, fence, 0);
pipe-screen-fence_reference(pipe-screen, fence, NULL);
}
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-commit
--
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] Merging gallium-st-api
On Tue, 2010-03-16 at 01:41 -0700, Chia-I Wu wrote:
On Tue, Mar 16, 2010 at 9:40 AM, Chia-I Wu olva...@gmail.com wrote:
On Mon, Mar 15, 2010 at 8:04 PM, Keith Whitwell kei...@vmware.com wrote:
I'm very happy to see it merged - it's a nice cleanup of the
state-tracker behaviours.
Great! I would like to do the merge later today.
Done.
I will go on to convert the remaining co state trackers, i.e. st/dri and
st/wgl, and hopefully drop st_public.h support soon.
olv,
I'm seeing an assertion failure with a softpipe/llvmpipe libGL.so
together with vncserver, running any GL application. (It appears to work
fine with a regular Xorg server).
I can't look into this immediately. Can you tell what's the problem?
Jose
Core was generated by `./glean --run results --overwrite --quick --tests
basic --visuals id == 33'.
Program terminated with signal 5, Trace/breakpoint trap.
#0 0x7fefb746b59a in _debug_assert_fail (expr=0x7fefb7b30157 0,
file=0x7fefb7b30110 src/gallium/state_trackers/glx/xlib/xm_api.c,
line=308, function=0x7fefb7b30430 choose_pixel_format)
at src/gallium/auxiliary/util/u_debug.c:201
in src/gallium/auxiliary/util/u_debug.c
#0 0x7fefb746b59a in _debug_assert_fail (expr=0x7fefb7b30157 0,
file=0x7fefb7b30110 src/gallium/state_trackers/glx/xlib/xm_api.c,
line=308, function=0x7fefb7b30430 choose_pixel_format)
at src/gallium/auxiliary/util/u_debug.c:201
No locals.
#1 0x7fefb7249adf in choose_pixel_format (v=0x2279fb0)
at src/gallium/state_trackers/glx/xlib/xm_api.c:308
native_byte_order = 1 '\001'
__FUNCTION__ = choose_pixel_format
#2 0x7fefb724a3a9 in XMesaCreateVisual (display=0x222ecb0,
visinfo=0x2238dd0, rgb_flag=1 '\001', alpha_flag=0 '\000',
db_flag=1 '\001', stereo_flag=0 '\000', ximage_flag=1 '\001',
depth_size=24, stencil_size=8, accum_red_size=16, accum_green_size=16,
accum_blue_size=16, accum_alpha_size=16, num_samples=0, level=0,
visualCaveat=32768) at src/gallium/state_trackers/glx/xlib/xm_api.c:712
xmdpy = 0x7fefb80473e0
v = 0x2279fb0
red_bits = 6
green_bits = 5
blue_bits = 5
alpha_bits = 0
__FUNCTION__ = XMesaCreateVisual
#3 0x7fefb724c0a1 in save_glx_visual (dpy=0x222ecb0, vinfo=0x2238dd0,
rgbFlag=1 '\001', alphaFlag=0 '\000', dbFlag=1 '\001',
stereoFlag=0 '\000', depth_size=24, stencil_size=8, accumRedSize=16,
accumGreenSize=16, accumBlueSize=16, accumAlphaSize=16, level=0,
numAuxBuffers=0) at src/gallium/state_trackers/glx/xlib/glx_api.c:241
ximageFlag = 1 '\001'
xmvis = 0x7fffec105a40
i = 1
comparePointers = 0 '\000'
#4 0x7fefb724c266 in create_glx_visual (dpy=0x222ecb0, visinfo=0x2238dd0)
at src/gallium/state_trackers/glx/xlib/glx_api.c:325
zBits = 16
accBits = 16
alphaFlag = 0 '\000'
#5 0x7fefb724e5e9 in glXGetConfig (dpy=0x222ecb0, visinfo=0x2238dd0,
attrib=1, value=0x7fffec105c1c)
at src/gallium/state_trackers/glx/xlib/glx_api.c:1619
xmvis = 0x0
k = 0
#6 0x00418ef6 in WindowSystem (this=0x7fffec106178, o=...)
at glean/winsys.cpp:87
supportsOpenGL = 1
i = 1
error_base = 0
event_base = 0
vit = {visual = 0x222eb10, visualid = 140737153884488, screen = 0,
depth = 32767, c_class = 4242407, red_mask = 140737153884488,
green_mask = 35841728, blue_mask = 35842840,
colormap_size = -334470648, bits_per_rgb = 32767}
n = 2
glxv = {std::_Vector_baseGLEAN::DrawingSurfaceConfig*,
std::allocatorGLEAN::DrawingSurfaceConfig* = {
_M_impl = {std::allocatorGLEAN::DrawingSurfaceConfig* =
{__gnu_cxx::new_allocatorGLEAN::DrawingSurfaceConfig* = {No data fields},
No data fields}, _M_start = 0x2279430, _M_finish = 0x2279438,
_M_end_of_storage = 0x2279438}}, No data fields}
f = {condition = {std::_Vector_baseint, std::allocatorint = {
_M_impl = {std::allocatorint =
{__gnu_cxx::new_allocatorint = {No data fields}, No data fields},
_M_start = 0x7fffec106380,
_M_finish = 0x222e6c8,
_M_end_of_storage = 0x222eb18}}, No data fields},
sortKeys = {std::_Vector_baseGLEAN::DrawingSurfaceFilter::Token,
std::allocatorGLEAN::DrawingSurfaceFilter::Token = {
_M_impl = {std::allocatorGLEAN::DrawingSurfaceFilter::Token =
{__gnu_cxx::new_allocatorGLEAN::DrawingSurfaceFilter::Token = {No data
fields}, No data fields}, _M_start = 0x222e6c0, _M_finish = 0x7fffec106148,
_M_end_of_storage = 0x0}}, No data fields}, lex = {
input = 0x7fffec105ba0 ,
p = 0x40bd27
\311\303UH\211\345H\203\354\020H\211}\370H\211u\360H\213U\360H\213E\370H\211\326H\211\307\350\212\001,
ignoringCase = true,
token = GLEAN::Lex::ERROR, id = {
static npos = 18446744073709551615,
Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.
On Fri, 2010-03-12 at 06:08 -0800, michal wrote: Keith Whitwell wrote on 2010-03-12 14:46: Michal, Is the intention to have 1 sampler view active in the Mesa state tracker, specifically in the cases where min_lod varies? In other words, you seem to have two ways of specifying the same state: pipe_sampler_view::first_level and pipe_sampler::min_lod Is there a case to keep both of these? Or is one enough? It looks like one has to go away, and that would be pipe_sampler::min_lod. And we want to have a per-texture cache of sampler views in mesa. Yeah. There is hardware out there that is modeled after DX9 that doesn't support min_lod, which would be greatly simplified with this. 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] util_format cleanup leftover: Gallium BGRA vertex swizzles
On Thu, 2010-03-11 at 17:50 -0800, Marek Olšák wrote: 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, Well spotted. These were cases where formats were being used inconsistently in respect to their LSB-MSB vs MSB-LSB meanings and my automatic format rename did no more than flipping the inconsistency the otherway around. Looks good to me. I've went ahead and commited since I needed to fix up other state trackers. 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] util_format cleanup leftover: Gallium BGRA vertex swizzles
On Fri, 2010-03-12 at 08:17 -0800, Brian Paul wrote: Jose wrote: On Thu, 2010-03-11 at 17:50 -0800, Marek Olšák wrote: 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, Well spotted. These were cases where formats were being used inconsistently in respect to their LSB-MSB vs MSB-LSB meanings and my automatic format rename did no more than flipping the inconsistency the otherway around. Looks good to me. I've went ahead and commited since I needed to fix up other state trackers. Should this go into the 7.8 branch too, Jose? It's a cleanup -- it doesn't actually change behavior --, but I think it is better to port to 7.8 since cherrypicking future related fixes could end up having different effect on 7.8 branch. 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] [RFC] gallium-sampler-view branch merge
On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
Hi,
I would like to merge the branch in subject this week. This feature
branch allows state trackers to bind sampler views instead of textures
to shader stages.
A sampler view object holds a reference to a texture and also overrides
internal texture format (resource casting) and specifies RGBA swizzle
(needed for GL_EXT_texture_swizzle extension).
Yesterday I had to merge master into gallium-sampler-view -- the nv50
and r300 drivers had lots of conflicts. Could the maintainers of said
drivers had a look at them and see if they are still functional, please?
Thanks.
Michal,
Looks good overall. Minor comments below. Sorry if I rehash things that
have been already discussed. Feel free to ignore them.
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index 3a97d88..3c7c0a5 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -300,6 +300,24 @@ struct pipe_surface
/**
+ * A view into a texture that can be bound to a shader stage.
+ */
+struct pipe_sampler_view
+{
+ struct pipe_reference reference;
+ enum pipe_format format; /** typed PIPE_FORMAT_x */
I think it is worth to document that not all formats are valid here.
pipe_sampler_view::format and pipe_texture::format must be compatible.
The semantics of compatibility are a bit confusing though. Even DX10's.
At very least format's util_format_block must match.
RGB = SRGB variations should also be accepted. And sizzwle variations.
The difficulty is whether formats like A4R4G4B4 = A1G5R5B5 or
R8G8B8A8 = R32 should be accepted. I think hardware should have no
troubles with typecasting. So I'm inclined towards make this acceptible.
+ struct pipe_texture *texture; /** texture into which this is a view */
+ struct pipe_context *context; /** context this view belongs to */
Is this for debugging? No other state object has a pointer to context so far.
+ unsigned first_level:8; /** first mipmap level */
+ unsigned num_levels:8;/** number of mipamp levels */
I don't care much, but we've been using last_level instead of num_levels
elsewhere. Is there a particular reason to use num_levels here?
s/mipamp/mipmap/ in comment.
+ unsigned swizzle_r:3; /** PIPE_SWIZZLE_x for red component */
+ unsigned swizzle_g:3; /** PIPE_SWIZZLE_x for green component */
+ unsigned swizzle_b:3; /** PIPE_SWIZZLE_x for blue component */
+ unsigned swizzle_a:3; /** PIPE_SWIZZLE_x for alpha component */
+};
+
+
+/**
* Transfer object. For data transfer to/from a texture.
*/
struct pipe_transfer
diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
index b30a075..2df86a0 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
[...]
+struct pipe_sampler_view *
+llvmpipe_create_sampler_view(struct pipe_context *pipe,
+struct pipe_texture *texture,
+const struct pipe_sampler_view *templ)
+{
+ struct pipe_sampler_view *view = CALLOC_STRUCT(pipe_sampler_view);
Need to handle out of memory here.
+ *view = *templ;
+ view-reference.count = 1;
+ view-texture = NULL;
+ pipe_texture_reference(view-texture, texture);
+ view-context = pipe;
+
+ return view;
+}
The rest looks great to me. It's a very useful gallium interface change.
I particularly like how you eased migration with
cso_set_sampler_textures().
BTW, I noticed you commented out pipe video code. Everybody agreed on
removing it from master and mature pipe video on a branch, but we never
got around to do it. I'll remove this code in the next few days.
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] [RFC] gallium-sampler-view branch merge
On Thu, 2010-03-11 at 05:21 -0800, Keith Whitwell wrote: On Thu, 2010-03-11 at 03:16 -0800, michal wrote: Hi, I would like to merge the branch in subject this week. This feature branch allows state trackers to bind sampler views instead of textures to shader stages. A sampler view object holds a reference to a texture and also overrides internal texture format (resource casting) and specifies RGBA swizzle (needed for GL_EXT_texture_swizzle extension). Michal, I've got some issues with the way the sampler views are being generated and used inside the CSO module. The point of a sampler view is that it gives the driver an opportunity to do expensive operations required for special sampling modes (which may include copying surface data if hardware is deficient in some way). This approach works if a sampler view is created once, then used multiple times before being deleted. Unfortunately, it seems the changes to support this in the CSO module provide only a single-shot usage model. Sampler views are created in cso_set_XXX_sampler_textures, bound to the context, and then dereferenced/destroyed on the next bind. Although I endorse cso_set_XXX_sampler_textures for migration, I agree entirely with you. Perhaps we could make this clear in the comments. To make this change worthwhile, we'd want to somehow cache sampler views and reuse them on multiple draws. Currently drivers that implement views internally hang them off the relevant texture. The choices in this branch are to do it in the CSO module, or push it up to the state tracker. Caching in the cso module is certainly feasible, but regardless where it is done, care must be taken because the smapler view state includes texture pointers. Worse, it holds on to a texture reference. So at the very least the cso needs an entrypoint for flushing views for a given texture that will be called when the st is done with the texture. 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] [RFC] gallium-sampler-view branch merge
On Thu, 2010-03-11 at 06:21 -0800, michal wrote:
José Fonseca wrote on 2010-03-11 14:40:
On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
Hi,
I would like to merge the branch in subject this week. This feature
branch allows state trackers to bind sampler views instead of textures
to shader stages.
A sampler view object holds a reference to a texture and also overrides
internal texture format (resource casting) and specifies RGBA swizzle
(needed for GL_EXT_texture_swizzle extension).
Yesterday I had to merge master into gallium-sampler-view -- the nv50
and r300 drivers had lots of conflicts. Could the maintainers of said
drivers had a look at them and see if they are still functional, please?
Thanks.
Michal,
Looks good overall. Minor comments below. Sorry if I rehash things that
have been already discussed. Feel free to ignore them.
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index 3a97d88..3c7c0a5 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -300,6 +300,24 @@ struct pipe_surface
/**
+ * A view into a texture that can be bound to a shader stage.
+ */
+struct pipe_sampler_view
+{
+ struct pipe_reference reference;
+ enum pipe_format format; /** typed PIPE_FORMAT_x */
I think it is worth to document that not all formats are valid here.
pipe_sampler_view::format and pipe_texture::format must be compatible.
The semantics of compatibility are a bit confusing though. Even DX10's.
At very least format's util_format_block must match.
RGB = SRGB variations should also be accepted. And sizzwle variations.
The difficulty is whether formats like A4R4G4B4 = A1G5R5B5 or
R8G8B8A8 = R32 should be accepted. I think hardware should have no
troubles with typecasting. So I'm inclined towards make this acceptible.
How about all component sizes and order of components must match, and
the only difference can be in value type, that is one can convert
between SNORM, UNORM, SRGB, FLOAT, etc., as long as the base format is
the same (e.g. PIPE_FORMAT_R8G8B8A8)?
Yes, looking again, this does seem consistent with DX10's
DXGI_FORMAT_xx_TYPELESS formats.
What about GL's PBOs? I don't know much about them, but I heard that is
possible to use surfaces with a different format from what was original
created. Do you or anybody know how pipe sampler view could be used in
that case?
+ struct pipe_texture *texture; /** texture into which this is a view */
+ struct pipe_context *context; /** context this view belongs to */
Is this for debugging? No other state object has a pointer to context so
far.
Had this object been created by pipe_screen, it would have a reference
to a screen that created it. Sampler view is a first resource type
that is created by pipe_context.
We want to migrate other types to
pipe_context as well. I suppose once pipe_texture has a reference to
pipe_context, we could remove it from here, but in the meantime we will
need it in e.g. pipe_sampler_view_reference().
If it makes life easier then sounds good.
+ unsigned first_level:8; /** first mipmap level */
+ unsigned num_levels:8;/** number of mipamp levels */
I don't care much, but we've been using last_level instead of num_levels
elsewhere. Is there a particular reason to use num_levels here?
s/mipamp/mipmap/ in comment.
Makes sense, I will change it.
+ unsigned swizzle_r:3; /** PIPE_SWIZZLE_x for red component */
+ unsigned swizzle_g:3; /** PIPE_SWIZZLE_x for green component */
+ unsigned swizzle_b:3; /** PIPE_SWIZZLE_x for blue component */
+ unsigned swizzle_a:3; /** PIPE_SWIZZLE_x for alpha component */
+};
+
+
+/**
* Transfer object. For data transfer to/from a texture.
*/
struct pipe_transfer
diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
index b30a075..2df86a0 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
[...]
+struct pipe_sampler_view *
+llvmpipe_create_sampler_view(struct pipe_context *pipe,
+struct pipe_texture *texture,
+const struct pipe_sampler_view *templ)
+{
+ struct pipe_sampler_view *view = CALLOC_STRUCT(pipe_sampler_view);
Need to handle out of memory here.
Will fix it, thanks.
Thanks!
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
Re: [Mesa3d-dev] Compile error in xorg_crtc.c
On Thu, 2010-03-11 at 13:39 -0800, Johannes Obermayr wrote: STEVE555 wrote: If I leave out the xorg state tracker,it goes past fine until it comes up with this error I posted earlier: gmake[5]: Entering directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl' gcc -c -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dummy.c -o dummy.o gmake[5]: *** No rule to make target `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by `egl_x11_vmwgfx.so'. Stop. gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl' gmake[4]: *** [default] Error 1 gmake[4]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware' gmake[3]: *** [default] Error 1 gmake[3]: Leaving directory `/opt/mesa/src/gallium/winsys/drm' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/opt/mesa/src/gallium/winsys' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/opt/mesa/src' gmake: *** [default] Error 1 I'll try and wait if the latest packages get updated for xorg,but I might be tempted to bit the bullet and upgrade to Rawhide. Regards, STEVE555 There is also this error with latest git: gmake[5]: *** No rule to make target `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by `egl_x11_i915.so'. Stop. This is a build order issue. src/gallium/winsys should produce no shared objects. Just static libraries. src/gallium/targets should produce the final shared object targets. So the right build order is winsys then targets. But since we still have shared objects in src/gallium/winsys they might be built before the .as they depend upon. Perhaps tweaking order such way that winsys/drm comes after winsys/xlib will help. 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] Mesa (master): util: Code generate functions to pack and unpack a single pixel.
On Mon, 2010-03-08 at 04:25 -0800, Roland Scheidegger wrote:
On 07.03.2010 01:21, José Fonseca wrote:
On Sat, 2010-03-06 at 05:44 -0800, Brian Paul wrote:
On Sat, Mar 6, 2010 at 5:44 AM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
Author: José Fonseca jfons...@vmware.com
Date: Fri Feb 26 16:45:22 2010 +
util: Code generate functions to pack and unpack a single pixel.
Should work correctly for all pixel formats except SRGB formats.
Generated code made much simpler by defining the pixel format as
a C structure. For example this is the generated structure for
PIPE_FORMAT_B6UG5SR5S_NORM:
union util_format_b6ug5sr5s_norm {
uint16_t value;
struct {
int r:5;
int g:5;
unsigned b:6;
} chan;
};
José, are you aware that the memory layout of bitfields is mostly
implementation dependent? IME this makes them mostly unusable for
modelling hardware in a portable manner.
It's not only implementation dependent and slow -- it is also buggy!
gcc-4.4.3 is doing something very fishy to single bit fields.
See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
fine.
Am I missing something or is this effectively a bug?
Same result with gcc 4.4.1.
If pixel.chan.a is put into a temporary int var followed by the
scaling arithmetic it comes out as expected. Looks like a bug to me.
Thanks. I'll submit a bug report then.
BTW, it looks like sizeof(union util_format_b5g5r5a1_unorm) == 4, not 2.
Yet another reason to stay away from bit fields..
Hmm, might be because the bitfields are of type unsigned, not uint16_t?
It might. But typed bitfields (ie. anything other than 'int' or
'unsigned int') are not standard C. gcc -pedantic will complaint IIRC.
I've no idea though neither why it would return 01 and not ff.
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] Mesa (master): mesa: Export GL_EXT_texture_cube_map.
On Fri, 2010-03-05 at 16:16 -0800, Ian Romanick wrote: 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? Hi Ian, It was Adobe Photoshop CS4. It actually searches for both GL_ARB_texture_cube_map and GL_EXT_texture_cube_map, but somewhere along the way it ignores the former and outputs in a system information log: Cube Maps NOT SUPPORTED... It is quite possible that it is a bug in the system information output code, and the GL code actually uses cubemaps. But it is almost impossible to be sure, as Photoshop is very complex and has several distinct uses of OpenGL (e.g., effects, visualization, etc). And at any rate if an user would see the above message it would get legitimately worried. It seemed simpler just to list GL_EXT_texture_cube_map! I didn't think anyone ever actually shipped this extension. I guess Nvidia might have.. I don't have my NVIDIA machine handy, but I checked it before committing this and IIRC they indeed had this extension listed. 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] Mesa (master): util: Code generate functions to pack and unpack a single pixel.
On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
Author: José Fonseca jfons...@vmware.com
Date: Fri Feb 26 16:45:22 2010 +
util: Code generate functions to pack and unpack a single pixel.
Should work correctly for all pixel formats except SRGB formats.
Generated code made much simpler by defining the pixel format as
a C structure. For example this is the generated structure for
PIPE_FORMAT_B6UG5SR5S_NORM:
union util_format_b6ug5sr5s_norm {
uint16_t value;
struct {
int r:5;
int g:5;
unsigned b:6;
} chan;
};
José, are you aware that the memory layout of bitfields is mostly
implementation dependent? IME this makes them mostly unusable for
modelling hardware in a portable manner.
It's not only implementation dependent and slow -- it is also buggy!
gcc-4.4.3 is doing something very fishy to single bit fields.
See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
fine.
Am I missing something or is this effectively a bug?
Jose
#include stdint.h
#include string.h
#include stdio.h
union util_format_b5g5r5a1_unorm {
uint16_t value;
struct {
unsigned b:5;
unsigned g:5;
unsigned r:5;
unsigned a:1;
} chan;
};
void
util_format_b5g5r5a1_unorm_unpack_4ub(uint8_t *dst, const void *src)
{
union util_format_b5g5r5a1_unorm pixel;
memcpy(pixel, src, sizeof pixel);
dst[0] = (uint8_t)(((uint32_t)pixel.chan.r) * 0xff / 0x1f); /* r */
dst[1] = (uint8_t)(((uint32_t)pixel.chan.g) * 0xff / 0x1f); /* g */
dst[2] = (uint8_t)(((uint32_t)pixel.chan.b) * 0xff / 0x1f); /* b */
dst[3] = (uint8_t)(((uint32_t)pixel.chan.a) * 0xff / 0x1); /* a */
}
int main()
{
uint16_t packed = 0x;
uint8_t unpacked[4];
util_format_b5g5r5a1_unorm_unpack_4ub(unpacked, packed);
/* ff ff ff ff is expected, but ff ff ff 01 is printed */
printf(%02x %02x %02x %02x\n, unpacked[0], unpacked[1], unpacked[2], unpacked[3]);
return 0;
}
.file test.c
.text
.globl util_format_b5g5r5a1_unorm_unpack_4ub
.type util_format_b5g5r5a1_unorm_unpack_4ub, @function
util_format_b5g5r5a1_unorm_unpack_4ub:
pushl %ebp
movl%esp, %ebp
pushl %ebx
subl$36, %esp
movl$4, 8(%esp)
movl12(%ebp), %eax
movl%eax, 4(%esp)
leal-8(%ebp), %eax
movl%eax, (%esp)
callmemcpy
movzbl -7(%ebp), %eax
shrb$2, %al
andl$31, %eax
movzbl %al, %edx
movl%edx, %eax
sall$8, %eax
movl%eax, %ecx
subl%edx, %ecx
movl%ecx, -24(%ebp)
movl$138547333, -28(%ebp)
movl-28(%ebp), %eax
mull-24(%ebp)
movl%edx, %ecx
movl-24(%ebp), %eax
subl%ecx, %eax
shrl%eax
leal(%ecx,%eax), %eax
shrl$4, %eax
movl%eax, %edx
movl8(%ebp), %eax
movb%dl, (%eax)
movl8(%ebp), %eax
leal1(%eax), %ebx
movzwl -8(%ebp), %eax
shrw$5, %ax
andl$31, %eax
movzbl %al, %edx
movl%edx, %eax
sall$8, %eax
movl%eax, %ecx
subl%edx, %ecx
movl%ecx, -24(%ebp)
movl$138547333, -28(%ebp)
movl-28(%ebp), %eax
mull-24(%ebp)
movl%edx, %ecx
movl-24(%ebp), %eax
subl%ecx, %eax
shrl%eax
leal(%ecx,%eax), %eax
shrl$4, %eax
movb%al, (%ebx)
movl8(%ebp), %eax
leal2(%eax), %ebx
movzbl -8(%ebp), %eax
andl$31, %eax
movzbl %al, %edx
movl%edx, %eax
sall$8, %eax
movl%eax, %ecx
subl%edx, %ecx
movl%ecx, -24(%ebp)
movl$138547333, -28(%ebp)
movl-28(%ebp), %eax
mull-24(%ebp)
movl%edx, %ecx
movl-24(%ebp), %eax
subl%ecx, %eax
shrl%eax
leal(%ecx,%eax), %eax
shrl$4, %eax
movb%al, (%ebx)
movl8(%ebp), %eax
leal3(%eax), %ecx
movzbl -7(%ebp), %eax
shrb$7, %al
movzbl %al, %edx
movl%edx, %eax
sall$8, %eax
subl%edx, %eax
movb%al, (%ecx)
addl$36, %esp
popl%ebx
popl%ebp
ret
.size util_format_b5g5r5a1_unorm_unpack_4ub,
.-util_format_b5g5r5a1_unorm_unpack_4ub
.section.rodata
.LC0:
.string %02x %02x %02x
Re: [Mesa3d-dev] Mesa (master): util: Code generate functions to pack and unpack a single pixel.
On Sat, 2010-03-06 at 05:44 -0800, Brian Paul wrote:
On Sat, Mar 6, 2010 at 5:44 AM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
Author: José Fonseca jfons...@vmware.com
Date: Fri Feb 26 16:45:22 2010 +
util: Code generate functions to pack and unpack a single pixel.
Should work correctly for all pixel formats except SRGB formats.
Generated code made much simpler by defining the pixel format as
a C structure. For example this is the generated structure for
PIPE_FORMAT_B6UG5SR5S_NORM:
union util_format_b6ug5sr5s_norm {
uint16_t value;
struct {
int r:5;
int g:5;
unsigned b:6;
} chan;
};
José, are you aware that the memory layout of bitfields is mostly
implementation dependent? IME this makes them mostly unusable for
modelling hardware in a portable manner.
It's not only implementation dependent and slow -- it is also buggy!
gcc-4.4.3 is doing something very fishy to single bit fields.
See the attached code. ff ff ff ff is expected, but ff ff ff 01 is
printed with gcc-4.4.3. Even without any optimization. gcc-4.3.4 works
fine.
Am I missing something or is this effectively a bug?
Same result with gcc 4.4.1.
If pixel.chan.a is put into a temporary int var followed by the
scaling arithmetic it comes out as expected. Looks like a bug to me.
Thanks. I'll submit a bug report then.
BTW, it looks like sizeof(union util_format_b5g5r5a1_unorm) == 4, not 2.
Yet another reason to stay away from bit fields..
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] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
Consistency between different formats is not always a good metric here, as there are all sort of historical reasons which make the used set of formats out of all possible quite asymmetric. PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename. But I think you stumbled on something: PIPE_FORMAT_R8G8B8X8_SNORM might not be needed. It's not used anywhere, nor can I find mention of such format in D3D9/10. I'll remove it if nobody opposes. Jose From: Luca Barbieri [luca.barbi...@gmail.com] Sent: Tuesday, March 02, 2010 22:16 To: Jose Fonseca Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles) Shouldn't PIPE_FORMAT_X8B8G8R8_UNORM= 68, be instead R8G8B8X8_UNORM, which is currently missing, for consistency with: PIPE_FORMAT_R8G8B8X8_SNORM= 81, with X8B8G8R8_UNORM perhaps put at the end next to PIPE_FORMAT_A8B8G8R8_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] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote: PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename. How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM. Yes, you're right. BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5, D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, D3DFMT_D24X4S4, D3DFMT_CxV8U8 and perhaps others I did not notice. D3DFMT_L6V5U5 is there (PIPE_FORMAT_R5SG5SB6U_NORM). The others are indeed missing. Neither of the mentioned formats is required for D3D9 conformance, but we could add them to gallium. D3DFMT_A1 is special: it has less than 1 byte per pixel. Probably the best way to support it would be to treat it as a 8x1 macro pixel, 8bits, similarly to compressed formats. D3DFMT_CxV8U8 too as special semantics. 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
[Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
On Wed, 2010-02-24 at 08:19 -0800, José Fonseca wrote:
On Tue, 2010-02-23 at 09:20 -0800, José Fonseca 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_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.
I'm finished with my u_format* cleanups for now.
We have no unit tests for pixel formats yet so there might be some
regressions. Let me know.
As said in the bottom of u_format.csv, there are the formats with
unclear / inconsistent semantics:
# Ambiguous formats
# FIXME: They are used
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
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. 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] Gallium software fallback/draw command failure
On Sun, 2010-02-28 at 21:35 -0800, Corbin Simpson wrote:
On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie airl...@gmail.com wrote:
On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt b...@zhasha.com wrote:
On Sun, 2010-02-28 at 20:25 +0100, 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 ? :)
Cheers,
Jerome
I think a vital point you're missing is: do we even care? If rendering
fails because we simply can't render any more, do we even want to fall
back? I can see a point in having a cap on how large a buffer can be
rendered but apart from that, I'm not sure there even is a problem.
Welcome to GL. If I have a 32MB graphics card, and I advertise
a maximum texture size of 4096x4096 + cubemapping + 3D textures,
there is no nice way for the app to get a clue about what it can legally
ask me to do. Old DRI drivers used to either use texmem which would
try and scale the limits etc to what it could legally fit in the
memory available,
or with bufmgr drivers they would check against a limit from the kernel,
and in both cases sw fallback if necessary. Gallium seemingly can't do this,
maybe its okay to ignore it but it wasn't an option when we did the
old DRI drivers.
GL_ATI_meminfo is unfortunately the best bet. :C
Also Gallium's API is written so that drivers must never fail on
render calls. This is *incredibly* lame but there's nothing that can
be done. Every single driver is currently encouraged to just drop shit
on the floor if e.g. u_trim_pipe_prim fails, and every driver is
encouraged to call u_trim_pipe_prim, so we have stupidity like: if
(!u_trim_pipe_prim(mode, count)) { return; }
In EVERY SINGLE DRIVER. Most uncool. What's the point of a unified API
if it can't do sanity checks? :T
I don't see what sanity checking has to do with the topic of failing
draw calls.
Would
(!u_trim_pipe_prim(mode, count)) { return FALSE; }
make you any happier?
I think we all agree sanity checking should be done by the state
trackers. You're just confusing the result of common practices of
cut'n'pasting code and working around third-party problems in their code
with the encouraged design principles. I'm sure a patch to fix this
would be most welcome.
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] Gallium software fallback/draw command failure
On Mon, 2010-03-01 at 06:24 -0800, Olivier Galibert wrote: On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote: validate function i have in mind as virtualy a zero cost (it will boil down to a bunch of add followed by a test) and what validate would do would be done by draw operation anyway. Not would, will. You have no way to be sure nothing changed between validate and draw, pipe_contexts are not re-entrant. unless you're happy with an interface that will always be unusable for multithreading. So you'll do it twice for something that will always tell yes except once in a blue moon. The current procedure is: pipe-bind_this_state(); pipe-bind_that_state(); pipe-set_this_state(); pipe-set_that_state(); pipe-draw(); Making it pipe-bind_this_state(); pipe-bind_that_state(); pipe-set_this_state(); pipe-set_that_state(); if(pipe-validate() == PIPE_OUT_OF_MEMORY) return GL_OUT_OF_MEMORY; pipe-draw(); Makes it no better, no worse in terms of race conditions. 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] Mesa (gallium-format-cleanup): gallium: Remove inexisting formats.
On Mon, 2010-03-01 at 07:32 -0800, Jakob Bornecrantz wrote: On 1 mar 2010, at 15.23, Jose Fonseca wrote: Module: Mesa Branch: gallium-format-cleanup Commit: 4c3bfc9778d9a0a75bf93b15303a4839f971f695 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4c3bfc9778d9a0a75bf93b15303a4839f971f695 Author: José Fonseca jfons...@vmware.com Date: Mon Mar 1 15:17:41 2010 + gallium: Remove inexisting formats. Can't find these formats used in any state tracker or any API. For some of these probably the reverse notation was meant, for which formats already exist. src/gallium/state_trackers/xorg/xorg_exa.c:62 currently they aren't translated to Gallium formats and I wonder if the new swizzle state on the sampler views will solve this instead. hmm... There's a bunch of PICT_* formats there that could be translated to existing gallium formats and aren't. Is it even imperative that all formats are supported? It looks like some can't be supported by 3d hardware, even with swizzles. Also if swizlling is necessary it can and should be performed in the fragment shaders generated by the xorg state tracker. Anyway, this bears no relation with my change above, as all formats I removed were signed, and xorg makes no use of SNORM or SSCALED formats AFAICT. 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] Mesa (master): util: Code generate functions to pack and unpack a single pixel.
On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
Author: José Fonseca jfons...@vmware.com
Date: Fri Feb 26 16:45:22 2010 +
util: Code generate functions to pack and unpack a single pixel.
Should work correctly for all pixel formats except SRGB formats.
Generated code made much simpler by defining the pixel format as
a C structure. For example this is the generated structure for
PIPE_FORMAT_B6UG5SR5S_NORM:
union util_format_b6ug5sr5s_norm {
uint16_t value;
struct {
int r:5;
int g:5;
unsigned b:6;
} chan;
};
José, are you aware that the memory layout of bitfields is mostly
implementation dependent? IME this makes them mostly unusable for
modelling hardware in a portable manner.
No, I wasn't! I'm surprised -- they're used quite a lot.
Not used everywhere yet because it seems compiled code is slower than
bitshift arithmetic by some misterious reason. So we should generate
bitshift arithmetic at least for the simple UNORM pixel formats.
Due to above I'd recommend always using bitshift arithmetic rather than
bitfields anyway. :)
Yeah. I think I'll do just that. bitfields made generated code cleaner,
but if I have to implement bitshift arith for performance then might as
well do it for all formats that apply.
Thanks for the feedback.
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/mesa: do not advertise S3TC if the external lib is not available
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] mesa: remove libmesagallium.a on make clean
On Sat, 2010-02-27 at 13:55 -0800, Marcin Slusarz wrote: --- src/mesa/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/Makefile b/src/mesa/Makefile index 0cb49e8..8c0ebf8 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -154,7 +154,7 @@ tags: clean: -rm -f */*.o -rm -f */*/*.o - -rm -f depend depend.bak libmesa.a libglapi.a + -rm -f depend depend.bak libmesa.a libglapi.a libmesagallium.a -rm -f drivers/*/*.o -rm -f *.pc -rm -f shader/slang/library/*_gc.h Commited. Thanks. 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] Mesa (master): r300/compiler: Assert that array index is not negative.
On Fri, 2010-02-26 at 01:18 -0800, Corbin Simpson wrote:
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.
Vinson has been cleaning up code base based on the results of coverity
static code analysis.
Coverity generates thousands of errors/warnings for Mesa source code.
Not all errors/warnings reported by coverity are actually hit in
practice, but putting asserts and/or error handling code will at least
inform coverity that that can't ever happen, and allow the real errors
to stand out.
I imagine this is the case here.
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] pipebuffer: check for unsynchronized usage before looking at flags
On Tue, 2010-02-23 at 12:49 -0800, Luca Barbieri wrote: Good catch of the fence_signalled negated logic. This was actually mentioned on IRC by Maarten Maathuis (who was working on adding pipebuffer support to the nv50 driver). Thanks to him :) Thanks to you both then! 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] Gallium format swizzles (Was: util: fix swizzles in the format table for 8-bits-per-channel formats)
On Tue, 2010-02-23 at 09:20 -0800, José Fonseca 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_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.
I'm finished with my u_format* cleanups for now.
We have no unit tests for pixel formats yet so there might be some
regressions. Let me know.
As said in the bottom of u_format.csv, there are the formats with
unclear / inconsistent semantics:
# Ambiguous formats
# FIXME: They are used with different meanings in different places!!!
PIPE_FORMAT_R8G8B8_UNORM , plain, 1, 1, un8 , un8 , un8 , , zyx1,
rgb
PIPE_FORMAT_R8G8B8A8_UNORM, plain, 1, 1, un8
Re: [Mesa3d-dev] softpipe/llvmpipe SConscript
Hi Xavier,
On Sun, 2010-02-21 at 11:29 -0800, Xavier Chantry wrote:
Since commit c6509f89 , scons dri=no drivers=softpipe (or llvmpipe) no
longer works.
It does show a warning at the beginning :
warning: trace pipe driver disabled: skipping build of xlib libGL.so
But it does not stop there, instead it goes on and build almost
everything, It's hard to see and not very intuitive.
Before the above command worked because there was no check for trace,
trace was always put by default to the driver list, and the current
SConscript still does that :
line 39 : drivers = [trace]
I have two suggestions that are not exclusive, and either of them
would make me happy :
1) Replace all warning by error , and Return() by Exit()
This is is a double edge source.
I'd like to move away from having to specify everything in command line
and let plain scons without options just work.
The only way I see to achieve that goal is to have stacketrackers=all
drivers=all winsys=all by default, and fail gracefully.
2) remove the check for trace, it's already added by default anyway
If you pass drivers=softpipe then trace is *not* built.
But there is another thing that we can do: take out trace from the scons
options and always built it, as there are so many state trackers and
winsys that rely on it for debug building, and trace can really build
anywhere and is thin so there's no point is making it an option.
A side question :
line 21 : if not set(('softpipe', 'llvmpipe',
'trace')).intersection(env['drivers']):
print 'warning: no supported pipe driver: skipping build of xlib libGL.so'
Return()
But below in the script (line 41-58), the drivers used are softpipe ,
llvmpipe and cell.
Should trace be replaced by cell in the above check ?
Yes, I think so.
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
[Mesa3d-dev] Gallium format swizzles (Was: util: fix swizzles in the format table for 8-bits-per-channel formats)
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_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 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)
On Tue, 2010-02-23 at 12:27 -0800, Brian Paul wrote:
José Fonseca 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_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?
It feels a little unnatural that an XY vertex format would be
described by PIPE_FORMAT_G32R32_FLOAT, but if that makes things more
consistant I can live with it.
I think the priority is to have consistency.
FWIW, I'm perfectly fine standardizing in PIPE_FORMAT_R32G23_FLOAT and
LSB-MSB everywhere.
Jose
Re: [Mesa3d-dev] [PATCH] util: fix swizzles in the format table for 8-bits-per-channel formats
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 -- 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): Revert r300g: rebuild winsys/ pipe buffer handling and add buffer map
The pipebuffer library works well with purely user space suballocation of a big pinned buffer, but there are some further tweaks necessary in order to use it with kernel TTM-like memory managers. For example, one problem with pb_bufmgr_cache is that it doesn't try to check if a buffer is busy (e.g., by trying to map with PIPE_BUFFER_USAGE_DONTBLOCK) before reusing it. This worked fine so far because fencing was implemented on top of buffer suballocation and caching (ie., by the time a freed buffer was put in the cache list it was already guaranteed to have no pending fences). But this is not true if caching is used by itself on top of a kernel memory manager. Thomas also noticed the way validation lists works also needs some tweaks in order to work correctly. I don't think there's anything fundamentally broken in pipebuffer lib, just that we never had the need to make fix it so far. Jose On Sun, 2010-02-21 at 23:29 -0800, Dave Airlie wrote: Module: Mesa Branch: master Commit: b14548ea32000459f4f0c4b49f3fa11d1ee9c003 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=b14548ea32000459f4f0c4b49f3fa11d1ee9c003 Author: Dave Airlie airl...@redhat.com Date: Mon Feb 22 17:26:30 2010 +1000 Revert r300g: rebuild winsys/pipe buffer handling and add buffer map This reverts commit fff5be8e7b4557c221f2425dcafc2e7cbbba76ba. Probably went too soon with this, dileX reported OA not working for him it works here fine, but the optimisations I wanted aren't working properly yet so I'll fix that now. Signed-off-by: Dave Airlie airl...@redhat.com --- src/gallium/drivers/r300/Makefile |1 - src/gallium/drivers/r300/r300_context.c| 38 +-- src/gallium/drivers/r300/r300_context.h|9 +- src/gallium/drivers/r300/r300_cs.h | 22 +- src/gallium/drivers/r300/r300_emit.c | 54 ++-- src/gallium/drivers/r300/r300_render.c | 33 +-- src/gallium/drivers/r300/r300_screen.c | 38 +-- src/gallium/drivers/r300/r300_screen.h |2 +- src/gallium/drivers/r300/r300_screen_buffer.c | 222 src/gallium/drivers/r300/r300_screen_buffer.h | 85 - src/gallium/drivers/r300/r300_state.c | 25 +-- src/gallium/drivers/r300/r300_texture.c| 41 +-- src/gallium/drivers/r300/r300_texture.h|4 +- src/gallium/drivers/r300/r300_winsys.h | 127 +--- src/gallium/winsys/drm/i965/gem/i965_drm_winsys.h |2 + src/gallium/winsys/drm/radeon/core/Makefile|2 +- src/gallium/winsys/drm/radeon/core/radeon_buffer.h | 60 ++-- src/gallium/winsys/drm/radeon/core/radeon_drm.c| 134 +--- src/gallium/winsys/drm/radeon/core/radeon_drm.h|5 + .../winsys/drm/radeon/core/radeon_drm_buffer.c | 361 src/gallium/winsys/drm/radeon/core/radeon_r300.c | 237 -- src/gallium/winsys/drm/radeon/core/radeon_r300.h |6 +- src/gallium/winsys/drm/radeon/core/radeon_winsys.h | 86 +++-- 23 files changed, 347 insertions(+), 1247 deletions(-) Diff: http://cgit.freedesktop.org/mesa/mesa/diff/?id=b14548ea32000459f4f0c4b49f3fa11d1ee9c003 ___ mesa-commit mailing list mesa-com...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-commit -- 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 release for the end of March?
On Fri, 2010-02-19 at 09:42 -0800, Kristian Høgsberg wrote: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: 2010/2/19 Brian Paul brian.e.p...@gmail.com: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: I applied the patches from Kenneth Graunke on the list for this. Can we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and _mesa_bzero() too? I've remove _mesa_bzero() just now, plus some other macro wrappers. We might as well remove the malloc/calloc() wrappers too, but that'll be a bit more work. I'm using: git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g which does most of the work. I'll do the same thing for _mesa_calloc and _mesa_free, review the result and commit that. All done. I was looking at the MALLOC, CALLOC, MALLOC_STRUCT, CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the _mesa_align_* functions. Do we want to drop those too? Given that we'll unify these for gallium and mesa it's better leave them allone for now -- it will make it easier to search'n'replace when we do that. I hope to get started on this task next week. I hesitated because src/gallium/README.portability says Use MALLOC, CALLOC, FREE instead of the malloc, calloc, free functions. But as far as I can see, they're not redefined or anything for gallium and they just resolve to the standard malloc, calloc and free functions. Am I missing something? On gallium they only resolve to malloc/calloc/free on certain platforms -- Linux Windows user space. And even in Windows debug we use malloc debugging macros. 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] Mesa release for the end of March?
On Fri, 2010-02-19 at 10:23 -0800, Kristian Høgsberg wrote: 2010/2/19 Brian Paul brian.e.p...@gmail.com: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: 2010/2/19 Brian Paul brian.e.p...@gmail.com: 2010/2/19 Kristian Høgsberg k...@bitplanet.net: I applied the patches from Kenneth Graunke on the list for this. Can we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and _mesa_bzero() too? I've remove _mesa_bzero() just now, plus some other macro wrappers. We might as well remove the malloc/calloc() wrappers too, but that'll be a bit more work. I'm using: git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g which does most of the work. I'll do the same thing for _mesa_calloc and _mesa_free, review the result and commit that. All done. I was looking at the MALLOC, CALLOC, MALLOC_STRUCT, CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the _mesa_align_* functions. Do we want to drop those too? I hesitated because src/gallium/README.portability says Use MALLOC, CALLOC, FREE instead of the malloc, calloc, free functions. But as far as I can see, they're not redefined or anything for gallium and they just resolve to the standard malloc, calloc and free functions. Am I missing something? Let's keep the Gallium code as-is. But for Mesa: MALLOC_STRUCT and CALLOC_STRUCT should be kept. They save a lot of typing. MALLOC, CALLOC, and FREE can go. The ALIGN macros could probably go too (just call the align functions). Years ago, some systems defined malloc() as returning char * instead of void * so the Mesa wrappers helped with casting. Plus, back before valgrind I'd often rig up my own malloc-debug code to track down memory errors. The macros were handy for that. Ok, I droppped the ALIGN macros, but I'll leave the rest as is. Not sure what Jose has in mind, but I hope we can drop the MALLOC, CALLOC and FREE wrappers as well. At least on Linux today, we have valgrind and LD_PRELOAD tricks available to do malloc debugging that doesn't require malloc wrappers. My plan was to use pretty much the src/gallium/auxiliary/os/os_memory.h as is. Mesa will never run in kernel mode like gallium needs to, but it still quite cross-platform, so having a thing abstraction on top of STDC free/malloc/calloc is always a convenient. Linux has very nice memory debugging tools indeed, but windows has nothing near valgrind. Even if one is willing to pay. Also the debugging wrappers are convenient because they run every time -- if you introduce a regression you quickly see that in the final report when closing the app. It's not necessary to go out of the way to run a debugging tool. 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] Mesa (gallium-sw-api): drm/sw: Wip drm winsys
On Mon, 2010-02-15 at 01:46 -0800, Keith Whitwell wrote:
On Mon, Feb 15, 2010 at 2:11 AM, Jakob Bornecrantz
wallbra...@kemper.freedesktop.org wrote:
Module: Mesa
Branch: gallium-sw-api
Commit: 6ad834b39d6c2ae9ead2e2b00908ad2fa6914897
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=6ad834b39d6c2ae9ead2e2b00908ad2fa6914897
Author: Jakob Bornecrantz wallbra...@gmail.com
Date: Mon Feb 15 01:52:29 2010 +
drm/sw: Wip drm winsys
This winsys wraps a drm_api in order abstract away the different
memory manager. It also needs help from a pipe screen wrapper.
That wrapper is included in the same file but could be moved out
into a generic file.
---
src/gallium/include/state_tracker/xm_winsys.h |8 +
src/gallium/winsys/drm/sw/Makefile| 13 ++
src/gallium/winsys/drm/sw/sw_drm_api.c| 287
+
3 files changed, 308 insertions(+), 0 deletions(-)
diff --git a/src/gallium/include/state_tracker/xm_winsys.h
b/src/gallium/include/state_tracker/xm_winsys.h
index c928be0..5e2b5ee 100644
--- a/src/gallium/include/state_tracker/xm_winsys.h
+++ b/src/gallium/include/state_tracker/xm_winsys.h
@@ -131,6 +131,14 @@ struct sw_driver {
struct pipe_screen *(*create_screen)( struct sw_driver *driver,
struct sw_callbacks *callbacks );
+ struct pipe_texture *(*wrap_displaytarget)( struct sw_driver *driver,
+ struct pipe_screen *screen,
+ struct pipe_texture *templ,
+ struct sw_displaytarget *dt
);
+
+ struct sw_displaytarget *(*get_displaytarget)( struct sw_driver *driver,
+ struct pipe_texture *tex
);
+
/* No call to wrap a display target and create a texture. Hope
* that the callback mechanism is sufficient for now.
*/
Hmm, so much for the comment...
I'd prefer *not* to have this interface express both techniques for
associating a displaytarget and a texture in this interface. I know
that the dri2 state tracker takes this backdoor wrapping approach,
but I'm not at all convinced it's the right way to do things.
The fact that xorg and dri2 are using different approaches to achieve
similar goals is also pretty concerning. I'd rather see that cleaned
up and unified than push the same choices into software drivers.
Whether it's the backdoor approach or screen::create_texture() (or
similar), there should be a single flow of control and a clear
layering that is the same everywhere.
Thinking about it now, my preference would be to add something to the
screen like:
struct pipe_texture *open_shared_texture( struct pipe_screen
*screen, struct pipe_texture *template, void *winsys_handle )
and hide the local vs shared handle business inside the void * somehow
so that bit of dri2/gem/kms mismatch doesn't contaminate the 3d stack.
I entirely agree with Keith. Inter-process resource sharing is a problem
common to all modern graphics APIs, therefore it should be suitably
abstracted so that differences become mere implementation details,
instead of having all these ad-hoc interfaces.
Jose
--
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
[Mesa3d-dev] scons and progs
FYI, progs take a long time to build so they are not built by default now with scons. To build them pass progs to the command line: scons progs To build the source and progs simultaneously do scons src progs Jose -- 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] RFC: gallium-embedded
On Tue, 2010-02-09 at 06:37 -0800, Kristian Høgsberg wrote: On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca jfons...@vmware.com wrote: ... This reminds me there's a patch series from mesa3d-dev that removed a bunch of Mesa's std C wrappers (like _mesa_memcpy()). Mabye some of those could be applied after gallium-embedded but before the src/platform work. Great. It seems we have a plan then. What happened to the plan? Are we going to move the header files out to src/os or are they staying under src/gallium/auxillary/os? Is the idea that code under src/mesa can include the headers from src/gallium/auxillary/os? Kristian Kristian, Nothing happened to the plan -- I will move the header files out to src/platform or src/os or whatever name people feel comfortable with. But I don't have time to do it this week or likely the next. It just not a matter of moving files -- it's also necessary to break the dependency of the os stuff from p_config.h and p_compiler.h somehow. I don't want gallium interfaces to depend on this new shared module nor vice-versa. It's not very hard but getting it right needs more attention and time than I can dispense at the moment. If you prefer getting a start at this yourself immediately then I'm fine with you starting a feature branch to rehearse this. Jose -- 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] st_api: a replacement for st_public.h
On Thu, 2010-02-04 at 21:23 -0800, Chia-I Wu wrote: Hi Keith, Thanks for having a closer look. On Thu, Feb 4, 2010 at 9:31 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: As st_api.h can be implemented parallelly with st_public.h, a possible route I would like to take is to (in this order) 1. implement st_api.h in OpenVG and OpenGL state trackers 2. convert st/egl to use st_api.h 3. convert st/glx and st/dri to use st_api.h 4. eliminate st_public.h and any use of it Probably the other major user is st/wgl. If you install mingw, this can be build-tested on linux machines, so you should at least be able to minimize the disruption in that component as well. Yeah, right. If there will still be concerns for st/wgl users, I can also postpone the elimination of st_public.h. WGL semantics are similar to GLX -- just different names --, so I don't expect any problem adapting st/wgl to st_api.h. Leaving it broken is not an option though, since it is a very important component for us. If you could do the initial rough conversion of st/wgl to st_api.h I'd gladly test it and polish it. I've looked at http://cgit.freedesktop.org/~olv/st_api/tree/st_api.h , and all looks very sensible. The only thing I don't understand, perhaps due to my EGL ignorance, is st_context::lock/unlock_resource(). What do they exactly accomplish? Is there some EGL visible APIs that map exactly to this? As Jakob drafted the first version of the interface, I believe he also wanted to remove screen-flush_front and screen-update_buffer. These two callbacks do become unnecessary because of the new st_framebuffer_iface, which I think is a step forward. screen-flush_front itself may still exist, but indeed the Mesa state tracker shouldn't call it directly -- it should be st/wgl, st/glx, and friends. I think st_api's st_framebuffer::flush_front accomplishes this nicely. BTW, I'd prefer the name present instead of flush_front. It's a more common and intuitive name for this operation. Jose -- 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] os_malloc_aligned fails on 64bit
On Thu, 2010-02-04 at 09:14 -0800, Andreia Gaita wrote: Hi everyone, On os_memory_aiigned.h, os_malloc_aligned does: buf = (char *)(((uintptr_t)ptr + sizeof(void *) + alignment - 1) ~(alignment - 1)); which gets clamped to 32 bits and fails rather spectacularly on 64 bits, the NOR needs a long cast to work properly. I've attached a patch with the fix, hope that's the proper way to submit it. Commited with minor changes. Thanks! Jose -- 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] RFC: gallium-embedded
On Mon, 2010-02-01 at 08:31 -0800, José Fonseca wrote: I've just started another feature branch, gallium-embedded. The objectives of this branch are two-fold: - remove all inlines and os dependencies from src/gallium/include/pipe headers, so that gallium interfaces become pure interfaces and therefore everything else becomes optional - move all OS abstractions to a separate optional module so that porting to new platforms is easier -- there will be a clear list of functions that need to be implemented The only planned interface change is pipe_reference -- it will be reduced to an ordinary int32_t -- which is key to achieve the above. Implementations of gallium should use p_atomic or their version of atomic operations. For platforms without hardware-support atomic operations (I personally don't know any interesting platform that fits the profile) gallium will either be single threaded or a global mutex should be acquired before incrementing refcounts. In summary there will be three levels of integration with gallium: 1 - just the gallium interfaces, mean and lean 2 - gallium interfaces and auxiliary modules but no OS abstractions (e.g. for embedded platforms) 3 - everything (interfaces + auxiliary + os abstractions). all existing platforms (linux, windows, etc) If there are any concerns with this direction please let me know as soon as possible. Jose The branch is ready for merge. There are no gallium interface per se, just shuffling stuff around. The interesting bits are: - http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/os?h=gallium-embedded - http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe?h=gallium-embedded git diff --diff-filter=M 5cc20a06b05bd551b663c050fb4802e2658decd5..origin/gallium-embedded -- src/gallium/include/pipe/ Let me know there are objections/suggestionns. Jose -- 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] RFC: gallium-embedded
On Wed, 2010-02-03 at 07:12 -0800, Jakob Bornecrantz wrote:
On Wed, Feb 3, 2010 at 12:58 PM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2010-02-01 at 08:31 -0800, José Fonseca wrote:
I've just started another feature branch, gallium-embedded.
The objectives of this branch are two-fold:
- remove all inlines and os dependencies from src/gallium/include/pipe
headers, so that gallium interfaces become pure interfaces and therefore
everything else becomes optional
- move all OS abstractions to a separate optional module so that porting
to new platforms is easier -- there will be a clear list of functions
that need to be implemented
The only planned interface change is pipe_reference -- it will be
reduced to an ordinary int32_t -- which is key to achieve the above.
Implementations of gallium should use p_atomic or their version of
atomic operations. For platforms without hardware-support atomic
operations (I personally don't know any interesting platform that fits
the profile) gallium will either be single threaded or a global mutex
should be acquired before incrementing refcounts.
In summary there will be three levels of integration with gallium:
1 - just the gallium interfaces, mean and lean
2 - gallium interfaces and auxiliary modules but no OS abstractions
(e.g. for embedded platforms)
3 - everything (interfaces + auxiliary + os abstractions). all existing
platforms (linux, windows, etc)
If there are any concerns with this direction please let me know as soon
as possible.
Jose
The branch is ready for merge.
There are no gallium interface per se, just shuffling stuff around. The
interesting bits are:
-
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/os?h=gallium-embedded
-
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe?h=gallium-embedded
git diff --diff-filter=M
5cc20a06b05bd551b663c050fb4802e2658decd5..origin/gallium-embedded --
src/gallium/include/pipe/
Let me know there are objections/suggestionns.
First of some of the commits are confusing in particularly gallium:
Make pipe_atomic a regular int32_t. since there are '#include
u_debug.h' sprinkled all over the place. In previous commits you
handled this much better.
Fair enough. I'll take more care next time.
Further on the topic of that commit I don't agree with removing the
pipe_atomic stuff from the gallium interface, the reference counting
is apart of the interface and it must be the same across a platform.
If you where to define a different platform it could change, but just
as you need to add support to a platform in the p_config and
p_compiler files you need to add support for p_atomic. In short I
think you set the bar just a tad bit to low and the interface got hurt
in the process.
The atomic operations semantics are quite clear. Two different
implementations can perfectly inter-operate if they follow the
semantics.
Also the removal of some of the inlines seems a bit to harsh as well,
the pipe_buffer_{unmap|map} inlines for instance holds a bit of
semantics in them. In short about this and the p_atomic functions, I
view them as apart of the interface just as much as pipe_context. Is
there a particularly reason for removing the inlines? Portability or
just general dislike of them?
Portability. Not dislike. Inlines depend on asserts which depend on
auxiliary modules, therefore it violates the goal of being able to use
gallium without auxiliary modules.
The inlines are really short cuts, and their semantics are either
implementation details or derive from gallium interface semantics.
I do very much agree with the moving out functions from u_debug into os_*.
I'm glad you liked something!! :D
You might want to protect the PIPE_OS_* defines with #ifndef
PIPE_OS_EMBEDDED so that you don't end up with more then one
platform. Or is PIPE_OS_EMBEDDED meant to be a subsystem thing?
Yep. That will happen soon. The branch is just for the invasive
refactoring changes. The remaining embedded platform specific stuff can
be done incrementally on master without disruption.
And this is not a comment about your work but more of a legacy thing,
p_config.h defines PIPE_CC_* shouldn't those be defined inside of
p_compiler.h?
Yeah, they could.
And the final bit, can you please update the documentation before
merging. Information about where the different PIPE_* defines are
defined. List of symbols that should be exposed by the os_ files. How
you go about adding a new platform would be nice but might be a bit to
much.
os module is not a gallium interface. Auxiliary stuff is optional and it
is not gallium on the strict sense -- just a possible implementation of
it.
There was never the commitment to document every auxiliary module.
I'll add a brief mention of OS module to gallium-docs if that's what
you're asking.
Jose
Re: [Mesa3d-dev] RFC: gallium-embedded
On Wed, 2010-02-03 at 07:38 -0800, Kristian Høgsberg wrote: On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell kei...@vmware.com wrote: Historically we had a lot of helpers in gallium/include, which have been incrementally moved out to gallium/auxiliary. Is there a way we can structure the code so that the atomic operations can be made available for core mesa (I guess I'm talking about the GL state tracker/implementation, either way, stuff like struct gl_framebuffer refcounts etc).? Yes. The [pu]_atomic.h header is pretty much self sufficient. If we replace the PIPE_CC_xxx by the original predefined compiler macros it would be completely self sufficient and could be shared between Mesa and Gallium. Perhaps somewhere inside mesa/include. Another possibility would be to put the compiler and os abstraction stuff in a shared component between Mesa and Gallium. Most of the stuff has the same origin anyway. It requires a bit more of playing with the build system but it's perfectly feasible, especially now that the os abstraction stuff no longer depends on other gallium auxiliary modules. Jose -- 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] RFC: gallium-embedded
On Wed, 2010-02-03 at 08:00 -0800, Kristian Høgsberg wrote: On Wed, Feb 3, 2010 at 10:51 AM, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-02-03 at 07:38 -0800, Kristian Høgsberg wrote: On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell kei...@vmware.com wrote: Historically we had a lot of helpers in gallium/include, which have been incrementally moved out to gallium/auxiliary. Is there a way we can structure the code so that the atomic operations can be made available for core mesa (I guess I'm talking about the GL state tracker/implementation, either way, stuff like struct gl_framebuffer refcounts etc).? Yes. The [pu]_atomic.h header is pretty much self sufficient. If we replace the PIPE_CC_xxx by the original predefined compiler macros it would be completely self sufficient and could be shared between Mesa and Gallium. Perhaps somewhere inside mesa/include. Another possibility would be to put the compiler and os abstraction stuff in a shared component between Mesa and Gallium. Most of the stuff has the same origin anyway. It requires a bit more of playing with the build system but it's perfectly feasible, especially now that the os abstraction stuff no longer depends on other gallium auxiliary modules. Either way sounds good to me - something like src/platform could work, but I don't have a strong preference. I can help out if you want, but it sounds like you're already moving things around so I would probably just step on your toes :-) Sure! If everybody agrees with this direction then I'll get started on that after I'm finished with the current reorg. Jose -- 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] RFC: gallium-embedded
On Wed, 2010-02-03 at 09:01 -0800, Brian Paul wrote: José Fonseca wrote: On Wed, 2010-02-03 at 08:00 -0800, Kristian Høgsberg wrote: On Wed, Feb 3, 2010 at 10:51 AM, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-02-03 at 07:38 -0800, Kristian Høgsberg wrote: On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell kei...@vmware.com wrote: Historically we had a lot of helpers in gallium/include, which have been incrementally moved out to gallium/auxiliary. Is there a way we can structure the code so that the atomic operations can be made available for core mesa (I guess I'm talking about the GL state tracker/implementation, either way, stuff like struct gl_framebuffer refcounts etc).? Yes. The [pu]_atomic.h header is pretty much self sufficient. If we replace the PIPE_CC_xxx by the original predefined compiler macros it would be completely self sufficient and could be shared between Mesa and Gallium. Perhaps somewhere inside mesa/include. Another possibility would be to put the compiler and os abstraction stuff in a shared component between Mesa and Gallium. Most of the stuff has the same origin anyway. It requires a bit more of playing with the build system but it's perfectly feasible, especially now that the os abstraction stuff no longer depends on other gallium auxiliary modules. Either way sounds good to me - something like src/platform could work, but I don't have a strong preference. I can help out if you want, but it sounds like you're already moving things around so I would probably just step on your toes :-) Sure! If everybody agrees with this direction then I'll get started on that after I'm finished with the current reorg. This would probably be a good move. There's a few places in the state tracker where there's conflicts between Mesa's and Gallium's low-level macros, etc. that could be fixed then. This reminds me there's a patch series from mesa3d-dev that removed a bunch of Mesa's std C wrappers (like _mesa_memcpy()). Mabye some of those could be applied after gallium-embedded but before the src/platform work. Great. It seems we have a plan then. Jose -- 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
[Mesa3d-dev] RFC: gallium-embedded
I've just started another feature branch, gallium-embedded. The objectives of this branch are two-fold: - remove all inlines and os dependencies from src/gallium/include/pipe headers, so that gallium interfaces become pure interfaces and therefore everything else becomes optional - move all OS abstractions to a separate optional module so that porting to new platforms is easier -- there will be a clear list of functions that need to be implemented The only planned interface change is pipe_reference -- it will be reduced to an ordinary int32_t -- which is key to achieve the above. Implementations of gallium should use p_atomic or their version of atomic operations. For platforms without hardware-support atomic operations (I personally don't know any interesting platform that fits the profile) gallium will either be single threaded or a global mutex should be acquired before incrementing refcounts. In summary there will be three levels of integration with gallium: 1 - just the gallium interfaces, mean and lean 2 - gallium interfaces and auxiliary modules but no OS abstractions (e.g. for embedded platforms) 3 - everything (interfaces + auxiliary + os abstractions). all existing platforms (linux, windows, etc) If there are any concerns with this direction please let me know as soon as possible. Jose -- 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] user buffers, usage hints [was RE: Grab bag of random questions (whoo)]
On Sun, 2010-01-31 at 04:31 -0800, Keith Whitwell wrote: Userbuffers get hit in the traditional GL vertex array paths, which is pretty common usage. I've been thinking about buffers and uploads a bit recently, and I'm pretty sure we can do better than the current mechanisms. Also, it makes sense to make the BUFFER_USAGE_ flags stronger - I think it's been a grey area whether they are hints or not. I've been (rightly or wrongly) thinking of them as guarantees for a while, so I certainly won't argue to keep them as hints. I'm pretty sure the SVGA driver treats them as guarantees, for instance, and uses malloc for constant buffers. Actually SVGA interprets them as hints. It just uses them to choose whether the initial storage should be in a malloc buffer or hardware buffer. If any buffer (user or not) is bound then a host surface and dma upload will happen automatically. This all happens in svga_buffer_handle(). From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Saturday, January 30, 2010 4:06 AM To: Mesa3D-Development Subject: [Mesa3d-dev] Grab bag of random questions (whoo) 4) user_buffer_create doesn't appear to see an incredible amount of usage. user_buffer_create is exposed by the APIs to the application. It is used as often as the apps use it. My understanding is that old GL and D3D apps use it a lot. Would it be too horrible to make *all* buffer allocations delayed, transparently? You mean, make the state tracker's responsibility to create a hardware pipe buffer and copy the contents when the buffer is about to be bound? What about software renderers or software vertex processing fallbacks done by the draw module? They would incur unnecessary extra copy, as they can read the user memory directly. Furthermore Thomas devised at some time the possibility to create DRM buffers from user memory on demand, so even real hardware could potentially do similar things. In summary, yes it will be possible, but it would damage I ask because apparently the PIPE_BUFFER_USAGE flags (PIXEL, CONSTANT, etc.) are optimization hints and not guarantees, which is very annoying since I need to prevent constantbufs from ever becoming BO-backed... That's why pipe_screen::buffer_create should be != pipe_winsys::buffer_create and pipe_winsys should die. The winsys should worry only about DRM BOs. The pipe driver should implement user buffers internally, do whatever it needs to be done, and never pass them to the winsys. Jose -- 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 Sat, 2010-01-30 at 04:06 -0800, Corbin Simpson wrote: Handful of random things bugging me. Bellow some answers for the things I know enough to comment. 1) Team Fortress 2 (and probably other Source games, haven't really checked) request some fairly large VBOs and indexbufs, beyond what I can provide. Is there any good example code on how to use translate/indices to slice up buffers for multiple render runs? Draw module has some code to break large VBOs. But I don't know how to set it up so that it does that without doing vertex processing though. Keith's might help you with that. 3) Is there still interest in the translate helper I proposed a couple weeks ago? It would take a list of safe formats, a list of VBO elements, and a list of VBOs (corresponding), and return a list of VBO elements and VBOs that only contain those safe formats. State trackers would call a pipe_screen (or pipe_context?) method with just the VBOs and elements, and it would fix them up without exposing the list of safe formats. I've missed that mail. I've read the thread and I agree with Keith's reply. In summary, there are more than one way to skin this cat but your proposed helper seems an useful thing to have. 5) How const is const for CSO? e.g. r300_state.c:498, we're not copying pipe_framebuffer_state but just the pointer. It appears to work, but is it actually safe? The const means the driver cannot change it. Not that it won't change. The long answer is depends on how the driver is implemented and commands batched. The next time the set_framebuffer_state is called the previous object may have been destroyed/modified, so if you have internal references to it they would cause segfault. But if by the time that happens you no longer have references to it -- e.g. you just have references to the BOs that hold the frambuffer storage -- then it would work fine. Short answer is -- it is better to just make a local copy. Also, on the topic of framebuffers, is it okay to refuse to render if no MRTs or Z buffer are present? Not really. At least not as it stands. If the hardware requires these then they'll need to be created internally by the pipe driver. We could add a caps for this but I see no point for it, since it's so easy to create a dummy framebuffer internally. I think that's it for now. Sorry for all the questions, but I'm really starting to get a good handle on the hardware and interface, and I'm ready to start beating the classic driver in serious benchmarks; I think that r300's probably the most mature driver alongside nv50 and maybe nv40. That's great to hear. It has been really nice to see gallium driver development lately on so many different hardware, and with that seeing gallium interface more polished to abstract well more hardware. I think you've been doing a great work not only with the driver development, but also making the right questions, and documenting interfaces. Jose -- 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 1/2] gallium: half float vertex formats
Ditto. Better keep the empty line before PIPE_FORMAT_COUNT though.
Jose
On Fri, 2010-01-29 at 04:11 -0800, Keith Whitwell wrote:
This looks good to me.
Keith
From: Luca Barbieri [l...@luca-barbieri.com]
Sent: Thursday, January 28, 2010 10:35 PM
To: mesa3d-dev@lists.sourceforge.net
Cc: airl...@linux.ie; Luca Barbieri
Subject: [Mesa3d-dev] [PATCH 1/2] gallium: half float vertex formats
Based on work by Dave Airlie.
Adds the 4 vertex formats for half float vertices.
This differs from Dave Airlie's patch in that it does not add padded
formats, but rather uses the convention already used for vertex
formats.
This allows to simplify the patches and is consistent with the
existing code.
Since vertex buffers have an explicitly specified stride, format
padding is redundant.
Future half float texture support may however need padded formats to
be defined.
---
src/gallium/include/pipe/p_format.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index 6bfff1c..09b2153 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -166,6 +166,11 @@ enum pipe_format {
PIPE_FORMAT_DXT3_SRGBA= 108,
PIPE_FORMAT_DXT5_SRGBA= 109,
+ /* half float vertex formats */
+ PIPE_FORMAT_R16_FLOAT = 110,
+ PIPE_FORMAT_R16G16_FLOAT = 111,
+ PIPE_FORMAT_R16G16B16_FLOAT = 112,
+ PIPE_FORMAT_R16G16B16A16_FLOAT= 113,
PIPE_FORMAT_COUNT
};
--
1.6.6.1.476.g01ddb
--
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
--
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
--
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] mesa_7_7_branch - master merges
On Wed, 2010-01-27 at 00:59 -0800, Keith Whitwell wrote: On Tue, 2010-01-26 at 16:26 -0800, Brian Paul wrote: Stephane Marchesin wrote: On Tue, Jan 26, 2010 at 15:13, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Fonseca wrote: mesa_7_7_branch and master are becoming quite different, because of all the gallium interface changes that have been going into master, so merging fixes from mesa_7_7_branch into master is becoming less and less of a trivial exercise. This is aggravated by the fact we are basing a release from the mesa_7_7_branch, so it's likely that we'll need to have temporary non-invasive bugfixes that should not go into master (which should receive instead the proper and potentially invasive fix). I see a few alternatives here: a) stop merging mesa_7_7_branch - master. bugfixes should be applied to both branches. preferably by the person that wrote the patch. b) when applying a non-trivial bugfix to mesa_7_7_branch, the same person should do the merge into master, and undo any undesired change, or update for interface changes in master. Note however that it's better to give a few days between applying to mesa_7_7_branch and merging into master, to allow for wider testing, otherwise we'll be merging like crazy. c) do not apply any non trivial bugfix to mesa_7_7_branch anymore, and use a separate branch for those. I don't feel strongly about any of these alternatives for now. We'll eventually need to setup a private branch for our release so c) is bound to happen anyway. But I also think we can't keep merging mesa_7_7_branch into master like this forever -- after so much thought was put into the gallium interface changes (feature branches, peer review, etc) but whenever a mesa_7_7_branch - master happens all sort of wrong code is merged automatically. This was my primary argument *against* our current commit / merge model. The ideal would be to peer-review the merges before committing, but it seems difficult to do that with git, while preserving merge history and not redoing merges. It sounds like we want to copy the Linux kernel model: - - Each developer has a local tree. - - Each developer sends out: - A patch series - A pull request - A list of commit IDs to cherry-pick - - Based on review comments, the maintainer applies the patches / pulls the tree. More bureaucracy. Just what we need in our understaffed world. I'm not too crazy about this either. We can barely keep up with the patches submitted for review now. I certainly don't have time to review everything that comes along and very few other people are reviewing/testing/committing patches either. My plate is already full. One thing worth noting is how well the branch-master merges have been working. We've *never* managed to put so many fixes into the stable branch and successfully propagate them to master. Think of the hundreds of commits Vinson has made fixing errors from static analysis. The system has worked better than anything else before, but is now starting to reach its limits. That seems to me to call for a minor adjustment rather than a total overhaul. Yes. I agree. Indeed reviews only work if there are enough reviewers, and the review traffic is pretty overwhelming as it is. I should have thought of that before mentioning it. BTW, Brian thanks for all the hard work you've been doing on taking patches. I should and will try to do more on this subject. Maybe the approach should be to minimise now the amount of stuff going into the stable branch - ask Vinson to do his work on master now, for instance, and let the stable branch only take fixes for user-visible bugs, which are hopefully smaller in volume. Yes, that's probably a good compromise. Jose -- 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 1/4] tgsi: add properties for fragment coord conventions (v2)
On Wed, 2010-01-27 at 08:49 -0800, Brian Paul wrote: Luca Barbieri wrote: Changes in v2: - Caps are added in a separate, subsequent patch This adds two TGSI fragment program properties that indicate the fragment coord conventions. The properties behave as described in the extension spec for GL_ARB_fragment_coord_conventions, but the default origin in upper left instead of lower left as in OpenGL. The syntax is: PROPERTY FS_COORD_ORIGIN [UPPER_LEFT|LOWER_LEFT] PROPERTY FS_COORD_PIXEL_CENTER [HALF_INTEGER|INTEGER] The names have been chosen for consistency with the GS properties and the OpenGL extension spec. The defaults are of course the previously assumed conventions: UPPER_LEFT and HALF_INTEGER. Sorry for the slow reply on this. It looks like you've solved the fragcoord problems in a clean/logical way. I haven't seen any objections, so I think we can move forward with this. Didn't Keith had objections on this, on another thread? Luca re-sent the patch but I don't see the remark being addressed. Forwarded Message From: Keith Whitwell kei...@vmware.com To: Luca Barbieri l...@luca-barbieri.com Cc: mesa3d-dev@lists.sourceforge.net mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] [PATCH 3/7] tgsi: add properties for fragment coord conventions Date: Tue, 26 Jan 2010 03:11:51 -0800 Luca, I would have expected fragment coord conventions to be device state, not a part of the shader. It seems like these new flags are really peers (or replacements?) of the gl_rasterization_rules flag in pipe_rasterizer_state, and that the shaders should remain unchanged. Keith Jose -- 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 1/4] tgsi: add properties for fragment coord conventions (v2)
On Wed, 2010-01-27 at 09:24 -0800, Brian Paul wrote: Keith Whitwell wrote: On Wed, 2010-01-27 at 09:09 -0800, José Fonseca wrote: On Wed, 2010-01-27 at 08:49 -0800, Brian Paul wrote: Luca Barbieri wrote: Changes in v2: - Caps are added in a separate, subsequent patch This adds two TGSI fragment program properties that indicate the fragment coord conventions. The properties behave as described in the extension spec for GL_ARB_fragment_coord_conventions, but the default origin in upper left instead of lower left as in OpenGL. The syntax is: PROPERTY FS_COORD_ORIGIN [UPPER_LEFT|LOWER_LEFT] PROPERTY FS_COORD_PIXEL_CENTER [HALF_INTEGER|INTEGER] The names have been chosen for consistency with the GS properties and the OpenGL extension spec. The defaults are of course the previously assumed conventions: UPPER_LEFT and HALF_INTEGER. Sorry for the slow reply on this. It looks like you've solved the fragcoord problems in a clean/logical way. I haven't seen any objections, so I think we can move forward with this. Didn't Keith had objections on this, on another thread? Luca re-sent the patch but I don't see the remark being addressed. I don't think my concerns are fatal to this approach, I just need to understand the issues a bit better before signing off on it. I meant I didn't see objections to Luca's latest patch series. After studying the issues for a while I think Luca's on the right track. I'll try to summarize. Re: coord origin upper/lower-left: A GPU may natively implement lower-left origin or upper-left origin (or both). With GL_ARB_fragment_coord_conventions, the user may want to use either of those origins. By asking the driver what it supports we can avoid extra Y-inversion code in the shader. Drivers don't have to do anything special other than tell the state tracker (via new cap bits) what it can do. Re: pixel center integer: Again, depending on what the GPU implements we may need to add/subtract a 0.5 bias to the fragment coord register in a fragment shader. This is orthogonal to pipe_rasterizer_state:: gl_rasterization_rules. With Luca's patch we query what the GPU can support and submit TGSI shaders which either tell the driver which convention to use, or submit shaders that implement the bias themselves. The new TGSI shader properties are needed because the origin/center state can change per-shader (it's not per-context) and for the sake of drivers that can support both conventions. I too was concerned whether this was all really needed but I think it is. It appears everybody was in agreement after all. I really don't have an opinion on this, as I don't understand the different rules. From what I could gather it seems that even in the most limited hardware it is always possible to expose this new functionality either by tweaking shaders or flushing contexts before switching hardware global device settings. I'm a bit confused what will pipe_rasterizer_state::gl_rasterization_rules mean at the end of the day. Is it still necessary? Jose -- 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 1/4] tgsi: add properties for fragment coord conventions (v2)
On Wed, 2010-01-27 at 10:05 -0800, Brian Paul wrote: José Fonseca wrote: On Wed, 2010-01-27 at 09:24 -0800, Brian Paul wrote: Keith Whitwell wrote: On Wed, 2010-01-27 at 09:09 -0800, José Fonseca wrote: On Wed, 2010-01-27 at 08:49 -0800, Brian Paul wrote: Luca Barbieri wrote: Changes in v2: - Caps are added in a separate, subsequent patch This adds two TGSI fragment program properties that indicate the fragment coord conventions. The properties behave as described in the extension spec for GL_ARB_fragment_coord_conventions, but the default origin in upper left instead of lower left as in OpenGL. The syntax is: PROPERTY FS_COORD_ORIGIN [UPPER_LEFT|LOWER_LEFT] PROPERTY FS_COORD_PIXEL_CENTER [HALF_INTEGER|INTEGER] The names have been chosen for consistency with the GS properties and the OpenGL extension spec. The defaults are of course the previously assumed conventions: UPPER_LEFT and HALF_INTEGER. Sorry for the slow reply on this. It looks like you've solved the fragcoord problems in a clean/logical way. I haven't seen any objections, so I think we can move forward with this. Didn't Keith had objections on this, on another thread? Luca re-sent the patch but I don't see the remark being addressed. I don't think my concerns are fatal to this approach, I just need to understand the issues a bit better before signing off on it. I meant I didn't see objections to Luca's latest patch series. After studying the issues for a while I think Luca's on the right track. I'll try to summarize. Re: coord origin upper/lower-left: A GPU may natively implement lower-left origin or upper-left origin (or both). With GL_ARB_fragment_coord_conventions, the user may want to use either of those origins. By asking the driver what it supports we can avoid extra Y-inversion code in the shader. Drivers don't have to do anything special other than tell the state tracker (via new cap bits) what it can do. Re: pixel center integer: Again, depending on what the GPU implements we may need to add/subtract a 0.5 bias to the fragment coord register in a fragment shader. This is orthogonal to pipe_rasterizer_state:: gl_rasterization_rules. With Luca's patch we query what the GPU can support and submit TGSI shaders which either tell the driver which convention to use, or submit shaders that implement the bias themselves. The new TGSI shader properties are needed because the origin/center state can change per-shader (it's not per-context) and for the sake of drivers that can support both conventions. I too was concerned whether this was all really needed but I think it is. It appears everybody was in agreement after all. I really don't have an opinion on this, as I don't understand the different rules. From what I could gather it seems that even in the most limited hardware it is always possible to expose this new functionality either by tweaking shaders or flushing contexts before switching hardware global device settings. Right. We ask the driver what it can do and the state tracker emits extra instructions to invert/bias the fragcoord as needed. I'm a bit confused what will pipe_rasterizer_state::gl_rasterization_rules mean at the end of the day. Is it still necessary? Yes, it's still needed. gl_rasterization_rules controls which pixels are hits/written when rasterizing a triangle regardless of the shader. The pixel_center_integer controls what value the fragment shader gets when it reads gl_FragCoord (either x.0 or x.5). Ah OK. Thanks for the explanation! Jose -- 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] gallium docs
On Mon, 2010-01-25 at 23:28 -0800, Uros Nedic wrote: First of all I consider myself as experienced C/C++/Java programmer. Even tough I know other languages this is my primary area of expertise. Also I have very good background in CS, mathematics, etc. What I wanted to say is that rapidly-changing GPU architectures market is not possible to track if you are not spending significant amount of time to learn about it and to keep informed. Learning curve is just to high. At the same time guys from Gallium started one really nice project, where I found myself. I saw that in Windows world something similar is happening. Ultimately, it is industry trend. I wanted to join to gallium community and asked one of leaders to tell me number of people, etc. His conversation with me was rather tough than welcomed. All I got is that I have to write to mesa3d-dev and hope that anyone would respond. Exactly as one developer noticed - I had to hijack thread in hope that anyone would read it. It looks like my idea succeeded. We are talking about that now. Another thing that bother me, is that gallium community is very small but worse thing is that some of people who are working on gallium are very hard to approach, even arrogant. This is certainly not way how to build successful society, for sure. It looks like that they consider themselves as that they have some mission and stuffs like community are not important at all. Documentation, as an example, fits perfectly into my story. There is no successful community if there aren't good documentation. I really do not know how do you imagine to develop any large-scale project if you do not develop documentation concurrently with code!? Documentation is at least important as source code is (read Donald Knuth!). But if some developers (I do not want to say all!) consider themselves as a higher class then they will get corresponding community response. I would like to start contributing to gallium community but behavior of some developers and luck of documentation simply rejects me from that. This is my final call that you make revision of your current policy to the rest of the world (community), and to apologize and start to communicate. Regards, Uros Nedic, MSc Uros, You're right went you say documentation would increase community size. More importantly, the life of the already existing developer community would be easier if there was more documentation. We all agree on this, and things have lately been going in the right direction, as a spec is being written. But documentation is not an absolute requirement to join. I complained about lack of documentation 8 years ago, but I didn't stop -- I analyzed the whole archive of mesa3d-dev and dri-dev mailing lists, created FAQs, glossaries, a wiki. A lot of that material is in todays' DRI wiki still. The problem is here is developer's time. And once in a while you see a newbie demanding documentation, personalized help, or pushing their vision of what the architecture should look like. And we really have no time to produce that documentation immediately, explaining basic stuff, or argue why things are as they are. Probably you're better than one of them, but unfortunately you sounded like one, and that's probably why this harsh reaction. In summary, it is not our intention to be elitist and put the entry bar high to avoid newbies, but we simply do not have the time to lower the bar ourselves. If newbies are really serious about participating and joining development, they will have to surpass the hurdles themselves and hopefully help lower the entry bar while they still remember how difficult it is to get started on this. Jose -- 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] softpipe: Fix softpipe_reset_sampler_varients, check if the sampler has a texture != NULL. It fixes the bug 25863
On Sun, 2010-01-24 at 18:36 -0800, Igor Oliveira wrote:
The patch fixes the bug 25863.
The bug happens when i use blend types like multiply, screen, dark in
vega state tracker.
--- a/src/gallium/drivers/softpipe/sp_state_sampler.c
+++ b/src/gallium/drivers/softpipe/sp_state_sampler.c
@@ -244,7 +244,7 @@ softpipe_reset_sampler_varients(struct
softpipe_context *softpipe)
* fragment programs.
*/
for (i = 0; i = softpipe-vs-max_sampler; i++) {
- if (softpipe-vertex_samplers[i]) {
+ if (softpipe-vertex_samplers[i] softpipe-vertex_textures[i]) {
softpipe-tgsi.vert_samplers_list[i] =
get_sampler_varient( i,
sp_sampler(softpipe-vertex_samplers[i]),
@@ -258,7 +258,7 @@ softpipe_reset_sampler_varients(struct
softpipe_context *softpipe)
}
for (i = 0; i = softpipe-fs-info.file_max[TGSI_FILE_SAMPLER]; i++) {
- if (softpipe-sampler[i]) {
+ if (softpipe-sampler[i] softpipe-texture[i]) {
softpipe-tgsi.frag_samplers_list[i] =
get_sampler_varient( i,
sp_sampler(softpipe-sampler[i]),
--
1.6.3.3
This doesn't seem the best way to fix this: the segfault may happen in
softpipe code, but the state tracker has the responsibility to sanitize
state. Shouldn't the vega state tracker bind a dummy black texture in
this case?
Also, the net effect of this patch is to use the previously bound
texture/sampler -- which may be null -- so the bug is potentially still
there, but perhaps less likely.
I wonder why changing blend type causes a null texture to be bound in
the first place? I recall from Zack's VG talk that certain kind of
blending ops had to be implemented with texturing, but binding a null
texture binding seems a symptom of some subtle bug.
Jose
--
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
[Mesa3d-dev] mesa_7_7_branch - master merges
mesa_7_7_branch and master are becoming quite different, because of all the gallium interface changes that have been going into master, so merging fixes from mesa_7_7_branch into master is becoming less and less of a trivial exercise. This is aggravated by the fact we are basing a release from the mesa_7_7_branch, so it's likely that we'll need to have temporary non-invasive bugfixes that should not go into master (which should receive instead the proper and potentially invasive fix). I see a few alternatives here: a) stop merging mesa_7_7_branch - master. bugfixes should be applied to both branches. preferably by the person that wrote the patch. b) when applying a non-trivial bugfix to mesa_7_7_branch, the same person should do the merge into master, and undo any undesired change, or update for interface changes in master. Note however that it's better to give a few days between applying to mesa_7_7_branch and merging into master, to allow for wider testing, otherwise we'll be merging like crazy. c) do not apply any non trivial bugfix to mesa_7_7_branch anymore, and use a separate branch for those. I don't feel strongly about any of these alternatives for now. We'll eventually need to setup a private branch for our release so c) is bound to happen anyway. But I also think we can't keep merging mesa_7_7_branch into master like this forever -- after so much thought was put into the gallium interface changes (feature branches, peer review, etc) but whenever a mesa_7_7_branch - master happens all sort of wrong code is merged automatically. The ideal would be to peer-review the merges before committing, but it seems difficult to do that with git, while preserving merge history and not redoing merges. Jose -- 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] VMWARE SVGA, gallium + xorg
On Sat, 2010-01-23 at 01:33 -0800, Sorin Popescu wrote: It almost builds now but there's still a bit of a screwup in vmw_screen_pools.c, fenced_bufmgr_create is gone. The debug code below it works fine though. Also, pb_buffer_fenced.c is missing from auxilliary/Makefile. Sorry I can't be more helpful. This was due to the recent merge. It should be fixed now. BTW, the attention of most developers working on vmware svga pipe driver is focused on the mesa_7_7_branch. Most testing is happening there and bugfixes land there first too. I'm not telling that you should mesa_7_7_branch -- master does have more state trackers --, just that this sort of small breakage is likely to happen for a couple of months until developers start focusing on master again. Jose -- 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] TGSI build and sse2 removal
Michal, On Mon, 2010-01-25 at 06:27 -0800, michal wrote: I would like to have those two modules go away, as they are maintenance pain with no real benefits. The build module has been superseded by the ureg module, and apparently all third-party code has already migrated or is in the process of porting to new interface. I would like to nuke it if nobody minds. I'm fine with this. For sse2, I am looking at simplifying it enough to be able to accelerate pass-thru fragment shaders and simple vertex shaders. That's it. For more sophisticated stuff we already have llvmpipe. I agree with this in principle, but I think it's better not to get too much ahead of ourselves here: drivers are using tgsi_exec/sse2 for software vertex processing fallbacks. And while the plan is indeed to move the LLVM JIT code generation out of llvmpipe into the auxiliary modules so that all pipe drivers can use that for fallbacks, the fact is we're not there yet. So for tgsi_sse2 I think it's better not to introduce any performance regressions in vertex processing until llvm code generation is in place and working for everybody. Jose -- 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] mesa_7_7_branch - master merges
On Mon, 2010-01-25 at 09:52 -0800, tom fogal wrote: writes: [snip] The ideal would be to peer-review the merges before committing, but it seems difficult to do that with git, while preserving merge history and not redoing merges. Google has developed an infrastructure to do peer review using git. `Gerrit': http://code.google.com/p/gerrit/ My understanding is that the basic idea is like bzr's PQM, except the gatekeeper is human. I haven't delved into it more deeply, because the server system sounds like one of those java/tomcat/servlet monstrosities that scares me, but it's probably worth checking out if you feel strongly about this kind of thing. Bias up front: I'm really looking to get the opinion of a non-googler as to the efficacy/setup pain of the system, so I'm trying to get you to be my guinea pig ;) Review infrastructures are nice. I'd have some bias towards http://www.reviewboard.org/ by the similar reasons ;) But automated infrastructures aside, my worry with reviewing merges is the actual constraints that git has. For example, let's suppose the following scenario: 1) Developer A merges a stable branch into master. 2) After spending a bunch of time fixing conflicts the best he can, he emails the patch to mesa3d-dev for peer review. 3) Developer B checks in a change into master. 4) Developer A takes feedback from list, updates the code, and commits. 5) Developer A cannot push because remote head has moved. So what can Developer A do now? a) Redo the merge, using the new master head. b) Rebase the merge on top of the new head (I'm not sure it works, or that it preserves branch history) c) Double merge, i.e., merge its local head with the new master head. Note that this problem is not specific to reviews -- pushing merges can always lead to this same situation --, but reviews of merges increase the probability of this problem from unlikely to guaranteed. Jose -- 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] python and constant buffers
On Wed, 2010-01-20 at 03:55 -0800, michal wrote:
Jose,
How one can upload data to buffers in python state tracker?
I am trying to do the following:
+cb0_data = [
+0.0, 0.0, 0.0, 0.0,
+0.0, 0.0, 0.0, 1.0,
+1.0, 1.0, 1.0, 1.0,
+2.0, 4.0, 8.0, 1.0,
+]
+
+constbuf0 = dev.buffer_create(
+16,
+PIPE_BUFFER_USAGE_CONSTANT |
+ PIPE_BUFFER_USAGE_GPU_READ |
+ PIPE_BUFFER_USAGE_GPU_WRITE |
+ PIPE_BUFFER_USAGE_CPU_READ |
+ PIPE_BUFFER_USAGE_CPU_WRITE,
+4 * 4 * 4)
+
+constbuf0.write_(cb0_data, 4 * 4 * 4)
But I can't find a way to convert a list of floats to (char *). Do have
an idea how to do it?
Hi Michal,
The Gallium - Python bindings are autogenerated by SWIG and there are
several things which are not very pythonic. Writing data into/out of
the buffers is one of them.
ATM the only way to do this is using the python struct module, and pack
the floats into a string... That is:
import struct
data = ''
data += struct.pack('4f', 1.0, 2.0, 3.0, 4.0)
...
Jose
--
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] Gallium semantics for nested pipe_buffer map/unmap?
I think we should forbid recursive maps of the same buffer. Direct3D10 also forbids them: http://msdn.microsoft.com/en-us/library/ee418691(VS.85).aspx This has however some implications for draw module and the way state trackers setup vertex buffers: either we force state trackers to never pass the same buffer twice in set_vertex_buffers, or the draw module has to check this and map the buffer only once. Also, pipe_screen::buffer_map_range should be modified to return the pointer to the range, like the GL extension. Jose On Mon, 2010-01-18 at 15:56 -0800, Luca Barbieri wrote: What are the Gallium semantics for nested buffer maps and unmaps? The current situation seems the following: - Nouveau doesn't support nested mapping. It fully supports them with a patch to libdrm I posted. - r300 fully supports nested mapping - VMware supports nested mapping, but only the outermost map can be for writing (strange...) - In OpenGL, nested mapping is disallowed Those who support nested maps do it by using a map counter. All drivers seem to ignore the range and just map the whole buffer. Note that nesting with map_range would require to keep a LIFO stack of mappings in the driver since unmap does not take the address as a parameter. What does the Gallium interface specify, or what do we want it to be? It seems that whatever is chosen as the interface, some drivers will need to be fixed. I see two possible avenues: 1. Ban nested mapping. This is somewhat uncomfortable for those who need to map multiple buffers at once, which may or may not be the same one. 2. Fully allow nested mapping, even with unpaired map/unmap, but add an address parameter to unmap. Drivers are required to reuse the same mapping for non-range maps, but may not do so for map_range. In that case, they can check whether the address being unmapped is the whole buffer mapping and if so lower the map count, and otherwise directly call munmap or the equivalent. -- 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 -- 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] Mesa (glsl-pp-rework-2): scons: Get GLSL code building correctly when cross compiling.
On Mon, 2010-01-11 at 15:28 -0800, Stephan Raue wrote: Hi all, Am 10.12.2009 17:36, schrieb José Fonseca: On Thu, 2009-12-10 at 08:31 -0800, Jose Fonseca wrote: Module: Mesa Branch: glsl-pp-rework-2 Commit: 491f384c3958067e6c4c994041f5d8d413b806bc URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=491f384c3958067e6c4c994041f5d8d413b806bc Author: José Fonsecajfons...@vmware.com Date: Thu Dec 10 16:29:04 2009 + scons: Get GLSL code building correctly when cross compiling. This is quite messy. GLSL code has to be built twice: one for the host OS, another for the target OS. is there also an solution for building without scons? i am get the follow when i am crosscompile for x86_64 target with i386 host: gmake[3]: Entering directory `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa/shader/slang/library' ../../../../../src/glsl/apps/compile fragment slang_common_builtin.gc slang_common_builtin_gc.h ../../../../../src/glsl/apps/compile: ../../../../../src/glsl/apps/compile: cannot execute binary file gmake[3]: *** [slang_common_builtin_gc.h] Error 126 gmake[3]: Leaving directory `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa/shader/slang/library' gmake[2]: *** [glsl_builtin] Error 1 gmake[2]: Leaving directory `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/stephan/projects/openelec/build.OpenELEC-intel_x64.x86_64.devel/Mesa-master-20100108/src' make: *** [default] Error 1 Nope, and I don't think it will be easy, since Mesa's makefile system doesn't support building stuff on a separate dir. Jose -- 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] Build failure of Mesa 7.7 with SCons on Windows
Hi,
I never tried to build with MinGW on windows. Only with cross
compilation.
MSVC linker works around limitations in the command line length by using
tempfiles.
gnu ld also allows to do the same. So it should be a matter of enabling
doing the same trick in SCons/Tool/mingw.py that is done in
SCons/Tool/mslink.py, like:
env['LINKCOM'] = '${TEMPFILE($LINK $LINKFLAGS /OUT:$TARGET.windows
$_LIBDIRFLAGS $_LIBFLAGS $_PDB $SOURCES.windows)}'
It's kind of an advanced thing to do. I'd like to help you but I'm quite
busy so it will take a while until I get back to you.
Alternatively, if you're confortable with linux, cross compiling to
MinGW on linux works perfectly well.
Jose
On Sun, 2010-01-10 at 09:32 -0800, Sir Gallantmon wrote:
Hello,
I was trying to build Mesa 7.7 with SCons on Windows using TDM-GCC
MinGW 4.4.1-tdm-2 with the following output:
C:\projects\mesa_7_7scons platform=windows machine=x86
statetrackers=mesa drivers=softpipe,trace winsys=gdi
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Compiling src\gallium\auxiliary\cso_cache\cso_cache.c ...
Compiling src\gallium\auxiliary\cso_cache\cso_context.c ...
Compiling src\gallium\auxiliary\cso_cache\cso_hash.c ...
Compiling src\gallium\auxiliary\draw\draw_context.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_aaline.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_aapoint.c ...
Archiving build\windows-x86\gallium\auxiliary\cso_cache
\libcso_cache.a ...
Compiling src\gallium\auxiliary\draw\draw_pipe_clip.c ...
Indexing build\windows-x86\gallium\auxiliary\cso_cache
\libcso_cache.a ...
Compiling src\gallium\auxiliary\draw\draw_pipe_cull.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_flatshade.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_offset.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_pstipple.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_stipple.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_twoside.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_unfilled.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_util.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_validate.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_vbuf.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_wide_line.c ...
Compiling src\gallium\auxiliary\draw\draw_pipe_wide_point.c ...
Compiling src\gallium\auxiliary\draw\draw_pt.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_elts.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_emit.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_fetch.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_fetch_emit.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_fetch_shade_emit.c ...
Compiling src\gallium\auxiliary\draw
\draw_pt_fetch_shade_pipeline.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_post_vs.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_util.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_varray.c ...
Compiling src\gallium\auxiliary\draw\draw_pt_vcache.c ...
Compiling src\gallium\auxiliary\draw\draw_vertex.c ...
Compiling src\gallium\auxiliary\draw\draw_vs.c ...
Compiling src\gallium\auxiliary\draw\draw_vs_aos.c ...
Compiling src\gallium\auxiliary\draw\draw_vs_aos_io.c ...
Compiling src\gallium\auxiliary\draw\draw_vs_aos_machine.c ...
Compiling src\gallium\auxiliary\draw\draw_vs_exec.c ...
Compiling src\gallium\auxiliary\draw\draw_vs_llvm.c ...
Compiling src\gallium\auxiliary\draw\draw_vs_ppc.c ...
Compiling src\gallium\auxiliary\draw\draw_vs_sse.c ...
Compiling src\gallium\auxiliary\draw\draw_vs_varient.c ...
C:\Python26_w32\Scripts\..\python.exe src\gallium\auxiliary\indices
\u_indices_gen.py build\windows-x86\gallium\auxilia
ry\indices\u_indices_gen.c
Compiling build\windows-x86\gallium\auxiliary\indices
\u_indices_gen.c ...
C:\Python26_w32\Scripts\..\python.exe src\gallium\auxiliary\indices
\u_unfilled_gen.py build\windows-x86\gallium\auxili
ary\indices\u_unfilled_gen.c
Compiling src\gallium\auxiliary\pipebuffer\pb_buffer_fenced.c ...
Compiling build\windows-x86\gallium\auxiliary\indices
\u_unfilled_gen.c ...
Archiving build\windows-x86\gallium\auxiliary\draw\libdraw.a ...
Indexing build\windows-x86\gallium\auxiliary\draw\libdraw.a ...
Compiling src\gallium\auxiliary\pipebuffer\pb_buffer_malloc.c ...
Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_alt.c ...
Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_cache.c ...
Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_debug.c ...
Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_fenced.c ...
Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_mm.c ...
Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_ondemand.c ...
Compiling src\gallium\auxiliary\pipebuffer\pb_bufmgr_pool.c ...
Re: [Mesa3d-dev] RFC: Generalize the alignment macros to other compilers and any alignment.
On Mon, 2010-01-11 at 11:19 -0800, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
Attached is a patch that generalizes the ALIGN16/8_XXX macros in
p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
bytes.
There is more than one way to have cross-platform alignment macros --
all quite ugly.
The major complication here is that GCC and MSVC syntax for type/vars
attributes differs. MSVC's attributes are before types/vars
declarations. GCC's attributes are in general after the types/vars
declarations, although it is possible to put var attributes before too.
For more detail read:
- http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Attribute-Syntax.html
- http://msdn.microsoft.com/en-us/library/83ythb65.aspx
The approach I chose in the attached patch was to define the alignment
macros to contain the whole declaration as an argument, e.g.:
I encountered this problem when I was working with the vector math
library in Bullet. I've since stopped using that library (the SSE
routines we completely untested and very buggy), but my recollection is
that GCC will take the attribute either before or after.
I created a macro ALIGN16 and s/__declspec\(align\(16\)\)/ALIGN16/g.
This code worked with both GCC and, IIRC, Visual Studio 2005.
#ifdef __GNUC__
# define ALIGN16 __attribute__((aligned(16)))
#else
# define ALIGN16 __declspec(align(16))
#endif
...
inline const Matrix3 Matrix3::scale(const Vector3 scaleVec)
{
__m128 zero = _mm_setzero_ps();
ALIGN16 unsigned int select_x[4] = {0x, 0, 0, 0};
ALIGN16 unsigned int select_y[4] = {0, 0x, 0, 0};
ALIGN16 unsigned int select_z[4] = {0, 0, 0x, 0};
return Matrix3(
Vector3( vec_sel( zero, scaleVec.get128(), select_x ) ),
Vector3( vec_sel( zero, scaleVec.get128(), select_y ) ),
Vector3( vec_sel( zero, scaleVec.get128(), select_z ) )
);
}
It seems like you ought to be able to define a similar PIPE_ALIGN(x),
and just prefix that on declarations.
I agree that both of the proposed options are really ugly.
I noticed GCC allows prefixed attributes for var declarations, but I was
unsure if there were any caveats since all references I could google
suggested postfixing. But if worked well for you then we could do that
instead -- it does looks a bit closer to normal C.
This won't work for types though, since according the gcc docs the type
attribute must be immediately after struct keyword, or after the
closing '}'.
Jose
--
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] c99 again [was: Re: [PATCH] Fix compressed texture loads for non-minimal pitches]
On Mon, 2010-01-11 at 12:42 -0800, Luca Barbieri wrote: But for Mesa core and shared Gallium code, we target portability and that means pretty strict C90... Well, then maybe -std=c99 should be removed from the global config and put in driver Makefiles. Yes, that's a good idea. Anyway, it's not obvious that anyone is using a non-C99 compiler to compile Mesa, and they could probably switch to gcc if they are. I wish that was that simple. The only mainstream compiler I know that doesn't support C99 is MSVC. My hunch is that facilitating developers to write cross-platform code is not really a high priority... I personally use MinGW cross-compiler for most of my windows development, but unfortunately MinGW toolchain lacks some polish and integration features that make it unacceptable for windows driver development. There are often MinGW specific bugs in gcc, and because MS doesn't publish any info concerning their debugging information format there is no integration with most Windows development/debugging tools: in particular if a crash happens and the stack trace crosses both mingw modules and msvc modules then you're pretty much screwed, as neither MS debugger or gdb will handle it... mingw's gdb port also behaves erratically some times. So this means we really can't ignore MSVC. Jose -- 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] [PATCH] Add EGL/GLX extension for direct Gallium access
On Fri, 2010-01-01 at 10:13 -0800, José Fonseca wrote: On Tue, 2009-12-29 at 15:41 -0800, Luca Barbieri wrote: The reason why I didn't implement the glX*Gallium*Mesa functions is because the glx* extensions are implemented by libGL, and a driver driver never has chance to export those extensions. And libGL is used for non-gallium drivers. I solved this by adding a DRI driver extension for Gallium. Non-Gallium drivers don't expose the extension and GLX returns null for the calls. Also, EGL support is either through egl_glx (based on the GLX extension) or through the OK. Looks good to me. Furthermore, both on WGL and GLX the hardware specific driver is loaded quite late -- when the first GL context is created --, so the idea of having GL context independent extensions to create Gallium pipe_screens and pipe_contexts sounds good in theory but it's not how things work in practice. My tests based on egl_glx worked without creating an EGL context. It seems it's not necessary, even though it may need some other GLX call (which you need anyway for fbconfig/visual setup). I think it can be easily fixed though. So both things considered, using gl* extensions names instead of wgl*/glx* would make more sense: - libGL could remain untouched - same extensions names for all OSes It has however the disadvantage of requiring Mesa and the OpenGL state tracker even for Gallium-only applications. With the current interface you could in principle remove both and still run Gallium code, while using EGL/GLX only for window system setup. In particular, an EGL application using the Gallium EGL state tracker could run without libmesa.a with little adjustments and without libmesagallium.a with some more adjustments. Maybe a direct Gallium state tracker could be added, but it would require duplicating the X11/DRM setup logic in EGL and GLX. In my view Gallium isn't an interface meant for applications and direct accessing Gallium interface is exclusively for development/testings purposes. Whatever works is good. Just to be clear -- names is not the big issue here, but keeping libGL.so Gallium agnostic is an important thing in the current circumstances -- libGL.so shouldn't be tied to any particular driver architecture in any way. My patch doesn't add a Gallium dependency to libGL since all the work happens behind the DRI Gallium extension. The only Gallium specific code is struct pipe_screen; struct pipe_context; struct pipe_surface; to declare the opaque structures which are exposed to the users. The patches look good to me. I'm not familiar with EGL though, and I haven't touched DRI in quite some time. Please allow a bit more time for people to come back from vacations. I think that there was enough time for everybody interested to voice their opinion. I'm going to start committing Luca's patches. Jose -- 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] RFC: Generalize the alignment macros to other compilers and any alignment.
Attached is a patch that generalizes the ALIGN16/8_XXX macros in
p_compiler.h to work on MSVC and handle alignments beyond 8 and 16
bytes.
There is more than one way to have cross-platform alignment macros --
all quite ugly.
The major complication here is that GCC and MSVC syntax for type/vars
attributes differs. MSVC's attributes are before types/vars
declarations. GCC's attributes are in general after the types/vars
declarations, although it is possible to put var attributes before too.
For more detail read:
- http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Attribute-Syntax.html
- http://msdn.microsoft.com/en-us/library/83ythb65.aspx
The approach I chose in the attached patch was to define the alignment
macros to contain the whole declaration as an argument, e.g.:
PIPE_ALIGN_TYPE(16,
struct {
float rgba[4];
});
PIPE_ALIGN_VAR(16, float rgba[4]);
Another alternative would be to define pre-/post-fix macros, where
alignment would have to be passed twice:
PIPE_ALIGN_TYPE_BEGIN(16)
struct {
float rgba[4];
}
PIPE_ALIGN_TYPE_END(16);
PIPE_ALIGN_VAR_BEGIN(16)
float rgba[4]
PIPE_ALIGN_VAR_END(16);
Or provide a mixture or union of all the above macros.
I honestly don't care either way -- they all look ugly to me --, as long
it works with all compilers I'm happy to go either way.
With this patch it is possible to build and run llvmpipe on windows with
MSVC.
Jose
From f92e5cc7b8991e7ef5dc77246daeff0cb51c707f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Fonseca?= jfons...@vmware.com
Date: Sun, 10 Jan 2010 12:58:11 +
Subject: [PATCH] gallium: Generalize the alignment macros to other compilers and any alignment.
---
src/gallium/auxiliary/draw/draw_vs_ppc.c |6 ++--
src/gallium/auxiliary/tgsi/tgsi_ppc.c|2 +-
src/gallium/drivers/cell/common.h|3 +-
src/gallium/drivers/cell/ppu/cell_context.h |8 +++---
src/gallium/drivers/cell/spu/spu_command.c |5 +--
src/gallium/drivers/cell/spu/spu_exec.c |6 +++-
src/gallium/drivers/cell/spu/spu_exec.h |4 +-
src/gallium/drivers/cell/spu/spu_funcs.c |2 +-
src/gallium/drivers/cell/spu/spu_main.h | 22 ++---
src/gallium/drivers/cell/spu/spu_render.c|2 +-
src/gallium/drivers/cell/spu/spu_vertex_fetch.c |2 +-
src/gallium/drivers/cell/spu/spu_vertex_shader.c | 15 ++-
src/gallium/drivers/llvmpipe/lp_quad.h |9 ---
src/gallium/drivers/llvmpipe/lp_setup.c |2 +-
src/gallium/drivers/llvmpipe/lp_test_blend.c | 20 +++---
src/gallium/drivers/llvmpipe/lp_test_conv.c |4 +-
src/gallium/include/pipe/p_compiler.h| 29 +++---
17 files changed, 80 insertions(+), 61 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_vs_ppc.c b/src/gallium/auxiliary/draw/draw_vs_ppc.c
index ad184bd..6179b5b 100644
--- a/src/gallium/auxiliary/draw/draw_vs_ppc.c
+++ b/src/gallium/auxiliary/draw/draw_vs_ppc.c
@@ -98,9 +98,9 @@ vs_ppc_run_linear( struct draw_vertex_shader *base,
/* loop over verts */
for (i = 0; i count; i += MAX_VERTICES) {
const uint max_vertices = MIN2(MAX_VERTICES, count - i);
- float inputs_soa[PIPE_MAX_SHADER_INPUTS][4][4] ALIGN16_ATTRIB;
- float outputs_soa[PIPE_MAX_SHADER_OUTPUTS][4][4] ALIGN16_ATTRIB;
- float temps_soa[TGSI_EXEC_NUM_TEMPS][4][4] ALIGN16_ATTRIB;
+ PIPE_ALIGN_VAR(16, float inputs_soa[PIPE_MAX_SHADER_INPUTS][4][4]);
+ PIPE_ALIGN_VAR(16, float outputs_soa[PIPE_MAX_SHADER_OUTPUTS][4][4]);
+ PIPE_ALIGN_VAR(16, float temps_soa[TGSI_EXEC_NUM_TEMPS][4][4]);
uint attr;
/* convert (up to) four input verts to SoA format */
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ppc.c b/src/gallium/auxiliary/tgsi/tgsi_ppc.c
index 138d2d0..cec5b11 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ppc.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ppc.c
@@ -51,7 +51,7 @@
* Since it's pretty much impossible to form PPC vector immediates, load
* them from memory here:
*/
-const float ppc_builtin_constants[] ALIGN16_ATTRIB = {
+PIPE_ALIGN_VAR(16, const float ppc_builtin_constants[]) = {
1.0f, -128.0f, 128.0, 0.0
};
diff --git a/src/gallium/drivers/cell/common.h b/src/gallium/drivers/cell/common.h
index d5f5c7b..aa29dcb 100644
--- a/src/gallium/drivers/cell/common.h
+++ b/src/gallium/drivers/cell/common.h
@@ -358,6 +358,7 @@ struct cell_spu_function_info
/** This is the object passed to spe_create_thread() */
+PIPE_ALIGN_TYPE(16,
struct cell_init_info
{
unsigned id;
@@ -370,7 +371,7 @@ struct cell_init_info
uint *buffer_status; /** points at cell_context-buffer_status */
struct cell_spu_function_info *spu_functions;
-} ALIGN16_ATTRIB;
+});
#endif /* CELL_COMMON_H */
diff --git a/src/gallium/drivers/cell/ppu/cell_context.h b/src/gallium/drivers/cell/ppu/cell_context.h
index 5c3188e..fa6e4f6 100644
---
Re: [Mesa3d-dev] [RFC] add support to double opcodes
On Wed, 2010-01-06 at 15:56 -0800, Zack Rusin wrote: On Wednesday 06 January 2010 14:56:35 Igor Oliveira wrote: Hi, the patches add support to double opcodes in gallium/tgsi. It just implement some opcodes i like to know if someone has suggestion about the patches. Hi Igor, first of all this should probably go into a feature branch because it'll be a bit of work before it's usable. The patches that you've proposed are unlikely what we'll want for double's. Keith, Michal and I discussed this on the phone a few days back and the biggest issue with doubles is that unlike the switch between the integers and floats they actually need bigger registers to accomodate them. Given that the registers in TGSI are untyped and its up to instructions to define the type it becomes hard for drivers to figure out the size of the registers beforehand. The solution that I personally like and what seems to becoming the facto standard when dealing with double support is having double precision values represented by a pair of registers. Outputs are either the pair yx or to the pair wz, where the msb is stored in y/w. For example: Idata 3.0 = (0x4008) in register r looks like: r.w =0x4008 ;high dword r.z = 0x ;low dword Or: r.y =0x4008 ;high dword r.x =0x ;low dword All source double inputs must be in xy (after swizzle operations). For example: d_add r1.xy, r2.xy, r2.xy Or d_add r1.zw, r2.xy, r2.xy Each computes twice the value in r2.xy, and places the result in either xy or zw. This assures that the register size stays constant. Of course the instruction semantics are different to the typical 4-component wide TGSI instructions, but that, I think, is a lot less of an issue. z I wonder if storage size of registers is such a big issue. Knowing the storage size of a register matters mostly for indexable temps. For regular assignments and intermediate computations storage everything gets transformed in SSA form, and the register size can be determined from the instructions where it is generated/used and there is no need for consistency. For example, imagine a shader that has: TEX TEMP[0], SAMP[0], IN[0] // SAMP[0] is a PIPE_FORMAT_R32G32B32_FLOAT -- use 4x32bit float registers MAX ?? ... TEX TEMP[0], SAMP[1], IN[0] // SAMP[1] is a PIPE_FORMAT_R64G64B64A64_FLOAT -- use 4x64bit double registers DMAX , TEMP[0], ??? ... TEX TEMP[0], SAMP[2], IN[0] // texture 0 and rendertarget are both PIPE_FORMAT_R8G8B8A8_UNORM -- use 4x8bit unorm registers MOV OUT[0], TEMP[0] etc. There is actually programmable 3d hardware out there that has special 4x8bit registers, and for performance the compiler has to deduct where to use those 4xbit. llvmpipe will need to do similar thing, as the smaller the bit-width the higher the throughput. And at least current gallium statetrackers will reuse temps with no attempt to maintain consistency in use. So if the compilers already need to deal with this, if this notion that registers are 128bits is really necessary, and will prevail in the long term. Jose -- 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] [RFC] add support to double opcodes
On Thu, 2010-01-07 at 05:25 -0800, Zack Rusin wrote: On Thursday 07 January 2010 06:50:36 José Fonseca wrote: I wonder if storage size of registers is such a big issue. Knowing the storage size of a register matters mostly for indexable temps. For regular assignments and intermediate computations storage everything gets transformed in SSA form, and the register size can be determined from the instructions where it is generated/used and there is no need for consistency. For example, imagine a shader that has: TEX TEMP[0], SAMP[0], IN[0] // SAMP[0] is a PIPE_FORMAT_R32G32B32_FLOAT -- use 4x32bit float registers MAX ?? ... TEX TEMP[0], SAMP[1], IN[0] // SAMP[1] is a PIPE_FORMAT_R64G64B64A64_FLOAT -- use 4x64bit double registers DMAX , TEMP[0], ??? That's not an issue because such a format doesn't exist. There's no 256bit sampling in any api. It's one of the self-inflicted wounds that we have. R64G64 is the most you'll get right now. That's interesting. Never realized that. TEX TEMP[0], SAMP[2], IN[0] // texture 0 and rendertarget are both PIPE_FORMAT_R8G8B8A8_UNORM -- use 4x8bit unorm registers MOV OUT[0], TEMP[0] etc. There is actually programmable 3d hardware out there that has special 4x8bit registers, and for performance the compiler has to deduct where to use those 4xbit. llvmpipe will need to do similar thing, as the smaller the bit-width the higher the throughput. And at least current gallium statetrackers will reuse temps with no attempt to maintain consistency in use. So if the compilers already need to deal with this, if this notion that registers are 128bits is really necessary, and will prevail in the long term. Somehow this is the core issue it's the fact that TGSI is untyped anything but register size is constant implies TGSI is typed but the actual types have to be deduced by the drivers which goes against what Gallium was about (we put the complexity in the driver). The question of 8bit vs 32bit and 64bit vs 32bit are really different questions. The first one is about optimization - it will work perfectly well if the 128bit registers will be used, the second one is about correctness - it will not work if 128bit registers will be used for doubles and it will not work if 256bit registers will be used for floats. True. Also we don't have a 4x8bit instructions, they're all 4x32bit instructions (float, unsigned ints, signed ints), so doubles will be the first differently sized instructions. Which in turn will mean that either TGSI will have to be actually statically typed, but not typed declared i.e. D_ADD will only be able to take two 256bit registers as inputs and if anything else is passed it has to throw an error, which is especially difficult that those registers didn't have a size declared but it would have to be inferred from previous instructions, or we'd have to allow mixing sizes of all inputs, e.g. D_ADD can operate on both 4x32 or 4x64 which simply moves the problem from above into the driver. Really, unless we'll say the entire pipeline can run in 4x64 like we did for floats then I don't see an easier way of dealing with this than the xy, zw, swizzle form. Ok. I didn't felt strongly either way, but now I'm more convinced that restricting xy zw swizzles is less painful. Thanks for explaining this Zack. Jose -- 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] [RFC] add support to double opcodes
On Thu, 2010-01-07 at 08:42 -0800, Christoph Bumiller wrote: On 01/07/2010 12:50 PM, José Fonseca wrote: On Wed, 2010-01-06 at 15:56 -0800, Zack Rusin wrote: On Wednesday 06 January 2010 14:56:35 Igor Oliveira wrote: Hi, the patches add support to double opcodes in gallium/tgsi. It just implement some opcodes i like to know if someone has suggestion about the patches. Hi Igor, first of all this should probably go into a feature branch because it'll be a bit of work before it's usable. The patches that you've proposed are unlikely what we'll want for double's. Keith, Michal and I discussed this on the phone a few days back and the biggest issue with doubles is that unlike the switch between the integers and floats they actually need bigger registers to accomodate them. Given that the registers in TGSI are untyped and its up to instructions to define the type it becomes hard for drivers to figure out the size of the registers beforehand. The solution that I personally like and what seems to becoming the facto standard when dealing with double support is having double precision values represented by a pair of registers. Outputs are either the pair yx or to the pair wz, where the msb is stored in y/w. For example: Idata 3.0 = (0x4008) in register r looks like: r.w =0x4008 ;high dword r.z = 0x ;low dword Or: r.y =0x4008 ;high dword r.x =0x ;low dword All source double inputs must be in xy (after swizzle operations). For example: d_add r1.xy, r2.xy, r2.xy Or d_add r1.zw, r2.xy, r2.xy Each computes twice the value in r2.xy, and places the result in either xy or zw. This assures that the register size stays constant. Of course the instruction semantics are different to the typical 4-component wide TGSI instructions, but that, I think, is a lot less of an issue. z I wonder if storage size of registers is such a big issue. Knowing the storage size of a register matters mostly for indexable temps. For regular assignments and intermediate computations storage everything gets transformed in SSA form, and the register size can be determined from the instructions where it is generated/used and there is no need for consistency. For example, imagine a shader that has: TEX TEMP[0], SAMP[0], IN[0] // SAMP[0] is a PIPE_FORMAT_R32G32B32_FLOAT -- use 4x32bit float registers MAX ?? ... TEX TEMP[0], SAMP[1], IN[0] // SAMP[1] is a PIPE_FORMAT_R64G64B64A64_FLOAT -- use 4x64bit double registers DMAX , TEMP[0], ??? ... TEX TEMP[0], SAMP[2], IN[0] // texture 0 and rendertarget are both PIPE_FORMAT_R8G8B8A8_UNORM -- use 4x8bit unorm registers MOV OUT[0], TEMP[0] etc. TEX will output floats, independently of the bound texture, so this code makes no sense to me. I do *not* (want to have to) know what will be bound to the sampler in advance, or produce a new shader for every different format. If TEX is to output doubles, make it D_TEX. Yes, that's fair enough. My point here is that one could avoid the double conversion as an optimization. That may not be the case of nvidia hardware, but there's 3d hardware out there where this sort of analysis will happen for e.g., for 4x8bit formats. It's not 3d hardware, but this will certainly be case for llvmpipe: we'll want to check if the sampler formats and rendertarget formats are rgba8 and produce specialized shaders using 16x8bit SIMD instructions for those. Jose -- 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] Mystery of u_format.csv
On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: 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, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Jose -- 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] Mystery of u_format.csv
On Wed, 2010-01-06 at 06:11 -0800, michal wrote: José Fonseca wrote on 2010-01-06 15:03: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: 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, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. I did this because in the other thread you defined arith layout to apply to 32-or-less-bit formats. Since I still believe arith and array layout are somewhat redundant, we can go the other way round and convert other arith layouts to array, save for 16-or-less-bit formats. Indeed arith applies to 32-or-less-bit formats, but I never meant to say that all 32-or-less-bit formats must be in arith. They are indeed redundant, but array is/will be more efficient and when code generation is more robust and big-endian-safe all x8, x8x8, x8x8x8, x8x8x8x8x8 formats will be likely in array layout. Jose -- 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] Mystery of u_format.csv
On Wed, 2010-01-06 at 06:32 -0800, michal wrote: Michel Dänzer wrote on 2010-01-06 15:23: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: 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, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, and IMO 'arith' formats should be defined in the CPU endianness. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Interesting. Is there any reference that would say which formats are 'array', and which are not? Or is it a simple rule that when every component's bitsize is greater-or-equal to, say, 16, then it's an array format? There isn't really a rule, and I haven't profiled code enough to tell which algorithm is faster for swizzling -- bit shifting arithmetic or byte/word/dword indexation. My expectation is that byte/word/dword indexation will be faster for n x 8bit formats. In particular there is sse3 instruction PSHUFB can swizzle any n x 8bit format, 16 channels at a time. Where as bit SSE2 bit shift arithmetic instructions can only do 4 or 8 channels at a time, for 32bit and 16bit formats respectively. Again, this is only relevant for the generating CPU routines that will do pixel translation. GPU drivers should behave identically regardless of this layout. Jose -- 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] Mystery of u_format.csv
On Wed, 2010-01-06 at 06:51 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: 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, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. Yes, that's probably the best. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... Basically a developer implementing a pipe drivers for a hardware should not have to worry about CPU endianness. If a graphics API define formats in terms of the native CPU endianness then the state tracker will have to do the translation. That's more or less what I meant in my last sentence above. Hopefully it'll be possible to share this between state trackers at least to some degree via an auxiliary module or so. At least OpenGL and X11 define (some) formats in CPU endianness. OK. We agree then. I don't know how you envision this auxiliary functionality. I don't think it is actually necessary to define a bunch of PIPE_FORMAT__REV formats, given that no hardware will ever support them. Instead code generate a variation of u_format_access.py which reads formats in native endianness should suffice. That is void util_format_read_4f_native
Re: [Mesa3d-dev] Mystery of u_format.csv
On Wed, 2010-01-06 at 07:03 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 15:51 +0100, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:32 +, José Fonseca wrote: On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: On Wed, 2010-01-06 at 14:03 +, José Fonseca wrote: On Tue, 2010-01-05 at 23:36 -0800, michal wrote: michal wrote on 2010-01-06 07:58: michal wrote on 2009-12-22 10:00: Marek Olšák wrote on 2009-12-22 08:40: 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, Yes, that seems like a defect. The format swizzle field tells us how to swizzle the incoming pixel so that its components are ordered in some predefined order. For RGB and SRGB colorspaces the order is R, G, B and A. For depth-stencil, ie. ZS color space the order is Z and then S. I will have a look at this. Marek, Jose, Can you review the attached patch? Ouch, it looks like we will have to leave 24-bit (s)rgb formats with array layout as the current code generator will bite us on big endian platforms. Attached an updated patch. Why are you changing the layout from array to arith? Please leave that alone. Yes, the code generator needs a big_ending - little endian call to be correct on big endian platforms, as gallium formats should always be thougth of in little endian terms, just like most hardware is. Actually, 'array' formats should be endianness neutral, Yep. and IMO 'arith' formats should be defined in the CPU endianness. I originally thought that too, but Keith convinced me that gallium is a hardware abstraction, and all 3d hardware is little endian, therefore gallium formats should be always in little endian. Then there probably should be no 'arith' formats, at least not when the components consist of an integer number of bytes. ... and at least for some others, e.g. 16 bit 565 or 1555 formats, 'always little endian' would mean that some API formats couldn't be represented by Gallium formats on big endian CPUs. So there would have to be a 'reverse byte order' bit at least. Just to see if I have the right facts here: does ATI NVIDIA hardware only support little endian 565 and 1555 formats, or do they also support the big endian formats too? Jose -- 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] [PATCH] Compile with -fvisibility-hidden by default
On Sun, 2010-01-03 at 12:55 -0800, Kristian Høgsberg wrote: On Sun, Jan 3, 2010 at 3:24 PM, José Fonseca jfons...@vmware.com wrote: On Sun, 2010-01-03 at 08:45 -0800, Brian Paul wrote: 2010/1/2 Chia-I Wu olva...@gmail.com: On Sat, Jan 02, 2010 at 07:01:02PM -0500, Kristian Høgsberg wrote: We have all functions that need to be visible marked with PUBLIC and this is trimming around 4% off the DRI driver .so size. I love this change! It might require another patch, but would it be possible to stop marking functions like _mesa_GenTextures as GLAPIENTRY? I think they are not public either in normal build. This would have to be checked on Windows. I think the x86 dispatch code is sensitive to the Windows calling conventions implied by GLAPIENTRY. Brian is right. GLAPI controls symbol visibility, both on unices (i.e., _attribute__((visibility(default and windows (i.e., _declspec(dllexport). GLAPIENTRY controls the calling convention (i.e., __stdcall presence or absence). This can be easily seen on top of GL/GL.h. So in summary, GLAPI can and probably should be removed for _mesa_* functions. GLAPIENTRY cannot. Ok, from all this I didn't see anything against enabling -fvisibility-hidden by default so I've committed the patch. Also, the _mesa_* entrypoints are only GLAPIENTRY, not GLAPI, so they are already hidden. FWIW I also think that-fvisibility-hidden by default is a good a thing. It's been ages ago and my memory is fuzzy, but I recall that when I was doing some work on Xgl there were problems because mesa internal symbols in the GL driver were colliding with Xorg's GLcore extension or something along those lines. Jose -- 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] [PATCH] Gallium API demos and supporting infrastructure
On Thu, 2009-12-31 at 01:37 -0800, Luca Barbieri wrote: This is a series of 4 patches that add the required infrastructure for writing Gallium demos and programs and include two such demos, galliumgears and galliumglobe. The first two patches have already been posted, but I am including them again in git format-patch format as part of the series (they were manually generated). The patches are all attached, and the commit message of the third and fourth is replicated in the message body for easier reading. From 04597af67fb6fa556e04ee5b293ad2b774178cbf Mon Sep 17 00:00:00 2001 From: Luca Barbieri l...@luca-barbieri.com Date: Thu, 31 Dec 2009 09:41:38 +0100 Subject: [PATCH 3/4] Add utility framework for Gallium programs This is an utility library called galliumut, designed to make writing Gallium applications (as opposed to state trackers) easier. It is put in gallium/programs since it doesn't follow the same coding standards and doesn't share the same goal of gallium/auxiliary. It requires my EGL_MESA_gallium extension patch to allow creation of a Gallium context capable of displaying surfaces to the user. For X11 usage, it also requires my MESA_screen_surface patch to make egl_glx automatically create a maximized window for EGL programs. * galliumut.h contains miscellaneous utility functions, easy framebuffer setup functions, mesh (vertex+index buffer) utilities and creation of common state objects * egl_gallium.c uses the MESA_screen_surface and EGL_MESA_gallium to set up a pipe_context and pipe_framebuffer_state suitable for drawing to the screen and implements a render loop * image.c/image.h uses the gdk-pixbuf library to create a pipe_texture from an image in the filesystem * ureg_lib.h adds utility functions, asin/acos, normalize and vector transform functions to ureg * uureg.h is a wrapper around ureg which allows to write much terser shaders. It features, for instance, a short macro for each possible swizzle and writemask, macros that don't include the ureg word, and automatic conversion of ureg_dst and scalars to ureg_src. * math_lib.h is a 3/4-sized vector/matrix library with SSE/SSE2 optimization math_lib_fp.h and math_lib_fp_transform.h are internally used headers * test_math tests math_lib.h * normal_gen.c/normal_gen.h include vertex and fragment shaders for normal map generation From 5a855511dfc524e298696f4356cf56595fc584e1 Mon Sep 17 00:00:00 2001 From: Luca Barbieri l...@luca-barbieri.com Date: Thu, 31 Dec 2009 10:24:09 +0100 Subject: [PATCH 4/4] Add galliumgears and galliumglobe Gallium API demos This patch includes two demos which don't use OpenGL, but directly draw using the Gallium3D API, with context setup done using EGL through the galliumut framework. They require my MESA_screen_surface, EGL_MESA_gallium and galliumut patches This provides a direct demonstration of the Gallium API. In addition to having fun writing Gallium demos, test suites for Gallium drivers can be written in this fashion. galliumgears is a Gallium remake of the gears demo. In addition to the classic demo it features: - Smart frustum which never puts the gears offscreen - Per-pixel diffuse and specular lighting (can be disabled to get the classic gears look) - Better meshes for gears with configurable amount of triangles for better rounded interiors - Configurable gear speed galliumglobe is a new demo which renders a pixel-perfect spinning Earth globe. It works this way: 1. Downloads NASA Blue Marble imagery for Earth color, altitude and nighttime lighting. 2. Uses the GPU to generate mipmaps and a spherical normal map from the heightmaps 3. Optionally builds a triangle fan which rasterizes to a perfect circle (1000-8000 triangles will be used for normal display sizes), and otherwise uses KIL in the fragment shader 4. For each window resize, uses the GPU to generate a texture containing 16-bit (split into 2 8-bit values) map projection u, v coordinates for points on the screen 5. Uses a fragment shader that for each point in a circle on the screen, gets the u,v coordinates from the texture, applies latitude translation and does diffuse/specular calculation using pre-rotated light and half vectors Anisotropic filtering is used for quality rendering at the poles and equator extremes. The demo is configurable in many ways: see the usage message for more information. The demos have been tested with softpipe and nv40, and may need adjustments to work on other drivers. Luca, This is great stuff, and it couldn't have been in better timing. I was just about to get the python gallium tests we have working with llvmpipe too, and your work will save me a bunch of time. Instead of mesa/src/gallium/programs/ I'd prefer to have these on mesa/progs/gallium/, to keep the drivers/APIs in mesa/src samples/tests in mesa/progs. I'm going to move the python tests/examples from
Re: [Mesa3d-dev] [PATCH] Add EGL/GLX extension for direct Gallium access
On Tue, 2009-12-29 at 15:41 -0800, Luca Barbieri wrote: The reason why I didn't implement the glX*Gallium*Mesa functions is because the glx* extensions are implemented by libGL, and a driver driver never has chance to export those extensions. And libGL is used for non-gallium drivers. I solved this by adding a DRI driver extension for Gallium. Non-Gallium drivers don't expose the extension and GLX returns null for the calls. Also, EGL support is either through egl_glx (based on the GLX extension) or through the OK. Looks good to me. Furthermore, both on WGL and GLX the hardware specific driver is loaded quite late -- when the first GL context is created --, so the idea of having GL context independent extensions to create Gallium pipe_screens and pipe_contexts sounds good in theory but it's not how things work in practice. My tests based on egl_glx worked without creating an EGL context. It seems it's not necessary, even though it may need some other GLX call (which you need anyway for fbconfig/visual setup). I think it can be easily fixed though. So both things considered, using gl* extensions names instead of wgl*/glx* would make more sense: - libGL could remain untouched - same extensions names for all OSes It has however the disadvantage of requiring Mesa and the OpenGL state tracker even for Gallium-only applications. With the current interface you could in principle remove both and still run Gallium code, while using EGL/GLX only for window system setup. In particular, an EGL application using the Gallium EGL state tracker could run without libmesa.a with little adjustments and without libmesagallium.a with some more adjustments. Maybe a direct Gallium state tracker could be added, but it would require duplicating the X11/DRM setup logic in EGL and GLX. In my view Gallium isn't an interface meant for applications and direct accessing Gallium interface is exclusively for development/testings purposes. Whatever works is good. Just to be clear -- names is not the big issue here, but keeping libGL.so Gallium agnostic is an important thing in the current circumstances -- libGL.so shouldn't be tied to any particular driver architecture in any way. My patch doesn't add a Gallium dependency to libGL since all the work happens behind the DRI Gallium extension. The only Gallium specific code is struct pipe_screen; struct pipe_context; struct pipe_surface; to declare the opaque structures which are exposed to the users. The patches look good to me. I'm not familiar with EGL though, and I haven't touched DRI in quite some time. Please allow a bit more time for people to come back from vacations. Jose -- 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] [PATCH] Add EGL/GLX extension for direct Gallium access
Hi Luca, This is something I'm very interested but I'm on travel and I'll need some more time to review it. Just a few quick thoughts. Python state tracker has the code to call glxGetGalliumScreenMESA and glxCreateGalliumContextMESA but I never got around to implement these functions on any glx/dri/etc state tracker, and I'm glad to see you making progress on that direction. The reason why I didn't implement the glX*Gallium*Mesa functions is because the glx* extensions are implemented by libGL, and a driver driver never has chance to export those extensions. And libGL is used for non-gallium drivers. Furthermore, both on WGL and GLX the hardware specific driver is loaded quite late -- when the first GL context is created --, so the idea of having GL context independent extensions to create Gallium pipe_screens and pipe_contexts sounds good in theory but it's not how things work in practice. So both things considered, using gl* extensions names instead of wgl*/glx* would make more sense: - libGL could remain untouched - same extensions names for all OSes Just to be clear -- names is not the big issue here, but keeping libGL.so Gallium agnostic is an important thing in the current circumstances -- libGL.so shouldn't be tied to any particular driver architecture in any way. Also, if these extensions become more than a hack for debugging gallium drivers then we need to start writing a spec for them too.. Jose On Fri, 2009-12-25 at 18:04 -0800, Luca Barbieri wrote: This patch adds two extensions, EGL_MESA_gallium and GLX_MESA_gallium, which allow an application to directly access the Gallium3D API bypassing OpenGL and using EGL or GLX for general setup. The python state tracker already uses the GLX_MESA_gallium functions (due to a commit by Jose Fonseca), but the functions are not actually implemented. There is already a WGL extension with wglGetGalliumScreenMESA and wglCreateGalliumContextMESA. A wglGetGalliumSurfacesMESA function should probably be added to match the EGL/GLX versions in this patch. It adds 3 functions: (egl|glx)GetGalliumScreenMESA: returns a pipe_screen for an X11 display/screen or an EGL display (egl|glx)CreateGalliumContextMESA: creates a pipe_context for an X11 display/screen or an EGL display (egl|glx)GetGalliumSurfacesMESA: returns all pipe_surface attachments for an X11 drawable or EGL surface The array returned by GetGalliumSurfacesMESA must be freed by the application. They are implemented for egl_glx, and the EGL and GLX DRI loaders and drivers. The egl_glx implementation simply wraps the GLX functions. The first two functions are trivially implemented, while GetGalliumSurfaces is trickier. The problem is that the current code assumes that a GL context is bound when getting surfaces, so most of the invasive changes in this patch remove this assumption. Currently, this only works for double buffered DRI surfaces, because the flush_framebuffer functions provided by DRI get the surface to flush from the current GL context. How to fix this is not obvious. An option could be to provide an (egl|glx)FlushFrontbuffer function with takes a drawable as input. Another option would be to change (egl|glx)SwapBuffers to do frontbuffer flushing without a GL context (it currently does that indirectly by calling glFlush()). Also currently surfaces are extracted from an st_framebuffer, which is not ideal as it keeps a dependency on the Mesa state tracker The patch assumes that my previous MESA_screen_surface patch has been applied. The patches are independent, but they textually conflict on the function tables. A GL_MESA_gallium extension could be implemented in the future for access to the underlying Gallium objects of OpenGL textures, buffers and renderbuffers. Some way to access the GLSL compiler without OpenGL would also be useful. --- include/EGL/eglext.h | 20 +++ include/GL/glxext.h | 20 +++ include/GL/internal/dri_interface.h | 19 +++ src/egl/drivers/glx/egl_glx.c | 28 ++ src/egl/main/eglapi.c | 40 ++- src/egl/main/eglapi.h | 11 src/egl/main/egldisplay.h |1 + src/egl/main/eglmisc.c|6 ++- src/gallium/state_trackers/dri/dri_drawable.c |4 +- src/gallium/state_trackers/dri/dri_screen.c | 38 ++ src/gallium/state_trackers/egl/egl_tracker.c | 26 + src/gallium/winsys/egl_xlib/egl_xlib.c| 54 +++- src/glx/x11/dri_common.c |7 +++ src/glx/x11/glxclient.h |7 +++ src/glx/x11/glxcmds.c | 69 + src/glx/x11/glxcurrent.c | 13 +++-- src/glx/x11/glxextensions.c |1 +
Re: [Mesa3d-dev] [PATCH] gallium: only create pipe buffer when size is nonzero
Maarten,
Looks good to me. Do you need someone to commit it for you?
Jose
On Wed, 2009-12-23 at 07:32 -0800, Maarten Maathuis wrote:
Anyone?
On Sun, Dec 20, 2009 at 2:03 PM, Maarten Maathuis madman2...@gmail.com
wrote:
- This fixes a crash upon starting spring (a rts engine/game).
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/mesa/state_tracker/st_cb_bufferobjects.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
b/src/mesa/state_tracker/st_cb_bufferobjects.c
index 63196af..494a3a9 100644
--- a/src/mesa/state_tracker/st_cb_bufferobjects.c
+++ b/src/mesa/state_tracker/st_cb_bufferobjects.c
@@ -170,15 +170,19 @@ st_bufferobj_data(GLcontext *ctx,
pipe_buffer_reference( st_obj-buffer, NULL );
- st_obj-buffer = pipe_buffer_create( pipe-screen, 32, buffer_usage,
size );
+ if (size != 0) {
+ st_obj-buffer = pipe_buffer_create(pipe-screen, 32, buffer_usage,
size);
- if (!st_obj-buffer) {
- return GL_FALSE;
+ if (!st_obj-buffer) {
+ return GL_FALSE;
+ }
+
+ if (data)
+ st_no_flush_pipe_buffer_write(st_context(ctx), st_obj-buffer, 0,
+ size, data);
+ return GL_TRUE;
}
- if (data)
- st_no_flush_pipe_buffer_write(st_context(ctx), st_obj-buffer, 0,
- size, data);
return GL_TRUE;
}
--
1.6.5.4
--
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] Mystery of u_format.csv
The data in u_format.csv was migrated from p_format which was full of inconsistencies. I've fixed some of these but there are others which I haven't. Read the pipe_format lookup table thread of mesa3d-dev if you want to know the background. I'll add more documentation to u_format.h. The gist is source channels come in a vector ordered from least significant bit - highest significant bit. Jose On Mon, 2009-12-21 at 23:40 -0800, Marek Olšák wrote: 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
Re: [Mesa3d-dev] [PATCH] gallium: add PIPE_CAP_QUADS_FOLLOW_FLATSHADE_FIRST_CONVENTION
On Thu, 2009-12-17 at 20:41 -0800, Marek Olšák wrote: 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 Hi Marek, One problem I have with this patch and many of past get_param changes for that matter, is that it changes default behavior and forces all pipe drivers to be updated. It is not the first time that a get_param changes broke drivers because it. I happened with PIPE_CAP_BLEND_EQUATION_SEPARATE. As the number of drivers is increases this is a no-no. It also complicates writing drivers since they have to answer a large number of queries, most of which are specific to one or two particular hardware devices. IMO, there are two ways to overcome this: a) when introducing new PIPE_CAP_xxx have its semantics such that 0 will yield the previous behavior b) change get_param/paramf prototype so that it is passed the default value as an argument. That said, reading http://www.opengl.org/registry/specs/EXT/provoking_vertex.txt , issue #2 (How should quads be handled?) it seems that 0 is actually a better default -- provoking vertex of quads does not apply to D3D and is only relevant for that extension. So I don't oppose for this to go in as is. But, independent of this change, lets fix the get_param/paramf calls. Keith, does b) above sound good to you? Jose -- 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] [PATCH] Fix u_pack_color.h rgb pack/unpack functions
On Tue, 2009-12-15 at 05:14 -0800, michal wrote: Guys, Does the attached patch make sense to you? I replaced the incomplete switch-cases with calls to u_format_access functions that are complete but are going to be a bit more expensive to call. Since they are used not very often in mesa state tracker, I thought it's a good compromise. Thanks. Looks good by me. Jose -- 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
