Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model
Christoph, This looks good. Thanks for bringing this back to life. Keith On Thu, 2010-12-16 at 07:47 -0800, Christoph Bumiller wrote: On 12/14/2010 12:36 PM, Keith Whitwell wrote: On Mon, 2010-12-13 at 12:01 -0800, Christoph Bumiller wrote: I want to warm this up again adding nvc0 and GL_ARB_separate_shader_objects to the picture. The latter extends GL_EXT_separate_shader_objects to support user defined varyings and guarantees well defined behaviour only if - varyings are declared inside the gl_PerVertex/gl_PerFragment block the blocks match exactly in name, type, qualification, and (most significantly) declaration order. - varyings are assigned matching location qualifiers: like: layout(location = 3) in vec4 normal The number of input locations available to a shader is limited. So, I propose to (loosely) identify GENERIC semantic indices with these location qualifiers and let the pipe driver set a limit on the allowed maximum (e.g PIPE_SHADER_CAP_MAX_INPUTS, and not demand to at least support 219 of them - nvc0 offsers 0x200 bytes for generic inputs/outputs). This sounds fine actually. We kicked this around before I was basically ok with the last iteration of the proposal, but this seems ok too. As far as I can tell from a gallium perspective you're really just proposing a new pipe cap _MAX_INPUTS (actually _MAX_GENERIC_INDEX would be clearer), which the state tracker thereafter has to respect? That would be fine with me. First attempt at a patch introducing such a cap attached. My motivation is mostly that the hardware routing table for shader varyings that was present on nv50 has been removed with nvc0 (Fermi). And I'm glad, because filling 4 routing tables (since we have 5 shader types now) is somewhat annoying. And so applying relocations to shaders - it can be done, it's probably not too time consuming, but it's just plain *unnecessary* (and thus stupid) for OpenGL. Now about d3d9 ... 1. don't care, I don't see a d3d9 state tracker 2. http://msdn.microsoft.com/en-us/library/bb509647%28v=VS.85%29.aspx says n is an optional integer between 0 and the number of resources supported - what supported means here isn't clear to me, but, I didn't find any example where someone used something OpenGL doesn't have (like COLOR2). 3. http://msdn.microsoft.com/en-us/library/bb944006%28v=vs.85%29.aspx#Varying_Shader_Inputs_and_Semantics says Input semantics are similar to the values in the D3DDECLUSAGE. and DECLUSAGE sounds like you're limited to sane values. I think you're on the right track with (1)... It's fairly pointless trying to discuss code here which isn't public I don't think people need to be worrying about what may or may not be important for code they can't see. I know this idea previously got tied up with speculation about what a DX9 state tracker might or might not require, but in retrospect I wish I'd been able to steer conversation away from that. The work on closed components may drive a lot of the feature development and new interfaces, but there's usually enough flexibility that this sort of cleanup isn't a big deal. Keith Not sure if anyone wants to think about this issue at this time (since implementation of ARB_separate_shader_objects is probably far in the GL4 future), but I'd be happy about any comments. Regards, Christoph On 04/13/2010 12:55 PM, Luca Barbieri wrote: This patch series is intended to resolve the issue of semantic-based shader linkage in Gallium. It can also be found in the RFC-gallium-semantics branch. It does not change the current Gallium design, but rather formalizes some limitations to it, and provides infrastructure to implement this model more easily in drivers, along with a full nv30/nv40 implementation. These limitations are added to allow an efficient implementation for both hardware lacking special support and hardware having support but also special constraints. Note that this does NOT resolve all issues, and there are quite a bit left to future refinement. In particular, the following issues are still open: 1. COLOR clamping (and floating point framebuffers) 2. A linkage table CSO allowing to specify non-identity linkage 3. BCOLOR/FACE-related issues 4. Adding a cap to inform the state tracker that more than 219 generic indices are provided This topic was already very extensively discussed. See http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg10865.html for some early inconclusive discussion around an early implementation that modified the GLSL linker (which is NOT being proposed here) See http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12016.html for some more discussion that seemed to mostly reach a consensus over the approach proposed here. See in particular http://www.mail-archive.com
Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model
form, and the capability can be generally useful anyway. === Discussion of possible options === [Options from Keith Whitwell, see http://www.opensource-archive.org/showthread.php?p=180719] a) Picking a lower number like 128, that an SM3 state tracker could usually be able to directly translate incoming semantics into, but which would force it to renumber under rare circumstances. This would make life easier for the open drivers at the expense of the closed code. b) Picking 256 to make life easier for some closed-source SM3 state tracker, but harder for open drivers. c) Picking 219 (or some other magic number) that happens to work with the current set of constraints, but makes gallium fragile in the face of new constraints. d) Abandoning the current gallium linkage rules and coming up with something new, for instance forcing the state trackers to renumber always and making life trivial for the drivers... [Options from me] (e) Allow arbitrary 32-bit indices. This requires slightly more complicated data structures in some cases, and will require svga and r600 to fallback to software linkage if numbers are too high. (f) Limit semantic indices to hardware interpolators _and_ introduce an interface to let the user specify an Personally I think the simplest idea for now could be to have all drivers support 256 indices or, in the case of r600 and svga, the maximum value supported by the hardware, and expose that as a cap (as well as another cap for the number of different semantic values supported at once). The minimum guaranteed value is set to the lowest hardware constraint, which would be svga with 219 indices (assuming no bcolor is used). If some new constraints pop up, we just lower it and change SM3 state trackers to check for it and fallback otherwise. This should just require simple fixes to svga and r300, and significant code for nv30/nv40, which is however already implemented. Luca Barbieri (5): tgsi: formalize limits on semantic indices tgsi: add support for packing semantics in SM3 byte values gallium/auxiliary: add semantic linkage utility code nvfx: support proper shader linkage - adds glsl support nvfx: expose GLSL Michal Krol (1): gallium: Remove TGSI_SEMANTIC_NORMAL. -- 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 -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] [RFC] Formalization of the Gallium shader semantics linkage model
On Tue, 2010-04-13 at 03:55 -0700, Luca Barbieri wrote: Personally I think the simplest idea for now could be to have all drivers support 256 indices or, in the case of r600 and svga, the maximum value supported by the hardware, and expose that as a cap (as well as another cap for the number of different semantic values supported at once). The minimum guaranteed value is set to the lowest hardware constraint, which would be svga with 219 indices (assuming no bcolor is used). If some new constraints pop up, we just lower it and change SM3 state trackers to check for it and fallback otherwise. Luca, Thanks for your patience and efforts in compiling this - I really appreciate the effort you've put into this and the persistence to keep coming back to it. The patchset looks good to me at first reading, I'll dig in more deeply. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu olva...@gmail.com wrote: On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell kei...@vmware.com wrote: On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote: On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell kei...@vmware.com wrote: OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a mapped range, the current behavior in debug build doesn't allow to flush its subrange if it doesn't touch the last byte of the range. The attached patch fixes that and changes u_uploadmgr for the mapped and flushed ranges to match. Please review. Other than that, it's stable as master. Thank you very much. OK, if nobody chimes in, let's look at merging this to master in the next day or so. I've made a final merge of master into gallium-resources. Please try it out and report/fix any issues. This will be merged tomorrow. Texturing in i915g seems to be broken. You can find screenshots of drawpix and teapot in the attachments. Any idea? Looks like only the first row of texels is being uploaded. Maybe stride is being set to zero in the transfer creation, or similar? Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 12:36 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu olva...@gmail.com wrote: On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell kei...@vmware.com wrote: On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote: On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell kei...@vmware.com wrote: OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a mapped range, the current behavior in debug build doesn't allow to flush its subrange if it doesn't touch the last byte of the range. The attached patch fixes that and changes u_uploadmgr for the mapped and flushed ranges to match. Please review. Other than that, it's stable as master. Thank you very much. OK, if nobody chimes in, let's look at merging this to master in the next day or so. I've made a final merge of master into gallium-resources. Please try it out and report/fix any issues. This will be merged tomorrow. Texturing in i915g seems to be broken. You can find screenshots of drawpix and teapot in the attachments. Any idea? Looks like only the first row of texels is being uploaded. Maybe stride is being set to zero in the transfer creation, or similar? Hmm, yes - u_default_get_transfer doesn't fill stride in, which is fine for buffers but busted for textures. I'll modify the two places where this is being used for textures. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 12:39 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Sat, Apr 10, 2010 at 12:36 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Sat, Apr 10, 2010 at 6:59 AM, Chia-I Wu olva...@gmail.com wrote: On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell kei...@vmware.com wrote: On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote: On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell kei...@vmware.com wrote: OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a mapped range, the current behavior in debug build doesn't allow to flush its subrange if it doesn't touch the last byte of the range. The attached patch fixes that and changes u_uploadmgr for the mapped and flushed ranges to match. Please review. Other than that, it's stable as master. Thank you very much. OK, if nobody chimes in, let's look at merging this to master in the next day or so. I've made a final merge of master into gallium-resources. Please try it out and report/fix any issues. This will be merged tomorrow. Texturing in i915g seems to be broken. You can find screenshots of drawpix and teapot in the attachments. Any idea? Looks like only the first row of texels is being uploaded. Maybe stride is being set to zero in the transfer creation, or similar? Hmm, yes - u_default_get_transfer doesn't fill stride in, which is fine for buffers but busted for textures. I'll modify the two places where this is being used for textures. Keith OK, I've pushed something which should fix this. Anything more we can resolve on master. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger srol...@vmware.com wrote: On 10.04.2010 16:43, Chia-I Wu wrote: On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? The conversion to pipe_resource seems to be done by components. Maybe a new branch that reorganize (git rebase -i) the commits in gallium-resources and merge the new branch to master? I've never used git rebase -i but I'm not convinced that can give something sensible. It wasn't done strictly by components, with a couple merges from master (and gallium-buffer-usage-cleanup) in between and fixes for already converted things... Squash merge it is. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger srol...@vmware.com wrote: On 10.04.2010 16:43, Chia-I Wu wrote: On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? The conversion to pipe_resource seems to be done by components. Maybe a new branch that reorganize (git rebase -i) the commits in gallium-resources and merge the new branch to master? I've never used git rebase -i but I'm not convinced that can give something sensible. It wasn't done strictly by components, with a couple merges from master (and gallium-buffer-usage-cleanup) in between and fixes for already converted things... Squash merge it is. Somewhat arbitrary decision to avoid stretching this out any further. I don't think the history that was on the branch was very useful, nor does inventing history seem likely to help people searching for regressions, etc. The branch is effectively an atomic change, so let's deal with it like that... Keith -- 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] Provide dri shared library building and SDK installation.
I haven't been following this very closely, so apologies if I'm going over established ground. This patch appears to create new libraries from some subset of Mesa's internals. At a guess you're selecting some internal interface(s) within mesa to become the public API of those libraries? I'm pretty sure that's not something we're trying to achieve in this project. We have public APIs which we respect and implement, and which are maintained and evolved under the Khronos umbrella. We have a strong driver-level interface (ie gallium) which we benefit greatly from being rev as fast and as hard as we can, to adapt to our evolving understanding of the problem space. We really don't want to subject that interface to the strictures that come with becoming a public API or ABI. We have a third interface, the Mesa driver interface, which may appear relatively stable, but which is more accurately described as neglected, veering towards deprecated. The shortcomings of this interface, in particular its porous nature and inappropriate abstraction level, were major catalysts provoking the development of gallium. Those shortcomings would also make it less than appropriate as a public API. At some point in the future, that interface will either roar back into rapid evolution or truly be deprecated in favour of either gallium or a low-level, legacy-free GL3/4 subset from Khronos. I can't easily tell from your patch what interfaces these new libraries have, or what expectations there would be for maintaining compatibility on those interfaces going forward. I'd like to see that spelled out explicitly. Without investigating further, I can say I'm not aware of any interface within Mesa which we'd be happy to promote to a public interface, nor one which we'd be happy to accept extra restrictions on in terms of compatibility. Keith On Fri, Apr 9, 2010 at 11:59 PM, Luc Verhaegen l...@skynet.be wrote: Patch cherry-picked from my dri-sdk-7.8 branch against current head (edb5253dfa). An earlier full build through of all drivers (except nouveau, i will play with its expansive libdrm dependencies later) showed it to be an exact match still. This patch, while not harming or hampering anything or anyone, gives us the ability to maintain and build DRI drivers out of tree for those so inclined. Build system additions only. No adverse effects. Everybody wins. I intend to provide changes as needed, I hope to at least manage to maintain released versions in the long term. For those wanting a test run, please check out the 7.8 version of the SDK and the drivers in my cgit.freedesktop.org repos. Luc Verhaegen. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Sat, Apr 10, 2010 at 4:52 PM, Roland Scheidegger srol...@vmware.com wrote: On 10.04.2010 17:10, Keith Whitwell wrote: On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger srol...@vmware.com wrote: On 10.04.2010 16:43, Chia-I Wu wrote: On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: Hmm, not sure whether to merge or squash-merge this branch. Any thoughts? The conversion to pipe_resource seems to be done by components. Maybe a new branch that reorganize (git rebase -i) the commits in gallium-resources and merge the new branch to master? I've never used git rebase -i but I'm not convinced that can give something sensible. It wasn't done strictly by components, with a couple merges from master (and gallium-buffer-usage-cleanup) in between and fixes for already converted things... Squash merge it is. Somewhat arbitrary decision to avoid stretching this out any further. I don't think the history that was on the branch was very useful, nor does inventing history seem likely to help people searching for regressions, etc. The branch is effectively an atomic change, so let's deal with it like that... Yeah, you're right. Thinking about it, parts of it were always broken throughout the life of the branch or didn't even build, so squash merge makes sense. Glad it's merged - no more conflicts fixing for merges from master :-). Indeed. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell kei...@vmware.com wrote: OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a mapped range, the current behavior in debug build doesn't allow to flush its subrange if it doesn't touch the last byte of the range. The attached patch fixes that and changes u_uploadmgr for the mapped and flushed ranges to match. Please review. Other than that, it's stable as master. Thank you very much. OK, if nobody chimes in, let's look at merging this to master in the next day or so. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote: On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote: On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell kei...@vmware.com wrote: OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a mapped range, the current behavior in debug build doesn't allow to flush its subrange if it doesn't touch the last byte of the range. The attached patch fixes that and changes u_uploadmgr for the mapped and flushed ranges to match. Please review. Other than that, it's stable as master. Thank you very much. OK, if nobody chimes in, let's look at merging this to master in the next day or so. I've made a final merge of master into gallium-resources. Please try it out and report/fix any issues. This will be merged tomorrow. Keith -- 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 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. Keith -- 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 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... Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Wed, 2010-04-07 at 18:58 -0700, Marek Olšák wrote: On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources With this, r300g works again. Hmm, I think the second of the patches (flush range relative to mapped range vs whole buffer) may be addressing a regression that has creeped into the -resources branch regarding this behaviour - ie. I think the code you modified was actually correct, but that pipe_flush_mapped_buffer_range() has changed to do the wrong thing. I'll try and figure out what should be happening. I've pushed a change which hopefully corrects the behaviour of the buffer_range inlines. Can you give it a try? Now glean/bufferObject fails on softpipe and r300g. I haven't tested other drivers. OK, it seems like quite a few cases had migrated to the new buffer_map_range() behaviour. I've looked at all I can find and moved them back to the old behaviour. glean is passing now on softpipe. Keith -- 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: Add missing D3D9 color formats
On Thu, 2010-04-08 at 09:33 -0700, José Fonseca wrote: 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 This seems fine. Some of these may actually exist in hardware. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote: On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources With this, r300g works again. Hmm, I think the second of the patches (flush range relative to mapped range vs whole buffer) may be addressing a regression that has creeped into the -resources branch regarding this behaviour - ie. I think the code you modified was actually correct, but that pipe_flush_mapped_buffer_range() has changed to do the wrong thing. I'll try and figure out what should be happening. I've pushed a change which hopefully corrects the behaviour of the buffer_range inlines. Can you give it a try? Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-resources branch merge
On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote: There's something fishy in u_upload_mgr, could you please review the first two patches here? http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources With this, r300g works again. Hmm, I think the second of the patches (flush range relative to mapped range vs whole buffer) may be addressing a regression that has creeped into the -resources branch regarding this behaviour - ie. I think the code you modified was actually correct, but that pipe_flush_mapped_buffer_range() has changed to do the wrong thing. I'll try and figure out what should be happening. Keith -- 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] ARB draw buffers + texenv program
On Fri, 2010-04-02 at 20:43 -0700, Dave Airlie wrote: Just going down the r300g piglit failures and noticed fbo-drawbuffers failed, I've no idea if this passes on Intel hw, but it appears the texenvprogram really needs to understand the draw buffers. The attached patch fixes it here for me on r300g anyone want to test this on Intel with the piglit test before/after? Dave. This change makes sense looks good to me. Keith -- 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 raw interfaces
On Sun, 2010-03-28 at 23:56 -0700, Chia-I Wu wrote: On Mon, Mar 29, 2010 at 1:51 AM, Keith Whitwell keith.whitw...@googlemail.com wrote: I've just pushed a variation on a theme a couple of people have explored in the past, ie. an interface to gallium without an intervening state-tracker. The purpose of this is for writing minimal test programs to exercise new gallium drivers in isolation from the rest of the codebase. In fact it doesn't really make sense to say without a state tracker, unless you don't mind creating test programs which are specific to the windowing system you're currently working with. Some similar work has avoided window-system issues altogether by dumping bitmaps to files, or using eg. python to abstract over window systems. This approach is a little different - I've defined a super-minimal api for creating/destroying windows, currently calling this graw, and we have a tiny little co-state-tracker that each implementation provides. This is similar to the glut approach of abstracting over window systems, though much less complete. It currently consists of three calls: struct pipe_screen *graw_init( void ); void *graw_create_window(...); void graw_destroy_window( void *handle ); which are sufficient to build simple demos on top of. A future enhancement would be to add a glut-style input handling facility. Right now there's a single demo, clear.c which displays an ugly purple box. Builds so far only with scons, using winsys=graw-xlib. I happened to be playing with the idea yesterday. My take is to define an EGL extension, EGL_MESA_gallium. The extension defines Gallium as a rendering API of EGL. The downside of this approach is that it depends on st/egl. The upside is that, it will work on whatever platform st/egl supports. I've cleaned up my work a little bit. You can find it in the attachments. There is a port of clear raw demo to use EGL_MESA_gallium. The demo supports window resizing, and is accelerated if a hardware EGL driver is used. The demo renders into a X11 window. It is worth noting that, when there is no need to render into an EGLSurface, eglCreateWindowSurface or eglMakeCurrent is not required. To interface with X11, I've also borrowed some code from OpenVG demos and renamed it to EGLUT. I'm not sure how far to take any of these naked gallium approaches. My motivation was to build something to provide a very controlled environment for bringup of new drivers - basically getting to the first triangle and not much further. After that, existing state trackers with stable ABIs are probably preferable. Keith -- 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 raw interfaces
Hi, I've just pushed a variation on a theme a couple of people have explored in the past, ie. an interface to gallium without an intervening state-tracker. The purpose of this is for writing minimal test programs to exercise new gallium drivers in isolation from the rest of the codebase. In fact it doesn't really make sense to say without a state tracker, unless you don't mind creating test programs which are specific to the windowing system you're currently working with. Some similar work has avoided window-system issues altogether by dumping bitmaps to files, or using eg. python to abstract over window systems. This approach is a little different - I've defined a super-minimal api for creating/destroying windows, currently calling this graw, and we have a tiny little co-state-tracker that each implementation provides. This is similar to the glut approach of abstracting over window systems, though much less complete. It currently consists of three calls: struct pipe_screen *graw_init( void ); void *graw_create_window(...); void graw_destroy_window( void *handle ); which are sufficient to build simple demos on top of. A future enhancement would be to add a glut-style input handling facility. Right now there's a single demo, clear.c which displays an ugly purple box. Builds so far only with scons, using winsys=graw-xlib. Keith -- 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] Rationale of gallium-resources changes?
On Wed, Mar 24, 2010 at 9:20 PM, Luca Barbieri l...@luca-barbieri.com wrote: Thanks for providing a long insightful reply. Transfers can then be split in texture transfers and buffer transfers. Note that they are often inherently different, since one often uses memcpy-like GPU functionality, and the other often uses 2D blitter or 3D engine functionality (and needs to worry about swizzling or tiling) Thus, they are probably better split and not unified. My experience is that there is more in common than different about the paths. There are the same set of constraints about not wanting to stall the GPU by mapping the underlying storage directly if it is still in flight, and allocating a dma buffer for the upload if it is. There will always be some differences, but probably no more than the differences between uploading to eg a constant buffer and a vertex buffer, or uploading to a swizzled and linear texture. The considerations you mentioned are indeed common between buffers and textures, but the actual mechanisms for performing the copy are often significantly different. For instance, r300g ends up calling the 3D engine via surface_copy-util_blitter for texture transfers, which I suppose it wouldn't do for buffer transfers. nv30/nv40 don't have a single way to deal with swizzled textures, and the driver must choose between many paths depending on whether the source/destination is swizzled or not, a 3D texture or not, and even its alignment or pitch (the current driver doesn't do fully that, and is partially broken for this reason). Buffers can instead be copied very simply with MEMORY_TO_MEMORY_FORMAT. nv50 does indeed have a common copy functionality that can handle all buffers and textures in a unified way (implemented as a revamped MEMORY_TO_MEMORY_FORMAT). However, an additional buffer-only path would surely be faster than going through the common texture path. In particular, for buffers tile_flags are always 0 and height is always 1, allowing to write a significantly simplified buffer-only version of nv50_transfer_rect_m2mf with no branches and no multiplications at all. In other words, I think most drivers would be better off implementing unified transfers with an if switching between a buffer and a texture path, so it may be worth using two interfaces. Also note that a buffer-only interface is significantly simplified since you don't need to specify: - face - level - zslice - y - height - z - depth - stride - slice stride While this may seem a micro-optimization, note that 3D applications often spend all the time running the OpenGL driver and Mesa/Gallium functions are already too heavy in profiles, so I think it's important to always keep CPU performance in mind. The code is also streamlined and easier to follow if it does not have to default-initialize a lot of stuff. An utility function calling the right interface can be created for state trackers that really need it (maybe Direct3D10, if the driver interface follows the user API). I take your point, though I should point out you've double-counted z and zslice, and face+level are one dword. To me this speaks to another aspect of the gallium interface which is a bit odd -- in particular the way several of our interfaces basically copy their inputs into a structure and pass that back to the state tracker. Why are we doing that? The state tracker already knows what it asked us to do, and there is no reason to assume that it needs us to re-present that information back to it. The only really new information provided by the driver to the state tracker by transfer_create + transfer_map is: - the pointer to the data - stride - slice stride If the transfer functions ended up just passing this data back, it would reduce the overhead across the board. Your point is still valid that the last two will be zero for buffer transfers, though. In DX they have different nomenclature for this - the graphics API level entities are resources and the underlying VMM buffers are labelled as allocations. In gallium, we're exposing the resource concept, but allocations are driver-internal entities, usually called winsys_buffers, or some similar name. D3D10 uses buffers, sampler views and render target views as entities bindable to the pipeline, and the latter are constructed over either textures or buffers. Note however, that the description structure is actually different in the buffer and texture cases. For render target views, they are respectively D3D10_BUFFER_RTV and D3D10_TEX2D_RTV (and others for other texture types). The first specifies an offset and stride, while the second specifies a mipmap level. Other views have similar behavior. Buffers are directly used in the interfaces that allow binding vertex/index/constant buffers. Both buffers and textures are subclasses of ID3D10Resource, which is used by CopyResource, CopySubresourceRegion and UpdateSubresource,
Re: [Mesa3d-dev] Rationale of gallium-resources changes?
On Tue, Mar 23, 2010 at 7:26 PM, Luca Barbieri l...@luca-barbieri.com wrote: What is the rationale behind the gallium-resources changes? Luca, Thanks for the feedback. I posted something describing this a little while ago: http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg11375.html There are a bunch of things pushing us in this direction, but at its most basic it is a recognition that we have two gpu-side objects with very similar operations on them but exposed by the interface in quite different ways. Look for instance at the SVGA driver which has implemented two separate (and fairly complex) non-blocking upload paths for each of these entities. And crucially, we also have APIs starting to blur the line between textures and buffers. In DX10 and 11 in particular, you can perform operations on buffers (like binding as a render-target) which are easier to cope with if we have a unified abstraction. In the past we had some confusion in what a pipe_buffer really is -- is it: a) a GPU-side entity which can be bound to the pipeline? b) a mechanism for CPU/GPU communication - effectively a dma buffer? c) a way of talking about the underlying storage for GPU resources, effectively a linear allocation of VRAM memory? What we're doing in gallium-resources is a unification of textures and the view (a) of buffers as abstract GPU entities. That implies that the roles b) and c) are covered by other entites -- in particular transfers become the generic CPU/GPU communication path, and the underlying concept of winsys buffers (not strictly part of gallium) provides (c). Basically the change unifies all the GPU-side entities under a single parent (resource). The driver is free to implement textures and buffers as one code path or two. For expediency, I've tried to avoid changing the drivers signficantly at this point, which has meant keeping alive the separate texture and buffer implementations and selecting between them with a vtbl. That isn't a strict requirement of the design, just something I've done to avoid rewriting all of the drivers at once on my own... I couldn't find any and I see several points that could be improved: 1. How does one do texture_blanket with the gallium-resources API? That is, how does one bind a buffer as a texture with a specific format? 2. Why is there a transfer_inline_write and not a transfer_inline_read? 3. How about adding a transfer_update_region that would copy data from the resource to the transfer, just like transfer_inline_write copies from the transfer to the resource? 4. How about making transfers be always mapped when alive and removing transfer_map and transfer_unmap? I think you brought up some of these points up in the followup to my earlier post, eg: http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg11537.html I think your suggestions are good - I had an 'inline_read' initially, and although I took it out, I've been convinced by others that there are actually users for such an interface - so no objections to it coming back in. Similarly I agree there isn't much value in transfer_create/destroy being separate from map and unmap. I see these as additional enhancements beyond getting the basic resource concept up and running which can be done in follow-on work. In reference to texture_blanket - this was actually removed from gallium a little while ago - replaced by the texture_from_handle() and texture_get_handle() interfaces. In this case the 'handle' is a pointer to an operating-system specific entity -- presumably describing the underlying storage. In addition to these micro-level issues, is the bigger picture unification of buffers and textures as resources a good idea? I think so, not least because other APIs are moving in this direction and using them somewhat interchangeably. It will burden all buffer operations with redundant notions of 3D boxes, strides, formats and texture targets. I'm not sure where you see this, but if there are specific cases where there is a lot of new overhead, we can work to reduce that. How about instead layering textures over buffers, and exposing the underlying buffer of a texture, maybe also allowing to dynamically change it? I think this makes sense for the view of buffers as memory-manager allocations. That works for certain cases, eg native rendering on local machines, but not all uses of gallium can be described that way. We're really positioning the gallium api at a slightly higher abstraction level, to cover both the case where that could work in addition to ones which don't fit that mold. Then you could create a texture, asking the driver to create a buffer too, for the normal texture creation case. You could create a texture with a specified format and layout over an existing buffer to implement buffer-as-texture, or reinterpret the underyling buffer of an existing texture as another data format. You could also create a texture without an underlying
Re: [Mesa3d-dev] Mesa (master): gallium: add soft screen helper
George,
This is basically a reproduction of a facility I had in target-helpers
previously (swrast_screen.c or similar), which I removed after
feedback from Jose that supporting it with scons created more ugliness
than we saved in the C code.
This change breaks layering in the build system by making code in the
utility libraries conditionally built depending on which targets we're
supporting. Ideally the code in auxilliary wouldn't have any idea
whether softpipe, llvmpipe or any other driver is out there.
For the meantime, I'd say just duplicate the function in the few
places which use it. There aren't many currently. Longer term, I
think we probably want a little targets/common or similar, rather than
trying to bundle this into auxilliary.
Keith
On Sun, Mar 21, 2010 at 11:24 AM, George Sapountzis
gs...@kemper.freedesktop.org wrote:
Module: Mesa
Branch: master
Commit: f87a5f6499f51f651c2a9f2d4682875b22926905
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f87a5f6499f51f651c2a9f2d4682875b22926905
Author: George Sapountzis gsapount...@gmail.com
Date: Fri Mar 19 02:38:11 2010 +0200
gallium: add soft screen helper
---
src/gallium/auxiliary/target-helpers/soft_screen.c | 73
src/gallium/auxiliary/target-helpers/soft_screen.h | 12 +++
src/gallium/targets/libgl-xlib/Makefile | 1 +
src/gallium/targets/libgl-xlib/soft_screen.c | 1 +
src/gallium/targets/libgl-xlib/xlib.c | 34 +-
src/gallium/winsys/drm/sw/Makefile | 3 +-
src/gallium/winsys/drm/sw/soft_screen.c | 1 +
src/gallium/winsys/drm/sw/sw_drm_api.c | 32 -
8 files changed, 120 insertions(+), 37 deletions(-)
diff --git a/src/gallium/auxiliary/target-helpers/soft_screen.c
b/src/gallium/auxiliary/target-helpers/soft_screen.c
new file mode 100644
index 000..00d386e
--- /dev/null
+++ b/src/gallium/auxiliary/target-helpers/soft_screen.c
@@ -0,0 +1,73 @@
+/**
+ *
+ * Copyright 2010 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY
CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ *
+ **/
+
+#include target-helpers/soft_screen.h
+#include softpipe/sp_public.h
+#include llvmpipe/lp_public.h
+#include cell/ppu/cell_public.h
+#include util/u_debug.h
+
+/**
+ * Choose and create a software renderer screen.
+ */
+struct pipe_screen *
+gallium_soft_create_screen( struct sw_winsys *winsys )
+{
+ const char *default_driver = NULL;
+ const char *driver = NULL;
+ struct pipe_screen *screen = NULL;
+
+#if defined(GALLIUM_CELL)
+ default_driver = cell;
+#elif defined(GALLIUM_LLVMPIPE)
+ default_driver = llvmpipe;
+#elif defined(GALLIUM_SOFTPIPE)
+ default_driver = softpipe;
+#else
+ default_driver = ;
+#endif
+
+ driver = debug_get_option(GALLIUM_DRIVER, default_driver);
+
+#if defined(GALLIUM_CELL)
+ if (screen == NULL strcmp(driver, cell) == 0)
+ screen = cell_create_screen( winsys );
+#endif
+
+#if defined(GALLIUM_LLVMPIPE)
+ if (screen == NULL strcmp(driver, llvmpipe) == 0)
+ screen = llvmpipe_create_screen( winsys );
+#endif
+
+#if defined(GALLIUM_SOFTPIPE)
+ if (screen == NULL)
+ screen = softpipe_create_screen( winsys );
+#endif
+
+ return screen;
+}
diff --git a/src/gallium/auxiliary/target-helpers/soft_screen.h
b/src/gallium/auxiliary/target-helpers/soft_screen.h
new file mode 100644
index 000..5c10126
--- /dev/null
+++ b/src/gallium/auxiliary/target-helpers/soft_screen.h
@@ -0,0 +1,12 @@
+#ifndef SOFT_SCREEN_HELPER_H
+#define SOFT_SCREEN_HELPER_H
+
+#include pipe/p_compiler.h
+
+struct pipe_screen;
+struct sw_winsys;
+
+struct
Re: [Mesa3d-dev] Mesa (master): gallium: add soft screen helper
On Sun, Mar 21, 2010 at 5:57 PM, George Sapountzis gsapount...@gmail.com wrote: On Sun, Mar 21, 2010 at 7:43 PM, George Sapountzis gsapount...@gmail.com wrote: On Sun, Mar 21, 2010 at 7:22 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: George, This is basically a reproduction of a facility I had in target-helpers previously (swrast_screen.c or similar), which I removed after feedback from Jose that supporting it with scons created more ugliness than we saved in the C code. Ah ok, i was not aware of this This change breaks layering in the build system by making code in the utility libraries conditionally built depending on which targets we're supporting. Ideally the code in auxilliary wouldn't have any idea whether softpipe, llvmpipe or any other driver is out there. This commit did not build soft_screen.c with auxiliary but symlinked it at each target and build it there, I guess this is not pretty either. For the record, the scons build seemed to work (after getting broken) as reported by Xavier. OK, that would overcome the issue I was thinking of, but agree it's not pretty either... For the meantime, I'd say just duplicate the function in the few places which use it. There aren't many currently. Longer term, I think we probably want a little targets/common or similar, rather than trying to bundle this into auxilliary. Ah ok, so it will be build once and all places will use the same software renderer by default. That's the hope... Ok, I just reverted the commit and the commits that fix it. It seems that there will be three places using it (libgl-xlib, drm/sw and drm/swrast). I'll give it a try some other day when I can read and type. Thanks George. Keith -- 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 (mesa_7_7_branch): mesa: List Quake3 extensions first.
On Tue, 2010-03-16 at 08:32 -0700, Ian Romanick wrote: I'm also a bit surprised that not detecting GL_EXT_compiled_vertex_array has any impact on our Quake3 performance. After all, our CVA implementation doesn't do anything! Looking at the list, it seems more likely that GL_EXT_texture_env_add is the problem. Not having that will cause Quake3 to use additional rendering passes in quite a few cases. I think if CVA isn't present, it falls back to glVertex() and friends... Keith -- 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 Mon, 2010-03-15 at 07:08 -0700, michal wrote: michal wrote on 2010-03-12 15:00: michal wrote on 2010-03-11 17:59: Keith Whitwell wrote on 2010-03-11 16:16: On Thu, 2010-03-11 at 06:05 -0800, michal wrote: Keith Whitwell wrote on 2010-03-11 14:21: 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. The reason CSO code looks like this is because it was meant to be an itermediate step towards migration to sampler view model. Fully converting all existing state trackers is non-trivial and thus I chose this conservative approach. State trackers that do not care about extra features a sampler view provides will keep using this one-shot CSO interface with the hope that creation of sampler objects is lighweight (format matches texture format, swizzle matches native texel layout, etc.). On the surface, this hope isn't likely to be fulfilled - lots of hardware doesn't support non-zero first_level. Most cases of drivers implementing sampler views internally are to catch this issue. Of course, it seems like your branch so leaves the existing driver-specific sampler view code in place, so that there are potentially two implementations of sampler views in those drivers. I guess this means that you can get away with the current implementation for now, but it prevents drivers actually taking advantage of the fact that these entities exist in the interface -- they will continue to have to duplicate the concept internally until the state trackers and/or CSO module start caching views. Ideally, everybody moves on and we stop using CSO for sampler views. I prefer putting my effort into incremental migration of state trackers rather than caching something that by definition doesn't need to be cached. The CSO module exists to manage this type of caching on behalf of state trackers. I would have thought that this was a sensible extension of the existing purpose of the CSO module. Won't all state-trackers implementing APIs which don't expose sampler views to the application require essentially the same caching logic, as is the case with regular state? Wouldn't it be least effort to do that caching once only in the CSO module? OK, I see your point. I will make the necessary changes and ping you when that's done. Keith, I changed my mind, went ahead and implemented sampler view caching in mesa state tracker, rather than inside cso context. I strongly believe that doing caching on cso side would be slower and more complicated. A state tracker has a better understanding of the relationship between a texture and sampler view. In case of mesa, this is trivial 1-to-1 mapping. Later, when we'll need more sampler views per texture, we can have a per-texture cache for that, and yes, the code for that would be in cso. There are two other state trackers that need to be fixed: xorg and vega. The transition should be similar to mesa -- I can help with doing that, but I can't do it myself. Once that's done we can purge one-shot sampler view wrappers. What do you think? Keith, I just finished transforming mesa and auxiliary modules to new sampler view interfaces. The remaining bits are vega and xorg state trackers -- I will need help with them, but they could be fixed after the merge, as they are not broken, and just set sampler view in suboptimal fashion. Please review, thanks. Michal, Did you get a chance to look at the double-refcounting (views + textures) in the cso module? Keith
Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge
On Mon, 2010-03-15 at 07:24 -0700, michal wrote: Keith Whitwell wrote on 2010-03-15 15:19: On Mon, 2010-03-15 at 07:08 -0700, michal wrote: michal wrote on 2010-03-12 15:00: michal wrote on 2010-03-11 17:59: Keith Whitwell wrote on 2010-03-11 16:16: On Thu, 2010-03-11 at 06:05 -0800, michal wrote: Keith Whitwell wrote on 2010-03-11 14:21: 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. The reason CSO code looks like this is because it was meant to be an itermediate step towards migration to sampler view model. Fully converting all existing state trackers is non-trivial and thus I chose this conservative approach. State trackers that do not care about extra features a sampler view provides will keep using this one-shot CSO interface with the hope that creation of sampler objects is lighweight (format matches texture format, swizzle matches native texel layout, etc.). On the surface, this hope isn't likely to be fulfilled - lots of hardware doesn't support non-zero first_level. Most cases of drivers implementing sampler views internally are to catch this issue. Of course, it seems like your branch so leaves the existing driver-specific sampler view code in place, so that there are potentially two implementations of sampler views in those drivers. I guess this means that you can get away with the current implementation for now, but it prevents drivers actually taking advantage of the fact that these entities exist in the interface -- they will continue to have to duplicate the concept internally until the state trackers and/or CSO module start caching views. Ideally, everybody moves on and we stop using CSO for sampler views. I prefer putting my effort into incremental migration of state trackers rather than caching something that by definition doesn't need to be cached. The CSO module exists to manage this type of caching on behalf of state trackers. I would have thought that this was a sensible extension of the existing purpose of the CSO module. Won't all state-trackers implementing APIs which don't expose sampler views to the application require essentially the same caching logic, as is the case with regular state? Wouldn't it be least effort to do that caching once only in the CSO module? OK, I see your point. I will make the necessary changes and ping you when that's done. Keith, I changed my mind, went ahead and implemented sampler view caching in mesa state tracker, rather than inside cso context. I strongly believe that doing caching on cso side would be slower and more complicated. A state tracker has a better understanding of the relationship between a texture and sampler view. In case of mesa, this is trivial 1-to-1 mapping. Later, when we'll need more sampler views per texture, we can have a per-texture cache for that, and yes, the code for that would be in cso. There are two other state trackers that need to be fixed: xorg and vega. The transition should be similar to mesa -- I can help with doing that, but I can't do it myself. Once that's done we can purge one-shot sampler view wrappers. What do you think? Keith, I just finished transforming mesa and auxiliary modules to new sampler view interfaces. The remaining bits are vega and xorg state trackers -- I will need help
Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.
Chia-I,
This looks like it introduces an extra full-window copying operation
at every swapbuffers... is that correct?
If so, I think we should try to figure out an alternative approach
without the copying... would actually flipping between two textures
(thus preserving the old back/new front) contents be workable?
Keith
On Sun, Mar 14, 2010 at 5:17 AM, Chia-I Wu o...@kemper.freedesktop.org wrote:
Module: Mesa
Branch: gallium-st-api
Commit: d6262bdcfb64e1f88f6a890829f5c30c26bc372b
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d6262bdcfb64e1f88f6a890829f5c30c26bc372b
Author: Chia-I Wu o...@lunarg.com
Date: Sun Mar 14 12:01:27 2010 +0800
st/glx: Sync the back buffer to the front buffer.
Consider this rendering sequence
* render to the back buffer
* swap buffers
* read from the front buffer
The front buffer is expected to have the contents of the back buffer.
---
src/gallium/state_trackers/glx/xlib/xm_st.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/xm_st.c
b/src/gallium/state_trackers/glx/xlib/xm_st.c
index de5a35e..bcb8285 100644
--- a/src/gallium/state_trackers/glx/xlib/xm_st.c
+++ b/src/gallium/state_trackers/glx/xlib/xm_st.c
@@ -197,18 +197,36 @@ xmesa_st_framebuffer_validate(struct
st_framebuffer_iface *stfbi,
struct pipe_texture **out)
{
struct xmesa_st_framebuffer *xstfb = xmesa_st_framebuffer(stfbi);
- unsigned statt_mask, i;
+ unsigned statt_mask, new_mask, i;
+ boolean resized;
statt_mask = 0x0;
for (i = 0; i count; i++)
statt_mask |= 1 statts[i];
+ /* record newly allocated textures */
+ new_mask = statt_mask ~xstfb-texture_mask;
+
+ resized = (xstfb-buffer-width != xstfb-texture_width ||
+ xstfb-buffer-height != xstfb-texture_height);
/* revalidate textures */
- if (xstfb-buffer-width != xstfb-texture_width ||
- xstfb-buffer-height != xstfb-texture_height ||
- (xstfb-texture_mask statt_mask) != statt_mask) {
+ if (resized || new_mask) {
xmesa_st_framebuffer_validate_textures(stfbi,
xstfb-buffer-width, xstfb-buffer-height, statt_mask);
+
+ if (!resized) {
+ enum st_attachment_type back, front;
+
+ back = ST_ATTACHMENT_BACK_LEFT;
+ front = ST_ATTACHMENT_FRONT_LEFT;
+ /* copy the contents if front is newly allocated and back is not */
+ if ((statt_mask (1 back))
+ (new_mask (1 front))
+ !(new_mask (1 back))) {
+ xmesa_st_framebuffer_copy_textures(stfbi, back, front,
+ 0, 0, xstfb-texture_width, xstfb-texture_height);
+ }
+ }
}
for (i = 0; i count; i++) {
___
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 (gallium-st-api): st/glx: Sync the back buffer to the front buffer.
On Sun, Mar 14, 2010 at 10:28 AM, Chia-I Wu olva...@gmail.com wrote:
On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell
keith.whitw...@googlemail.com wrote:
This looks like it introduces an extra full-window copying operation
at every swapbuffers... is that correct?
If so, I think we should try to figure out an alternative approach
without the copying... would actually flipping between two textures
(thus preserving the old back/new front) contents be workable?
Buffers swapping is handled in xmesa_swap_st_framebuffer. It is a zero-copy
operation.
This commit is to fix a bug when this code path is hit
/* draw something and ... */
glXSwapBuffers();
glReadBuffer(GL_FRONT);
glReadPixels();
In the above, glReadBuffer will cause BUFFER_FRONT_LEFT renderbuffer to be
added on demand as can be seen in st_ReadBuffer. The validation list would
become { ST_ATTACHMENT_FRONT_LEFT, ST_ATTACHMENT_BACK_LEFT }. When
glReadPixels is called, st/mesa will validate with the list and read from the
front buffer.
On the st/glx side, this use pattern is catched. When the front buffer is
allocated, the contents of the back buffer will be copied to the front buffer.
This happens only once. When the same code is run again, glXSwapBuffers will
swap the buffers.
The copying is required because xmesa_swap_st_framebuffer does not always swap
the buffers. It is so that only the back buffer is allocated when the
application never draws/reads the front buffer.
--
o...@lunarg.com
OK, sorry for being slow thanks for explaining...
Keith
--
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] nv30/nv40 Gallium drivers unification
On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: Sounds good to me - fewer driver directories to fix up after changes... It'd be good to get this merged sooner rather than later as I'll soon be starting on pipe_resources conversion for the nv drivers. Once I do that, there will be heaps of conflicts with your patches, but if I can merge them in before I do the conversion all will be well... Keith -- 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): st/mesa: Always recalculate invalid index bounds.
On Sat, Mar 13, 2010 at 4:33 AM, Luca Barbieri luca.barbi...@gmail.com wrote: Actually, why is the state tracker doing the min/max computation at all? If the driver does the index lookup itself, as opposed to using an hardware index buffer, (e.g. the nouveau drivers do this in some cases) this is unnecessary and slow. Would completely removing the call to vbo_get_minmax_index break anything? Also, how about removing the max_index field in pipe_vertex_buffer? This seems to be set to the same value for all vertex buffers, and the value is then passed to draw_range_elements too. Isn't the value passed to draw_range_elements sufficient? It's really only needed for the special (but common) case where the vertex data isn't in a GL VBO at all, but just sitting in regular memory. The state tracker currently has the task of wrapping those regions of memory in user_buffers, and needs this computation to figure out what memory to wrap in that way. User buffers are a useful concept for avoiding a data copy, and can be implemented one of three ways in the driver: a) for drivers doing swtnl, just access the wrapped memory directly b) for drivers with hwtnl but unsophisticated memory managers, upload the userbuffer contents to a real buffer, then use that. c) for drivers with sophisticated memory managers, instruct the kernel to allow the hardware to access these pages directly and do whatever memory management tricks necessary to avoid the contents being clobbered by subsequent CPU accesses. It's a difficult trick to avoid extra data copies in a layered stack like gallium, and user_buffers are an attempt to avoid one source of them. But for any such technique, the mesa state tracker will need to figure out what memory is being referred to by those non-VBO vertex buffers and to do that requires knowing the index min/max values. Keith -- 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): st/mesa: Always recalculate invalid index bounds.
On Sat, Mar 13, 2010 at 11:40 AM, Luca Barbieri luca.barbi...@gmail.com wrote: But for any such technique, the mesa state tracker will need to figure out what memory is being referred to by those non-VBO vertex buffers and to do that requires knowing the index min/max values. Isn't the min/max value only required to compute a sensible value for the maximum user buffer length? (the base pointer is passed to gl*Pointer) Yes, I think that's what I was trying to say. The fact is, that we don't need to know how large the user buffer is if the CPU is accessing it (or if we have a very advanced driver that faults memory in the GPU VM on demand, and/or a mechanism to let the GPU share the process address space). Even for software tl, it's pretty important, see below. As you said, this happens for instance with swtnl, but also with drivers that scan the index buffer and copy the referenced vertex for each index onto the GPU FIFO themselves (e.g. nv50 and experimental versions of nv30/nv40). Having user-buffers with undefined size establishes a connection inside the driver between two things which could previously be fully understood separately - the vertex buffer is now no longer fully defined without reference to an index buffer. Effectively the user buffer become just unqualified pointers and we are back to the GL world pre-VBOs. In your examples, scanning and uploading (or transforming) per-index is only something which is sensible in special cases - eg where there are very few indices or sparse access to a large vertex buffer that hasn't already been uploaded/transformed. But you can't even know if the vertex buffer is sparse until you know how big it is, ie. what max_index is... Typical usage is the opposite - vertices are referenced more than once in a mesh and the efficient thing to do is: - for software tnl, transform all the vertices in the vertex buffer (requires knowing max_index) and then apply the indices to the transformed vertices - for hardware tnl, upload the vertex buffer in entirety (or better still, the referenced subrange). So couldn't we pass ~0 or similar as the user buffer length, and have the driver use an auxiliary module on draw calls to determine the real length, if necessary? Of course, drivers that upload user buffers on creation (if any exists) would need to be changed to only do that on draw calls. My feeling is that user buffers are a pretty significant concession to legacy GL vertex arrays in the interface. If there was any change to them, it would be more along the lines of getting rid of them entirely and forcing the state trackers to use proper buffers for everything. They are a nice way to accomodate old-style GL arrays, but they don't have many other uses and are already on shaky ground semantically. In summary, I'm not 100% comfortable with the current userbuffer concept, and I'd be *really* uncomfortable with the idea of buffers who's size we don't know or which could change size when a new index buffer is bound... Keith -- 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] nv30/nv40 Gallium drivers unification
Sounds good to me - fewer driver directories to fix up after changes... Keith On Sat, Mar 13, 2010 at 5:29 PM, Luca Barbieri l...@luca-barbieri.com wrote: Currently the nv30 and nv40 Gallium drivers are very similar, and contain about 5000 lines of essentially duplicate code. I prepared a patchset (which can be found at http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) which gradually unifies the drivers, one file per the commit. A new nvfx directory is created, and unified files are put there one by one. After all patches are applied, the nv30 and nv40 directories are removed and the only the new nvfx directory remains. The first patches unify the engine naming (s/curie/eng3d/g; s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. Initial versions of this work changed renouveau.xml to create a new NVFXTCL object, but the current version doesn't need any renouveau.xml modification at all. The unification+fixes branch referenced above is the one that should be tested. The unification branch contains just the unification, with no behavior changes, while unification+fixes also fixes swtnl and quad rendering, allowing to better test the unification. Some cleanups on top of the unfication are also included. That same repository also contains other branches with significant improvements on top of the unification, but I'm still not proposing them for inclusion as they need more testing and some fixes. While there are some branches in the Mesa repository that would conflict with this, such branches seem to be popping up continuously (and this is good!), so waiting until they are merged probably won't really work. The conflicts are minimal anyway and the driver fixes can be very easily reconstructed over the unified codebase. How about merging this? Any objections? Any comments? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] New error in xorg_crtc.c
Steve, Fixed, sorry for the screwup - it looks like a couple of directories escaped conversion. Keith On Fri, 2010-03-12 at 03:59 -0800, STEVE555 wrote: Hi guys, I've pulled in the latest commits for my local copy of Mesa git master.I ran gmake -B realclean,and used my usaul confiugre options: ./configure --prefix=/usr --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096 --with-max-height=4096 --enable-debug Mesa stops compiling with this new error: /usr/include/xorg/edid.h:623: warning: declaration does not declare anything gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -DHAVE_CONFIG_H -DHAVE_XEXTPROTO_71 -DHAVE_LIBKMS -I/usr/include/libkms -I/usr/include/pixman-1 -I/usr/include/xorg -I/usr/include/drm -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../include -I../../../../src/mesa -I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main -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 -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 xorg_crtc.c -o xorg_crtc.o In file included from /usr/include/xorg/xf86Crtc.h:25, from xorg_crtc.c:41: /usr/include/xorg/edid.h:623: warning: declaration does not declare anything xorg_crtc.c: In function ‘crtc_load_cursor_argb_ga3d’: xorg_crtc.c:223: error: ‘struct pipe_screen’ has no member named ‘get_tex_transfer’ xorg_crtc.c:227: error: ‘struct pipe_screen’ has no member named ‘transfer_map’ xorg_crtc.c:231: error: ‘struct pipe_screen’ has no member named ‘transfer_unmap’ xorg_crtc.c:232: error: ‘struct pipe_screen’ has no member named ‘tex_transfer_destroy’ gmake[4]: *** [xorg_crtc.o] Error 1 gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg' gmake[3]: *** [subdirs] Error 1 gmake[3]: Leaving directory `/opt/mesa/src/gallium/state_trackers' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/opt/mesa/src/gallium' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/opt/mesa/src' gmake: *** [default] Error 1 I think it's to do with the gallium-context-tranfers merge,or some very recent commit,I'm not that sure.The error is similar to the one that has been posted earlier in the mailing list. Regards, STEVE555 -- 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): st/mesa: Always recalculate invalid index bounds.
On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote:
Module: Mesa
Branch: master
Commit: 50876ddaaff72a324ac45e255985e0f84e108594
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
Author: Corbin Simpson mostawesomed...@gmail.com
Date: Fri Mar 12 02:51:40 2010 -0800
st/mesa: Always recalculate invalid index bounds.
These should always be sanitized before heading towards the pipe driver,
and if the calling function explicitly marked them as invalid, we need
to regenerate them.
Allows r300g to properly pass a bit more of Wine's d3d9 testing without
dropping stuff on the floor.
---
src/mesa/state_tracker/st_draw.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c
b/src/mesa/state_tracker/st_draw.c
index 8b01272..d81b361 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
assert(ctx-NewState == 0x0);
/* Gallium probably doesn't want this in some cases. */
- if (!index_bounds_valid)
- if (!vbo_all_varyings_in_vbos(arrays))
- vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ if (index_bounds_valid != GL_TRUE) {
+ vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ }
Corbin,
This isn't really desirable. Ideally this range checking should be
pushed into pipe driver, because it's an expensive operation that is not
necessary on a lot of hardware. #
Specifically, vertex fetch hardware can often be set up with the min/max
permissible index bounds to avoid accessing vertex data outside of the
bound VB's. This can be achieved by examining the VBs, with min_index
== 0, max_index = vb.size / vb.stride.
The case where we need to calculate them internally is if some data is
not in a VB, meaning we can't guess what the legal min/max values are.
Also note that we need that min/max information to be able to upload the
data to a VB.
So, I think the code was probably correct in the original version -
defer the minmax scan to the hardware driver, which may or may not need
it.
But maybe there is a better way to let the driver know that we are not
providing this information.
Keith
--
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-sampler-view): st/mesa: Associate a sampler view with an st texture object.
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?
Keith
On Fri, 2010-03-12 at 05:39 -0800, Micha?? Kr??l wrote:
Module: Mesa
Branch: gallium-sampler-view
Commit: b8030c6561e019e079b5be2fe64ec804df4bfa03
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b8030c6561e019e079b5be2fe64ec804df4bfa03
Author: Michal Krol mic...@vmware.com
Date: Fri Mar 12 14:37:36 2010 +0100
st/mesa: Associate a sampler view with an st texture object.
Lazily create a sampler view when the texture is being bound
for the first time.
---
src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +
src/mesa/state_tracker/st_atom_texture.c | 20 +-
src/mesa/state_tracker/st_cb_bitmap.c | 48 +++
src/mesa/state_tracker/st_cb_drawpixels.c | 46 ++
src/mesa/state_tracker/st_cb_texture.c |4 ++
src/mesa/state_tracker/st_context.c|4 +-
src/mesa/state_tracker/st_context.h|3 +-
src/mesa/state_tracker/st_texture.h| 39 +++
8 files changed, 119 insertions(+), 47 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c
b/src/mesa/state_tracker/st_atom_pixeltransfer.c
index 0b2e3f5..e766b3a 100644
--- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
+++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
@@ -257,6 +257,8 @@ get_pixel_transfer_program(GLcontext *ctx, const struct
state_key *key)
/* create the colormap/texture now if not already done */
if (!st-pixel_xfer.pixelmap_texture) {
st-pixel_xfer.pixelmap_texture = create_color_map_texture(ctx);
+ st-pixel_xfer.pixelmap_sampler_view =
st_sampler_view_from_texture(ctx-st-pipe,
+
st-pixel_xfer.pixelmap_texture);
}
/* with a little effort, we can do four pixel map look-ups with
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index 57b71c1..241c001 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -56,7 +56,7 @@ update_textures(struct st_context *st)
/* loop over sampler units (aka tex image units) */
for (su = 0; su st-ctx-Const.MaxTextureImageUnits; su++) {
- struct pipe_texture *pt = NULL;
+ struct pipe_sampler_view *sampler_view = NULL;
if (samplersUsed (1 su)) {
struct gl_texture_object *texObj;
@@ -84,7 +84,7 @@ update_textures(struct st_context *st)
st-state.num_textures = su + 1;
- pt = st_get_stobj_texture(stObj);
+ sampler_view = st_get_stobj_sampler_view(stObj);
}
/*
@@ -96,17 +96,17 @@ update_textures(struct st_context *st)
}
*/
- pipe_texture_reference(st-state.sampler_texture[su], pt);
+ pipe_sampler_view_reference(st-state.sampler_views[su],
sampler_view);
}
- cso_set_sampler_textures(st-cso_context,
-st-state.num_textures,
-st-state.sampler_texture);
+ cso_set_fragment_sampler_views(st-cso_context,
+ st-state.num_textures,
+ st-state.sampler_views);
if (st-ctx-Const.MaxVertexTextureImageUnits 0) {
- cso_set_vertex_sampler_textures(st-cso_context,
- MIN2(st-state.num_textures,
-
st-ctx-Const.MaxVertexTextureImageUnits),
- st-state.sampler_texture);
+ cso_set_vertex_sampler_views(st-cso_context,
+ MIN2(st-state.num_textures,
+
st-ctx-Const.MaxVertexTextureImageUnits),
+ st-state.sampler_views);
}
}
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index f326601..25d33b9 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -398,7 +398,7 @@ setup_bitmap_vertex_data(struct st_context *st,
static void
draw_bitmap_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
GLsizei width, GLsizei height,
- struct pipe_texture *pt,
+ struct pipe_sampler_view *sv,
const GLfloat *color)
{
struct st_context *st = ctx-st;
@@ -436,7 +436,7 @@ draw_bitmap_quad(GLcontext *ctx, GLint x, GLint y,
GLfloat z,
cso_save_rasterizer(cso);
cso_save_samplers(cso);
-
Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.
Resending to the right address.
Keith
On Fri, 2010-03-12 at 13:40 +, Keith Whitwell wrote:
On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote:
Module: Mesa
Branch: master
Commit: 50876ddaaff72a324ac45e255985e0f84e108594
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
Author: Corbin Simpson mostawesomed...@gmail.com
Date: Fri Mar 12 02:51:40 2010 -0800
st/mesa: Always recalculate invalid index bounds.
These should always be sanitized before heading towards the pipe driver,
and if the calling function explicitly marked them as invalid, we need
to regenerate them.
Allows r300g to properly pass a bit more of Wine's d3d9 testing without
dropping stuff on the floor.
---
src/mesa/state_tracker/st_draw.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c
b/src/mesa/state_tracker/st_draw.c
index 8b01272..d81b361 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
assert(ctx-NewState == 0x0);
/* Gallium probably doesn't want this in some cases. */
- if (!index_bounds_valid)
- if (!vbo_all_varyings_in_vbos(arrays))
-vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ if (index_bounds_valid != GL_TRUE) {
+ vbo_get_minmax_index(ctx, prims, ib, min_index, max_index);
+ }
Corbin,
This isn't really desirable. Ideally this range checking should be
pushed into pipe driver, because it's an expensive operation that is not
necessary on a lot of hardware. #
Specifically, vertex fetch hardware can often be set up with the min/max
permissible index bounds to avoid accessing vertex data outside of the
bound VB's. This can be achieved by examining the VBs, with min_index
== 0, max_index = vb.size / vb.stride.
The case where we need to calculate them internally is if some data is
not in a VB, meaning we can't guess what the legal min/max values are.
Also note that we need that min/max information to be able to upload the
data to a VB.
So, I think the code was probably correct in the original version -
defer the minmax scan to the hardware driver, which may or may not need
it.
But maybe there is a better way to let the driver know that we are not
providing this information.
Keith
--
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-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. OK, I'm fine with this if you're ok to go ahead and implement the caching. It's worth noting that drivers can discard any vram backing sampler views at any time (when they're not in use), so if we have a situation where large numbers of views are gobbling up vram, the driver has the option of running though all the views and discarding their cached contents. Keith -- 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-sampler-view): st/mesa: Associate a sampler view with an st texture object.
On Fri, 2010-03-12 at 06:19 -0800, Christoph Bumiller wrote: On 12.03.2010 15:08, 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. But there *is* a difference between GL_TEXTURE_MIN_LOD and GL_TEXTURE_BASE_LEVEL which those two seem to reflect. How do you implement that if you just remove one ? Note that we currently only have the one (sampler::min_lod), and the other is a synonym for the same value that has been introduced by this branch. Those GL values are currently both consolidated down by the mesa state-tracker (along with other stuff) into sampler::min_lod. Although Michal has chosen a different name for the new member, it has the same meaning and the GL semantics can be implemented on top of it as they currently are for sampler::min_lod. Keith -- 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-sampler-view): st/mesa: Associate a sampler view with an st texture object.
On Fri, 2010-03-12 at 06:54 -0800, Luca Barbieri wrote: What if you have a non-integer min LOD? While the integer part may belong to the sampler view, the fractional part really seems to be a sampler property. Requiring min_lod 1.0 also doesn't seem to make much sense, so shouldn't it be kept as it is now? Same thing for last_level / max_lod. Hmm, I see your point. Fractional values don't have a lot of meaning in the views, but without a fraction from somewhere we don't capture all of GL semantics. I guess this is the underlying reason GL has such a wide variety of ways of specifying the min/max level also. And finally, it seems like DX10 has done the same thing - with both integer min/max in views and float min/max in the sampler state. It looks like we really do want to keep them both. Keith -- 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-RFC] st_api, EGLImage, and flush_frontbuffer
On Wed, 2010-03-10 at 20:15 -0800, Chia-I Wu wrote:
Hi all,
This patch series adds st_api interface to st/mesa and st/vega, and
switch st/egl and st/glx from st_public interface to the new interface.
Feature-wise, st_api provides a more robust multiple client APIs
(OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
various EGLImage extensions. As st_api interface can coexist with
st_public interface, co state trackers should work as before unless they
are switched to use st_api.
The original plan to merge the work to master after the interface is
implemented by st/mesa and st/vega, and st/egl is converted to use it.
Further development and conversions of st/glx and st/dri will happen in
master. While this is still the plan, the recent merge of
gallium-sw-api-2 motivates me to submit this WIP patch series for public
review. I will cover only pipe_screen::update_buffer,
pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
here as the other parts were discussed a while ago. But any feedback to
the design is appreciated.
To summarize, there is *no* change to pipe_screen::update_buffer and
pipe_screen::flush_frontbuffer. This guarantees the non-Khronos state
trackers are not affected, and the st_public path of st/mesa and st/vega
still work. But when the st_api path is taken,
pipe_screen::update_buffer is no longer got called. And the caller of
pipe_screen::flush_frontbuffer becomes co state trackers instead of
state trackers.
In st_api, the co state trackers are responsible for representing
windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
depth/stencil, ...) to the state trackers. In DRI2, this is done
through DRI2GetBuffers and winsys_handle. In software rasterizer (or
DRI1?), this is done by having co state trackers allocate a set of
private pipe_textures. In both cases, the pipe_textures are created as
needed. That is, if the state trackers draw only to the back buffer,
the front buffer will not be creatd.
At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
st_framebuffer_iface. The state trackers retrieve the pipe_textures of
a window/pixmap/pbuffer mentioned above through this interface. Other
than retrieving the pipe_textures, to support front buffer rendering,
the state trackers should call st_framebuffer_iface::flush_front when it
has something to display.
The implementation of st_framebuffer_iface::flush_front again depends on
the window systems. In X11 with DRI2, it is no-op if the front buffer
passed to the state trackers is real; Otherwise, it calls
DRI2CopyRegion to copy the contents from the fake front buffer to the
real front one.
In X11 with software rasterizer, the co state tracker is responsible to
display its private pipe_texture to a X drawable. With the merge of
gallium-sw-api-2, this is made really easy by calling
pipe_screen::flush_frontbuffer.
The last patch of the series converts st/glx to use st_api. The diff is
cleaner than the diff to st/egl. It is a quick conversion to help see
the design of st_api in work. There should be bugs, but the simple
demos I tested all work. The other patches are constrained to EGL and
any regression outside EGL is considered a bug.
If you read this long because of the mention of EGLImage in the subject,
you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
thank-you gift :)
Chia-I,
This is all looking good to me. The code doesn't seem to introduce any
new layering issues or introduce dependencies on existing ones, which
helps with ongoing cleanups.
I did some quick testing with the linux-debug target. Gears works,
with and without GALLIUM_WRAP=t. However, demos/singlebuffer seems to
get caught in infinite recursion and segfaults:
Program received signal SIGSEGV, Segmentation fault.
0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
185 {
(gdb) bt
#0 0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
#1 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#2 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#3 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#4 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#5 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#6 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#7 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#8
Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer
On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
On Wed, 2010-03-10 at 20:15 -0800, Chia-I Wu wrote:
Hi all,
This patch series adds st_api interface to st/mesa and st/vega, and
switch st/egl and st/glx from st_public interface to the new interface.
Feature-wise, st_api provides a more robust multiple client APIs
(OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
various EGLImage extensions. As st_api interface can coexist with
st_public interface, co state trackers should work as before unless they
are switched to use st_api.
The original plan to merge the work to master after the interface is
implemented by st/mesa and st/vega, and st/egl is converted to use it.
Further development and conversions of st/glx and st/dri will happen in
master. While this is still the plan, the recent merge of
gallium-sw-api-2 motivates me to submit this WIP patch series for public
review. I will cover only pipe_screen::update_buffer,
pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
here as the other parts were discussed a while ago. But any feedback to
the design is appreciated.
To summarize, there is *no* change to pipe_screen::update_buffer and
pipe_screen::flush_frontbuffer. This guarantees the non-Khronos state
trackers are not affected, and the st_public path of st/mesa and st/vega
still work. But when the st_api path is taken,
pipe_screen::update_buffer is no longer got called. And the caller of
pipe_screen::flush_frontbuffer becomes co state trackers instead of
state trackers.
In st_api, the co state trackers are responsible for representing
windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
depth/stencil, ...) to the state trackers. In DRI2, this is done
through DRI2GetBuffers and winsys_handle. In software rasterizer (or
DRI1?), this is done by having co state trackers allocate a set of
private pipe_textures. In both cases, the pipe_textures are created as
needed. That is, if the state trackers draw only to the back buffer,
the front buffer will not be creatd.
At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
st_framebuffer_iface. The state trackers retrieve the pipe_textures of
a window/pixmap/pbuffer mentioned above through this interface. Other
than retrieving the pipe_textures, to support front buffer rendering,
the state trackers should call st_framebuffer_iface::flush_front when it
has something to display.
The implementation of st_framebuffer_iface::flush_front again depends on
the window systems. In X11 with DRI2, it is no-op if the front buffer
passed to the state trackers is real; Otherwise, it calls
DRI2CopyRegion to copy the contents from the fake front buffer to the
real front one.
In X11 with software rasterizer, the co state tracker is responsible to
display its private pipe_texture to a X drawable. With the merge of
gallium-sw-api-2, this is made really easy by calling
pipe_screen::flush_frontbuffer.
The last patch of the series converts st/glx to use st_api. The diff is
cleaner than the diff to st/egl. It is a quick conversion to help see
the design of st_api in work. There should be bugs, but the simple
demos I tested all work. The other patches are constrained to EGL and
any regression outside EGL is considered a bug.
If you read this long because of the mention of EGLImage in the subject,
you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
thank-you gift :)
Chia-I,
This is all looking good to me. The code doesn't seem to introduce any
new layering issues or introduce dependencies on existing ones, which
helps with ongoing cleanups.
I did some quick testing with the linux-debug target. Gears works,
with and without GALLIUM_WRAP=t. However, demos/singlebuffer seems to
get caught in infinite recursion and segfaults:
Program received signal SIGSEGV, Segmentation fault.
0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
185 {
(gdb) bt
#0 0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
#1 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#2 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#3 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#4 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#5 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#6 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt
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). 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. 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. Keith -- 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. 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. Looking at it a little, I suspect that doing it in the CSO module will be the least painful, though you'll need to be careful that caching sampler views doesn't cause texture references to never go to zero. Either way, it looks like there is a bit of work still to do on this branch. Keith -- 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] sw-api-2 branch
Steve, Does the attached patch help for you? Keith On Wed, 2010-03-10 at 05:34 -0800, STEVE555 wrote: Hi Keith, I use these configure options: ./configure --prefix=/usr --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga --with-max-width=4096 --with-max-height=4096 --ernable-debug I sometimes use --with-max-width= and --with-max-height= but the rest of them generally stay the same. Regards, STEVE555 Keith Whitwell-3 wrote: Steve, What configure options are those? Keith On Wed, 2010-03-10 at 04:41 -0800, STEVE555 wrote: Dear Keith, I checked out your branch using git checkout -b.and used git pull to get the differences between your branch and master.I did a gmake -B realclean and used my ./configure options I use for master. Unfortunately,it has stopped compiling with this error: /usr/bin/install -c vmwgfx_dri.so ../../../../../../lib/gallium gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/dri' 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 -DHAVE_XEXTPROTO_71 -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 -DHAVE_XEXTPROTO_71 -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 Regards, STEVE555 Keith Whitwell-3 wrote: This has reached a point where I could think about merging it. There is plenty more cleanup to do, but the branch makes some big strides and introduces a couple of concepts that I've wanted for a long time. In particular the idea of a designated targets subtree which has code for explicitly constructing driver stacks. Secondly the ability to inject layers into (at least) the software stacks has been greatly improved, and I'd like to see us build on that for hardware drivers as well. There is probably still some bugfix to come, but if you're interested in the software rasterizers, please check out this branch and let me know how much I've broken things... Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev diff --git a/configure.ac b/configure.ac index 70e158f..049c9e5 100644 --- a/configure.ac +++ b/configure.ac @@ -458,6 +458,7 @@ CORE_DIRS=glsl mesa SRC_DIRS=glew GLU_DIRS=sgi GALLIUM_DIRS=auxiliary drivers state_trackers +GALLIUM_TARGET_DIRS= GALLIUM_WINSYS_DIRS= GALLIUM_WINSYS_DRM_DIRS= GALLIUM_DRIVERS_DIRS=softpipe failover trace identity @@ -467,11 +468,12 @@ case $mesa_driver in xlib) DRIVER_DIRS
Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge
On Thu, 2010-03-11 at 06:05 -0800, michal wrote: Keith Whitwell wrote on 2010-03-11 14:21: 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. The reason CSO code looks like this is because it was meant to be an itermediate step towards migration to sampler view model. Fully converting all existing state trackers is non-trivial and thus I chose this conservative approach. State trackers that do not care about extra features a sampler view provides will keep using this one-shot CSO interface with the hope that creation of sampler objects is lighweight (format matches texture format, swizzle matches native texel layout, etc.). On the surface, this hope isn't likely to be fulfilled - lots of hardware doesn't support non-zero first_level. Most cases of drivers implementing sampler views internally are to catch this issue. Of course, it seems like your branch so leaves the existing driver-specific sampler view code in place, so that there are potentially two implementations of sampler views in those drivers. I guess this means that you can get away with the current implementation for now, but it prevents drivers actually taking advantage of the fact that these entities exist in the interface -- they will continue to have to duplicate the concept internally until the state trackers and/or CSO module start caching views. Ideally, everybody moves on and we stop using CSO for sampler views. I prefer putting my effort into incremental migration of state trackers rather than caching something that by definition doesn't need to be cached. The CSO module exists to manage this type of caching on behalf of state trackers. I would have thought that this was a sensible extension of the existing purpose of the CSO module. Won't all state-trackers implementing APIs which don't expose sampler views to the application require essentially the same caching logic, as is the case with regular state? Wouldn't it be least effort to do that caching once only in the CSO module? Keith -- 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-RFC] st_api, EGLImage, and flush_frontbuffer
On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
On Thu, Mar 11, 2010 at 7:54 PM, Keith Whitwell kei...@vmware.com wrote:
On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
This is all looking good to me. The code doesn't seem to introduce any
new layering issues or introduce dependencies on existing ones, which
helps with ongoing cleanups.
I did some quick testing with the linux-debug target. Gears works,
with and without GALLIUM_WRAP=t. However, demos/singlebuffer seems to
get caught in infinite recursion and segfaults:
Program received signal SIGSEGV, Segmentation fault.
0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
185 {
(gdb) bt
#0 0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
#1 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#2 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#3 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#4 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#5 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#6 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#7 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#8 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
Also, libgl-xlib / llvmpipe is getting some rendering errors with these
patches - seems like culling is messed up maybe. This is with a scons
build after adding the missing xm_st.c file.
Does it make sense to push these patches to a public Mesa branch so some
bugfixing can get done?
Thanks for testing the patches. I will have a look at the segfault tomorrow.
I haven't tried llvmpipe. Does softpipe also get the rendering error?
No, purely llvmpipe.
I will create a topic branch, gallium-st-api, tomorrow and continue the
development/bugfixing there, unless there are major design defects that should
be resolved first.
I don't see any major defects - it all looks pretty sensible to me.
Keith
--
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] context transfers again
I've pushed a cleaned-up version of this branch to gallium-context-transfers-2. Despite its long history, this branch is a fairly straightforward change, moving transfers to pipe_context. We've had to do quite a bit of work elsewhere to make this change feasible, but having done that it's not too invasive. I hope people can take a look at it I'll aim to merge in the next few days. Keith -- 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 08:59 -0800, Jerome Glisse wrote: On Thu, Mar 11, 2010 at 03:16:32PM +, Keith Whitwell wrote: On Thu, 2010-03-11 at 06:05 -0800, michal wrote: Keith Whitwell wrote on 2010-03-11 14:21: 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. The reason CSO code looks like this is because it was meant to be an itermediate step towards migration to sampler view model. Fully converting all existing state trackers is non-trivial and thus I chose this conservative approach. State trackers that do not care about extra features a sampler view provides will keep using this one-shot CSO interface with the hope that creation of sampler objects is lighweight (format matches texture format, swizzle matches native texel layout, etc.). On the surface, this hope isn't likely to be fulfilled - lots of hardware doesn't support non-zero first_level. Most cases of drivers implementing sampler views internally are to catch this issue. Of course, it seems like your branch so leaves the existing driver-specific sampler view code in place, so that there are potentially two implementations of sampler views in those drivers. I guess this means that you can get away with the current implementation for now, but it prevents drivers actually taking advantage of the fact that these entities exist in the interface -- they will continue to have to duplicate the concept internally until the state trackers and/or CSO module start caching views. Ideally, everybody moves on and we stop using CSO for sampler views. I prefer putting my effort into incremental migration of state trackers rather than caching something that by definition doesn't need to be cached. The CSO module exists to manage this type of caching on behalf of state trackers. I would have thought that this was a sensible extension of the existing purpose of the CSO module. Won't all state-trackers implementing APIs which don't expose sampler views to the application require essentially the same caching logic, as is the case with regular state? Wouldn't it be least effort to do that caching once only in the CSO module? Keith I didn't read anything about sampler view stuff, thus i can be completely wrong here, but from driver pov i prefer having most of the state going through create,bind,destroy pattern ie having the CSO doing the caching. Jerome, The driver view in both cases is as you describe - it's just a question of whether the state tracker does the create/bind/destroy itself, or if we can build a helper module to do that logic for it. Keith -- 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] sw-api-2 branch
I actually merged the sw-api-2 branch to master then deleted the branch. Sorry if I surprised you - just trying to avoid having hundreds of old, dead branches cluttering up the repository. Usually after a few weeks go by it's hard to remember which branches are still active and which can be deleted. I'll push the fix tomorrow from work. Keith On Thu, Mar 11, 2010 at 9:58 PM, STEVE555 stevenward...@hotmail.com wrote: Hi guys, I applied the patch using git apply on the Mesa master branch (I was getting the same on there also),for some reason,Kompare wasn't doing it's job properly. The reason I did it on there was because I looked at the branches on cgit,and Keith's gallium-sw-api-2 branch has disappeared! I'm extremeley sorry if I deleted it,or merged it into master by accident like I did earlier.I genuinely thought I was doing that sort of thing on my local copy of his branch. The good news is that when I re-compiled my local copy of Mesa master with the patch applied,it all compiled fine,with no ill effects when I re-booted. Regards, STEVE555 Dan Nicholson-2 wrote: On Thu, Mar 11, 2010 at 12:23 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Thu, Mar 11, 2010 at 12:19 PM, STEVE555 stevenward...@hotmail.com wrote: Hi Keith, Here's what I did.I opened Konsole on my mesa folder.I did a git pull origin to get the latest commits from master,then I did a git checkout -b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I deleted it earlier) .I then switched to the gallium-sw-api-2 using git branch and then did a git merge master.I saved your patch in a txt file,and then renamed it as gallium-sw-api-2.patch,I then used Kompare to apply and save all the differences. I then did a gmake -B realclean and then I used the same configure options as before. Unfortunately,your patch didn't work,I still get the same error as before. You would actually need to run autoconf first to generate a new configure script with Keith's changes. Or just run ./autogen.sh with the arguments you normally pass to configure. -- Dan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- View this message in context: http://old.nabble.com/sw-api-2-branch-tp27841684p27870463.html Sent from the mesa3d-dev mailing list archive at Nabble.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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] sw-api-2 branch
On Tue, 2010-03-09 at 16:49 -0800, STEVE555 wrote: Dear Keith, I've downloaded your sw-api-2 branch using the .tar.gz method again(git just won't let me).I used the same ./configure options but with the exception of doing --prefix=/usr/local instaed od /usr just in case. It was compiling fine until it hit this error: Ugh, should be fixed by the merge from master. Keith -- 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] sw-api-2 branch
Steve, What configure options are those? Keith On Wed, 2010-03-10 at 04:41 -0800, STEVE555 wrote: Dear Keith, I checked out your branch using git checkout -b.and used git pull to get the differences between your branch and master.I did a gmake -B realclean and used my ./configure options I use for master. Unfortunately,it has stopped compiling with this error: /usr/bin/install -c vmwgfx_dri.so ../../../../../../lib/gallium gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/dri' 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 -DHAVE_XEXTPROTO_71 -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 -DHAVE_XEXTPROTO_71 -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 Regards, STEVE555 Keith Whitwell-3 wrote: This has reached a point where I could think about merging it. There is plenty more cleanup to do, but the branch makes some big strides and introduces a couple of concepts that I've wanted for a long time. In particular the idea of a designated targets subtree which has code for explicitly constructing driver stacks. Secondly the ability to inject layers into (at least) the software stacks has been greatly improved, and I'd like to see us build on that for hardware drivers as well. There is probably still some bugfix to come, but if you're interested in the software rasterizers, please check out this branch and let me know how much I've broken things... Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]
On Wed, 2010-03-10 at 06:47 -0800, Corbin Simpson wrote: I don't know the VBO code that well, so I'm asking you guys if this has ever come up before. http://bugs.winehq.org/show_bug.cgi?id=22000 Gallium and indexed rendering are not very happy with each other. I get some fairly solidly reliable segfaults with both a d3d9 DLL test (device.ok) and Civ4 (Steam version). Hardware is a Radeon R580 (X1900), driver is r300g from Mesa git. My current guess, based on the Mesa debug info I dumped, is that the indexed rendering code is slightly baked and maybe trusting the underlying GL driver a bit too much. get_arrays_bounds: Handling 2 attrs attr 0: stride 16 size 12 start (nil) end 0xfffc attr 1: stride 16 size 4 start 0xc end (nil) buffer range: (nil) 0xfffc range -4 max index 4294967295 So right here (from device.ok) we have interleaved userspace VBO, that is being prepped inside core Mesa. Two delightful things here; the first attr seems way off-base, it shouldn't dare be giving us bad pointers, and the second attr's pointers don't even line up! In VBO rendering, the pointers are really just offsets into the VBO, so should be interpreted as numbers. The first attribute has what looks like a small negative number. I don't know if that's legal or not in GL - I suspect it is probably not legal and should be rejected in the mesa validation code. I suspect what is happening is wine is passing in some negative values and we aren't properly rejecting them in mesa. Compare to a sane program (Mesa's drawarrays): get_arrays_bounds: Handling 2 attrs attr 0: stride 16 size 12 start 0x8087020 end 0x808705c attr 1: stride 16 size 4 start 0x808702c end 0x8087060 buffer range: 0x8087020 0x8087060 range 64 max index 3 This doesn't look like VBO rendering though. These are regular vertex arrays, meaning these values are proper pointers. r300g doesn't really care. It shouldn't have to - the expectation in gallium is that inputs have been validated. The kernel drops the rendering on the floor for a variety of reasons, not least being the ridiculous max_index. But then it segfaults, and I have zero idea why. I'd guess it's something to do with tossing around NULL pointers like candy, but I'm honestly not sure and I haven't really dug into the DLL code yet. It's great you found a bug, but why all the excitement? Just track it down and propose a fix. Mesa's pretty well debugged, but there are always going to be new issues. I'm not sure why it warrants this type of implicit criticism when you come across something new. Keith -- 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 vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]
On Wed, 2010-03-10 at 07:18 -0800, Corbin Simpson wrote: On Wed, Mar 10, 2010 at 6:59 AM, Keith Whitwell kei...@vmware.com wrote: It's great you found a bug, but why all the excitement? Just track it down and propose a fix. Mesa's pretty well debugged, but there are always going to be new issues. I'm not sure why it warrants this type of implicit criticism when you come across something new. I wasn't aware of any implicit criticism in my post. If I said something wrong, I'm sorry; I'm a little bit fried from studying for a final, and what started as a relaxing diversion from math review has kind of turned into a multi-package bug and increased my frustration more than just a bit. I'll check the specs later and see if there's validation code missing, and also see if Wine needs similar patches. Again, sorry and thanks. No problem Corbin. I suspect this is because DX9 allows negative offset values in some surprising places. Basically I think you've hit two bugs - one wine is trying to send Mesa an illegal negative value instead of translating it away somehow, and secondly we are accepting it... Ketih -- 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-sw-api-2, cell driver alert!
On Tue, 2010-03-09 at 06:36 -0800, Brian Paul wrote: Keith Whitwell wrote: This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. My PS3 is still going- I'll look into it. Thanks Brian. Hopefully it's clear what's going on - it's just a port of the equivalent code from llvmpipe, plus a change to do the display-target untwiddling inside the driver rather than in the winsys. Keith -- 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-sw-api-2, cell driver alert!
This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Keith -- 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-sw-api-2, cell driver alert!
On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote: This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Dave had some code that fixes this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. It's just a cleanup at this point, no urgency. Keith -- 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] Commit messages broken??
I haven't seen any of these for a while now... Anyone have any ideas? Keith -- 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] sw-api-2 branch
This has reached a point where I could think about merging it. There is plenty more cleanup to do, but the branch makes some big strides and introduces a couple of concepts that I've wanted for a long time. In particular the idea of a designated targets subtree which has code for explicitly constructing driver stacks. Secondly the ability to inject layers into (at least) the software stacks has been greatly improved, and I'd like to see us build on that for hardware drivers as well. There is probably still some bugfix to come, but if you're interested in the software rasterizers, please check out this branch and let me know how much I've broken things... Keith -- 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-sw-api-2, cell driver alert!
On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote: On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote: This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Dave had some code that fixes this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. It's just a cleanup at this point, no urgency. I'll try and merge the easy bits of my branch to get drop u_simple_screen first. then worry about the cached mgr stuff. Sure, whenever it's convenient. Keith -- 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] to SpanRenderStart to avoid texture mapping overheads
On Sat, 2010-03-06 at 00:30 -0800, Dave Airlie wrote: So in classic drivers we can hit swrast fallbacks for things like ReadPixels where we know we aren't going to have to want to touch textures at all. This would be useful for the r300 driver where Maciej is working on texture tiling will allow us to avoid the untiling overheads that mapping textures requires for most sw fallbacks. There may be other operations where we can do this also. For render to texture scenarios the driver should still map the textures via the FBOs anyways. Dave. Looks like a reasonable idea to me. Keith -- 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 no texture blanket
I intend to merge this branch in the next few days. This will temporarily break the XShm code in egl/x11, which is coded around an interesting combination of user_buffer_create + texture_blanket, but there is other work in progress to address that, and the non-XShm version continues to work in the meantime. Additionally, the surface_buffer_create() hook should no longer be needed and will be removed soonish. Some drivers still use this internally, but it doesn't need to be part of the public interface. Keith -- 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-winsys-handle-rebased branch
This branch is hopefully ready for broader testing ahead of a merge. Can people, especially nv people, pull this down and try it out. Jakob has made a best effort to get this right, but neither of us have hardware. The branch itself is the start of a significant cleanup of some of the uglier bits of gallium, particularly the integration with cross-process shared surfaces, swapbuffers, etc. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Does DX9 SM3 - VMware svga with arbitrary semantics work? How?
On Tue, 2010-03-02 at 12:43 -0800, Luca Barbieri wrote: The difference between an easier and harder life for (some) drivers is whether the limit is tied to hardware interpolators or not. Once we decide to not tie it, whether the limit is 128 or 256 is of course quite inconsequential. Allowing arbitrary 32-bit values would however require use of binary search or an hash table. I think you or someone else from the Mesa team should decide how to proceed, and most drivers would need to be fixed. As I understand, the constraints are the following: Hardware with no capabilities. - nv30 does not support any mapping. However, we already need to patch fragment programs to insert constants, so we can patch input register numbers as well. The current driver only supports 0-7 generic indices, but I already implemented support for 0-255 indices with in-driver linkage and patching. Note that nv30 lacks control flow in fragment programs. - nv40 is like nv30, but supports fp control flow, and may have some configurable mapping support, with unknown behavior Hardware with capabilities that must be configured for each fp/vp pair. - nv40 might have this but the nVidia OpenGL driver does not use them - nv50 has configurable vp-gp and gp-fp mappings with 64 entries. The current driver seems to support arbitrary 0-2^32 indices. - r300 appears to have a configurable vp-fp mapping. The current driver only supports 0-15 generic indices, but redefining ATTR_GENERIC_COUNT could be enough to have it support larger numbers. Hardware with automatic linkage when semantics match: - VMWare svga appears to support 14 * 16 semantics, but the current driver only supports 0-15 generic indices. This could be fixed by mapping GENERIC into all non-special SM3 semantics. Hardware that can do both configurable mappings and automatic linkage: - r600 supports linkage in hardware between matching apparently byte-sized semantic ids Other hardware; - i915 has no hardware vertex shading - Not sure about i965 Software: 1. SM3 wants to use 14 * 16 indices overall. This is apparently only supported by the VMware closed source state tracker. 2. SM2 and non-GLSL OpenGL just want to use as many indices as the hardware interpolator count 3. Current GLSL currently wants to use at most about 10 indices more than the hardware interpolator count. This can be fixed since we see both the fragment and vertex shaders during linkage (the patch I sent did that) 4. GLSL with EXT_separate_shader_objects does not add requirements because only gl_TexCoord and other builtin varyings are supported. User-defined varyings are not supported 5. An hypotetical version of EXT_separate_shader_objects extended to support user-defining varyings would either want arbitrary 32-bit generic indices (by interning strings to generate the indices) or the ability to specify a custom mapping between shader indices 6. An hypotetical no-op implementation of the GLSL linker would have the same requirement Also note that non-GENERIC indices have peculiar properties. For COLOR and BCOLOR: 1. SM3 and OpenGL with glColorClamp appropriately set wants it to _not_ be clamped to [0, 1] 2. SM2 and normal OpenGL apparently want it to be clamped to [0, 1] (sometimes for fixed point targets only) and may also allow using U8_UNORM precision for it instead of FP32 3. OpenGL allows to enable two-sided lighting, in which case COLOR in the fragment shader is automagically set to BCOLOR for back faces 4. Older hardware (e.g. nv30) tends to support BCOLOR but not FACING. Some hardware (e.g. nv40) supports both FACING and BCOLOR in hardware. The latest hardware probably supports FACING only. Any API that requires special semantics for COLOR and BCOLOR (i.e. non-SM3) seems to only want 0-1 indices. Note that SM3 does *not* include BCOLOR, so basically the limits for generic indices would need to be conditional on BCOLOR being present or not (e.g. if it is present, we must reserve two semantic slots in svga for it). POSITION0 is obviously special. PSIZE0 is also special for points. FOG0 seems right now to just be a GENERIC with a single component. Gallium could be extended to support fixed function fog, which most DX9 hardware supports (nv30/nv40 and r300). This is mostly orthogonal to the semantic issue. TGSI_SEMANTIC_NORMAL is essentially unused and should probably be removed The options are the ones you outlined, plus: (e) Allow arbitrary 32-bit indices. This requires slightly more complicated data structures in some cases, and will require svga and r600 to fallback to software linkage if numbers are too high. (f) Limit semantic indices to hardware interpolators _and_ introduce an interface to let the user specify an Personally I think the simplest idea for now could be to have all drivers support 256 indices or, in the case of r600 and svga, the maximum value supported by the hardware, and
Re: [Mesa3d-dev] Does DX9 SM3 - VMware svga with arbitrary semantics work? How?
On Wed, 2010-03-03 at 11:23 -0800, Luca Barbieri wrote: And never will... It does not export PIPE_CAP_GLSL, and does not have the shader opcodes to ever do so. Any Gallium driver should be able to support the GLSL subset without control flow. And if we had a proper optimization infrastructure capable of inlining functions, converting conditionals to multiplications and unrolling loops (e.g. look at what the nVidia Cg compiler does), then essentially all GLSL could be supported on any driver, with only limitations on the maximum number of loop iterations. Isn't it worth supporting that? BTW, proprietary drivers do this: for instance nVidia supports GLSL on nv30, which can't do control flow in fragment shaders and doesn't support SM3. OK, maybe never is too strong... But it's certainly a long way off... Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Does DX9 SM3 - VMware svga with arbitrary semantics work? How?
On Wed, 2010-03-03 at 06:58 -0800, Luca Barbieri wrote: BTW, i915 is also limited to 0-7 generic indices, and thus doesn't work with GLSL at all right now. This should be relatively easy to fix since it should be enough to store the generic indices in the texCoords arrays, and then pass them to draw_find_shader_output. Luca, If you want to go ahead and send a patch, I don't have a problem with it. Like you say, it should be an easy change. Keith -- 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-vertexelementcso branch merge
On Mon, 2010-03-01 at 20:18 -0800, Joakim Sindholt wrote:
On Tue, 2010-03-02 at 04:02 +0100, Roland Scheidegger wrote:
On 02.03.2010 00:18, Joakim Sindholt wrote:
On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
Hi,
this branch turns vertex element into a cso, so instead of
set_vertex_elements there's now the triad of
create/bind/delete_vertex_elements_state. I have converted all the
drivers except nouveau (I didn't do it because Christoph Bumiller
already did nv50, but I can give the rest of them a shot), though that
doesn't necessarily mean they are optimized for it (the idea is of
course to precalculate state on create, not just copy the pipe structs
and do everything on bind) - only i965g really does something close to
it (though still emits the state always). Drivers doing both hw vertex
shaders and using draw in some circumstances of course will have to
store both representations on create.
Also note that util_draw_vertex_buffer semantics have changed a bit
(caller needs to set vertex element state, which is a bit odd).
Roland
Can I still do things like:
element 0: - vbo 5
element 1: - vbo 2
and then set_vertex_buffers() with an array { zeros, zeros, vbo 2, zeros
zeros, vbo 5 } ?
The branch doesn't change pipe_vertex_element itself (except
nr_components got removed as that's really derived from the associated
pipe_format), only how those vertex elements are set. Hence you can do
exactly the same things you could do before. Though I'm not quite sure
what your zeros mean, if that's just a unused vbo it should be ok, but
it is probably not ok to just pass in a null pointer for a unused
pipe_vertex_buffer.
Roland
I did just mean empty buffers, but they're not actual buffers. I wrote
zeros because I literally just zero out everything in that particular
struct. There's no sense in binding 6 vbos when I really only have 2
Yes, this looks legal to me.
Keith
--
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] PK/UP* and NV_[vertex|fragment]_program* support in Gallium?
On Mon, 2010-03-01 at 10:25 -0800, Luca Barbieri wrote: I see that PK2US and friends are being removed. These would be necessary to implement NV_fragment_program_option, NV_fragment_program2 and NV_gpu_program4. Currently the no drivers (including Nouveau) support them, but since we already have some support in Mesa (even parsers for the nVidia syntax), it would be nice to support them in Gallium eventually. Not sure about STR/SFL though: they can be encoded/decoded as MOV x, 0/1, but they complete the SETcond instruction set. How about keeping them and adding a capability bit for them? At some stage we're definitely interested in the gpu_program4 extension. I'm not sure the older ones will ever be pulled in. There is more than just these few pack/unpack opcodes to support gpu4 though. I don't see much point keeping them hanging around as placeholders until somebody commits to do the real work of implementing the extension. Basically I'd like to see them removed until they actually get used, at which time they're welcome back in... Keith -- 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-vertexelementcso branch merge
On Mon, 2010-03-01 at 10:02 -0800, Roland Scheidegger wrote: Hi, this branch turns vertex element into a cso, so instead of set_vertex_elements there's now the triad of create/bind/delete_vertex_elements_state. I have converted all the drivers except nouveau (I didn't do it because Christoph Bumiller already did nv50, but I can give the rest of them a shot), though that doesn't necessarily mean they are optimized for it (the idea is of course to precalculate state on create, not just copy the pipe structs and do everything on bind) - only i965g really does something close to it (though still emits the state always). Drivers doing both hw vertex shaders and using draw in some circumstances of course will have to store both representations on create. Also note that util_draw_vertex_buffer semantics have changed a bit (caller needs to set vertex element state, which is a bit odd). Roland, The branch looks good to me, happy to see it merged when you're ready to go. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge
Michal, This is looking good to me - feel free to merge once any loose ends are tied up. Keith On Mon, 2010-03-01 at 17:46 -0800, Marek Olšák wrote: Ahhh, I am a bad liar. The attached patch fixes the regressions. -Marek On Tue, Mar 2, 2010 at 2:08 AM, Marek Olšák mar...@gmail.com wrote: Hi Michal, This branch breaks 2 piglit tests with r300g: depthrange-clear texdepth However I haven't investigated these and won't get to them until the weekend. I personally don't mind fixing the regressions after the merge (but I'm not the maintainer of r300g). Anyway I'm glad to see bypass_vs_clip_and_viewport dying. -Marek On Mon, Mar 1, 2010 at 5:08 PM, michal mic...@vmware.com wrote: Hi, This branch removes bypass_vs_clip_and_viewport flag from pipe rasterizer state. The benefits of having this bit around were dubious for everybody and burdensome for driver writers. All the utility code that relied on this flag have been rewritten to pass vertex positions in clip space and set clip and viewport state. I would like to ask the maintainers of u_blitter module to please test my changes and provide feedback. Please review. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- 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 Tue, 2010-03-02 at 02:44 -0800, José Fonseca wrote:
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
Re: [Mesa3d-dev] Does DX9 SM3 - VMware svga with arbitrary semantics work? How?
On Tue, 2010-03-02 at 03:26 -0800, Luca Barbieri wrote: I've been looking at shader semantics some more, and I'm a bit surprised by how the svga driver works. It seems that an obvious implementation of a DirectX 9 state tracker just won't work with the svga driver. I don't think anybody has tried hooking it up - so far the primary purpose of the svga gallium driver has been GL support, but thinking about it you're probably right. In SM3, vertex/fragment semantics can be arbitrary (independent of hardware resources), but indices are limited to a 0-15 range. A DirectX 9 state tracker must convert those to TGSI_SEMANTIC_GENERIC. How does the VMware one do that? Assuming that it maps them directly, this means that the driver must support GENERIC semantic indices up to a number that varies between about 200 and 255. The details of the closed code aren't terribly important as they could always be changed. But you're right that any DX9 state tracker would have to try to pack all or almost all the DX9 semantics into the TGSI GENERIC range. The simplest implementation would end up using 0..255. The problem is that the vmware svga driver, as far as I can see, doesn't support indices greater than 15. This is caused by the fact that it maps all GENERIC semantics to SVGA3D_DECLUSAGE_TEXCOORD, and the index bitfield in the svga virtual interface only supports 4 bits. Indeed, good point. That's basically a shortcoming of the current svga gallium driver which needs to be addressed somehow. In other words, SM3 under VMware with arbitrary semantics (allowed by SM3 and other drivers) really seems broken, for a straightforward DirectX9 state tracker implementation. The only way it can work now is if the DirectX 9 state tracker looks at both the vertex and pixel shaders, links them, and outputs sequential semantic indices. It seems to me that the svga driver should be fixed to map GENERIC to *all* SM3 semantic types, ideally in a way that reverses the SM3 - GENERIC transformation done by the DX9 state tracker. Agree, though I don't think reversibility is necessary. Doing this requires to specify a maximum index for TGSI_SEMANTIC_GENERIC which is very carefully chosen to allow 1:1 mapping with SM3, so that DirectX 9 state trackers have enough indices to represent all SM3, and the svga driver can fit all indices in the SM3-like semantics of the VMware virtual GPU interface. The correct value in this case seems to be 219 = 14 * 16 SM3 semantics - 5 for COLOR0, COLOR1, PSIZE0, POSITION0, FOG0 which have specific TGSI semantics which they need to mapped to/from. Agree, though I'd opt for 255 as a round number. I'm looking at this because this seems the strictest constraint on choosing a limit for TGSI_SEMANTIC_GENERIC indices. The other constraint is due to r600 supporting only byte-sized semantic/index combinations, which is less strict than SM3. BTW, glsl also looks artificially limited on svga, as only 6 varyings will be supported, due to it starting from 10. Agree, well spotted. I'll take a look at that. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Does DX9 SM3 - VMware svga with arbitrary semantics work? How?
On Tue, 2010-03-02 at 04:36 -0800, Luca Barbieri wrote: The correct value in this case seems to be 219 = 14 * 16 SM3 semantics - 5 for COLOR0, COLOR1, PSIZE0, POSITION0, FOG0 which have specific TGSI semantics which they need to mapped to/from. Agree, though I'd opt for 255 as a round number. The problem with this is that you only have 14 SM3 semantics with 16 indices each, so you can't map 256 generic indices into the VMware interface, or directly into an SM3 shader. You only have 14 * 16 minus the ones used for non-GENERIC semantics (the one mentioned above). And of course, if you choose a smaller number, you can't map SM3 _into_ Gallium, so you need to choose the exact number required for SM3. Tying Gallium in this way to SM3 is surely a bit ugly, but it's just a constant, and I don't see any other way to implement SM3 without doing linkage in software in the r600 and svga drivers and/or in SM3 state trackers. I accept that it can be viewed as an arbitrary constant, but maybe it's a step too far. If another API or piece of hardware came along that we decided was important, the calculations might change and we'd be stuck. I see our options as: a) Picking a lower number like 128, that an SM3 state tracker could usually be able to directly translate incoming semantics into, but which would force it to renumber under rare circumstances. This would make life easier for the open drivers at the expense of the closed code. b) Picking 256 to make life easier for some closed-source SM3 state tracker, but harder for open drivers. c) Picking 219 (or some other magic number) that happens to work with the current set of constraints, but makes gallium fragile in the face of new constraints. d) Abandoning the current gallium linkage rules and coming up with something new, for instance forcing the state trackers to renumber always and making life trivial for the drivers... I suspect we'll end up reworking the whole GENERIC idea at some stage, ie (d). But for now, I don't think that some piece of closed code should be dictating the gallium interface direction, so I'd suggest something that makes the open driver's lives easier -- ie (a) or (c). To be honest, I'd suggest keeping a modicum of independence in gallium plus making the open code simpler, and going with 128... But if you feel strongly, I don't mind the bigger number (219) either, except on aesthetic grounds... Keith -- 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 03:21 -0800, José Fonseca wrote: On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote: Hi, I am a bit puzzled, how a pipe driver should handle draw callback failure ? On radeon (pretty sure nouveau or intel hit the same issue) we can only know when one of the draw_* context callback is call if we can do the rendering or not. The failure here is dictated by memory constraint, ie if user bind big texture, big vbo ... we might not have enough GPU address space to bind all the desired object (even for drawing a single triangle) ? What should we do ? None of the draw callback can return a value ? Maybe for a GL stack tracker we should report GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line is i think pipe driver are missing something here. Any idea ? Thought ? Is there already a plan to address that ? :) Gallium draw calls had return codes before. They were used for the fallover driver IIRC and were recently deleted. Either we put the return codes back, or we add a new pipe_context::validate() that would ensure that all necessary conditions to draw successfully are met. Putting return codes on bind time won't work, because one can't set all atoms simultaneously -- atoms are set one by one, so when one's setting the state there are state combinations which may exceed the available resources but that are never drawn with. E.g. you have a huge VB you finished drawing, and then you switch to drawing with a small VB with a huge texture, but in between it may happen that you have both bound simultaneously. If ignoring is not an alternative, then I'd prefer a validate call. Whether to fallback to software or not -- it seems to me it's really a problem that must be decided case by case. Drivers are supposed to be useful -- if hardware is so limited that it can't do anything useful then falling back to software is sensible. I don't think that a driver should support every imaginable thing -- apps should check errors, and users should ensure they have enough hardware resources for the workloads they want. Personally I think state trackers shouldn't emulate anything with CPU beyond unsupported pixel formats. If a hardware is so limited that in need CPU assistence this should taken care transparently by the pipe driver. Nevertheless we can and should provide auxiliary libraries like draw to simplify the pipe driver implementation. My opinion on this is similar: the pipe driver is responsible for getting the rendering done. If it needs to pull in a fallback module to achieve that, it is the pipe driver's responsibility to do so. Understanding the limitations of hardware and the best ways to work around those limitations is really something that the driver itself is best positioned to handle. The slight quirk of OpenGL is that there are some conditions where theoretically the driver is allowed to throw an OUT_OF_MEMORY error (or similar) and not render. This option isn't really available to gallium drivers, mainly because we don't know inside gallium whether the API permits this. Unfortunately, even in OpenGL, very few applications actually check the error conditions, or do anything sensible when they fail. I don't really like the idea of pipe drivers being able to fail render calls, as it means that every state tracker and every bit of utility code that issues a pipe-draw() call will have to check the return code and hook in fallback code on failure. One interesting thing would be to consider creating a layer that exposes a pipe_context interface to the state tracker, but revives some of the failover ideas internally - maybe as a first step just lifting the draw module usage up to a layer above the actual hardware driver. Keith -- 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 03:55 -0800, Jerome Glisse wrote: On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote: On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote: On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote: Hi, I am a bit puzzled, how a pipe driver should handle draw callback failure ? On radeon (pretty sure nouveau or intel hit the same issue) we can only know when one of the draw_* context callback is call if we can do the rendering or not. The failure here is dictated by memory constraint, ie if user bind big texture, big vbo ... we might not have enough GPU address space to bind all the desired object (even for drawing a single triangle) ? What should we do ? None of the draw callback can return a value ? Maybe for a GL stack tracker we should report GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line is i think pipe driver are missing something here. Any idea ? Thought ? Is there already a plan to address that ? :) Gallium draw calls had return codes before. They were used for the fallover driver IIRC and were recently deleted. Either we put the return codes back, or we add a new pipe_context::validate() that would ensure that all necessary conditions to draw successfully are met. Putting return codes on bind time won't work, because one can't set all atoms simultaneously -- atoms are set one by one, so when one's setting the state there are state combinations which may exceed the available resources but that are never drawn with. E.g. you have a huge VB you finished drawing, and then you switch to drawing with a small VB with a huge texture, but in between it may happen that you have both bound simultaneously. If ignoring is not an alternative, then I'd prefer a validate call. Whether to fallback to software or not -- it seems to me it's really a problem that must be decided case by case. Drivers are supposed to be useful -- if hardware is so limited that it can't do anything useful then falling back to software is sensible. I don't think that a driver should support every imaginable thing -- apps should check errors, and users should ensure they have enough hardware resources for the workloads they want. Personally I think state trackers shouldn't emulate anything with CPU beyond unsupported pixel formats. If a hardware is so limited that in need CPU assistence this should taken care transparently by the pipe driver. Nevertheless we can and should provide auxiliary libraries like draw to simplify the pipe driver implementation. My opinion on this is similar: the pipe driver is responsible for getting the rendering done. If it needs to pull in a fallback module to achieve that, it is the pipe driver's responsibility to do so. Understanding the limitations of hardware and the best ways to work around those limitations is really something that the driver itself is best positioned to handle. The slight quirk of OpenGL is that there are some conditions where theoretically the driver is allowed to throw an OUT_OF_MEMORY error (or similar) and not render. This option isn't really available to gallium drivers, mainly because we don't know inside gallium whether the API permits this. Unfortunately, even in OpenGL, very few applications actually check the error conditions, or do anything sensible when they fail. I don't really like the idea of pipe drivers being able to fail render calls, as it means that every state tracker and every bit of utility code that issues a pipe-draw() call will have to check the return code and hook in fallback code on failure. One interesting thing would be to consider creating a layer that exposes a pipe_context interface to the state tracker, but revives some of the failover ideas internally - maybe as a first step just lifting the draw module usage up to a layer above the actual hardware driver. Keith So you don't like the pipe_context::validate() of Jose ? My taste goes to the pipe_context::validate() and having state tracker setting the proper flag according to the API they support (GL_OUT_OF_MEMORY for GL), this means just drop rendering command that we can't do. I think it's useful as a method for implementing GL_OUT_OF_MEMORY, but the pipe driver should: a) not rely on validate() being called - ie it is just a query, not a mandatory prepare-to-render notification. b) make a best effort to render in subsequent draw() calls, even if validate has been called - ie. it is just a query, does not modify pipe driver behaviour. I am not really interested in doing software fallback. What would be nice is someone testing with closed source driver what happen when you try to draw somethings the GPU can't handle. Maybe even people from closed source world can give us a clue on what
Re: [Mesa3d-dev] Gallium software fallback/draw command failure
On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote: On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote: On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote: On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote: On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote: Hi, I am a bit puzzled, how a pipe driver should handle draw callback failure ? On radeon (pretty sure nouveau or intel hit the same issue) we can only know when one of the draw_* context callback is call if we can do the rendering or not. The failure here is dictated by memory constraint, ie if user bind big texture, big vbo ... we might not have enough GPU address space to bind all the desired object (even for drawing a single triangle) ? What should we do ? None of the draw callback can return a value ? Maybe for a GL stack tracker we should report GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line is i think pipe driver are missing something here. Any idea ? Thought ? Is there already a plan to address that ? :) Gallium draw calls had return codes before. They were used for the fallover driver IIRC and were recently deleted. Either we put the return codes back, or we add a new pipe_context::validate() that would ensure that all necessary conditions to draw successfully are met. Putting return codes on bind time won't work, because one can't set all atoms simultaneously -- atoms are set one by one, so when one's setting the state there are state combinations which may exceed the available resources but that are never drawn with. E.g. you have a huge VB you finished drawing, and then you switch to drawing with a small VB with a huge texture, but in between it may happen that you have both bound simultaneously. If ignoring is not an alternative, then I'd prefer a validate call. Whether to fallback to software or not -- it seems to me it's really a problem that must be decided case by case. Drivers are supposed to be useful -- if hardware is so limited that it can't do anything useful then falling back to software is sensible. I don't think that a driver should support every imaginable thing -- apps should check errors, and users should ensure they have enough hardware resources for the workloads they want. Personally I think state trackers shouldn't emulate anything with CPU beyond unsupported pixel formats. If a hardware is so limited that in need CPU assistence this should taken care transparently by the pipe driver. Nevertheless we can and should provide auxiliary libraries like draw to simplify the pipe driver implementation. My opinion on this is similar: the pipe driver is responsible for getting the rendering done. If it needs to pull in a fallback module to achieve that, it is the pipe driver's responsibility to do so. Understanding the limitations of hardware and the best ways to work around those limitations is really something that the driver itself is best positioned to handle. The slight quirk of OpenGL is that there are some conditions where theoretically the driver is allowed to throw an OUT_OF_MEMORY error (or similar) and not render. This option isn't really available to gallium drivers, mainly because we don't know inside gallium whether the API permits this. Unfortunately, even in OpenGL, very few applications actually check the error conditions, or do anything sensible when they fail. I don't really like the idea of pipe drivers being able to fail render calls, as it means that every state tracker and every bit of utility code that issues a pipe-draw() call will have to check the return code and hook in fallback code on failure. One interesting thing would be to consider creating a layer that exposes a pipe_context interface to the state tracker, but revives some of the failover ideas internally - maybe as a first step just lifting the draw module usage up to a layer above the actual hardware driver. Keith So you don't like the pipe_context::validate() of Jose ? My taste goes to the pipe_context::validate() and having state tracker setting the proper flag according to the API they support (GL_OUT_OF_MEMORY for GL), this means just drop rendering command that we can't do. I think it's useful as a method for implementing GL_OUT_OF_MEMORY, but the pipe driver should: a) not rely on validate() being called - ie it is just a query, not a mandatory prepare-to-render notification. b) make a best effort to render in subsequent draw() calls, even if validate has been called - ie. it is just a query, does not modify pipe driver behaviour. I am not really interested in doing software fallback. What would be nice is someone testing with closed source
Re: [Mesa3d-dev] [RFC] gallium-winsys-handle branch merge
On Thu, 2010-02-25 at 20:46 -0800, Jakob Bornecrantz wrote: Howdy I'm hoping to merge the gallium-winsys-handle branch to master this weekend or early next week. The branch adds two new pipe screen functions to be used by the co state tracker (state tracker manger in new st_api.h speak). The branch also adds a new PIPE_TEXTURE_USAGE_SHARABLE flag telling the driver that the driver that the texture might be used for sharing. Even more so it also renames PIPE_TEXTURE_USAGE_PRIMARY to PIPE_TEXTURE_USAGE_SCANOUT just to make things clear. I also ported the egl,xorg,dri state trackers to the new interface and removing unneeded functions from drm_api making it even smaller, however I only ported i915g, i965 and svga to the new API. Looking at the commits where I port the other drivers it should be pretty clear what to do. Jakob, I think it's probably best if you make an attempt at the changes to the other drivers and then ask people to test your changes. This is how we've been doing other interface changes and it seems to be a good balance. Keith -- 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] Continue to allow building src/glx on current distros
On Wed, 2010-02-24 at 16:48 -0800, Mike Stroyan wrote: The ifdef changes to allow building with older libdrm and glproto header files are working. But the configure.ac requirements are still aggressive, requiring LIBDRM_REQUIRED=2.4.15 and GLPROTO_REQUIRED=1.4.11 Could those back down now that the source code itself is more flexible? Those version requirements are not met by debian testing or ubuntu 9.10. I'd be fine with this. Keith -- 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 07:33 -0800, Olivier Galibert wrote: On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote: Do you have solution/proposal/idea on how to handle the situation i am describing ? I've been looking at gallium from far away, but it seems to me you have two independant issues: - informing the caller of errors in atomic draw() calls - deciding what to do when the error is due to resource exhaustion For the first issue, if the api doesn't allow for returning errors, then the api is crap and has to be fixed. No two ways about it. Thanks for your comments. To reiterate what has already been said, the approach we're taking is: a) the driver makes a best effort to render under all circumstances b) we'll add an error notification path to generate GL_OUT_OF_MEMORY, but the state tracker will not be doing any fallbacks based on this. Keith -- 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 1/2] st/mesa: Make the frontbuffer visible on st_flush(PIPE_FLUSH_FRAME).
On Tue, 2010-02-16 at 09:45 -0800, Francisco Jerez wrote: So far the frontbuffer was only being flushed on st_glFlush and st_glFinish, however, a co-state tracker may need to make sure that any frontbuffer changes are already on its way to the actual front. I'm not sure this is true -- GL spec states that rendering to GL_FRONT is not necessarily visible until after GLFlush() or GLFinish() has been called. That seems to match the current behaviour. Keith -- 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] Mesa (gallium-sw-api): drm/sw: Wip drm winsys
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.
+
+static struct sw_displaytarget *
+swpc_dt_create(struct sw_callbacks *swc,
+ enum pipe_format format,
+ unsigned width, unsigned height,
+ unsigned alignment,
+ unsigned *stride)
+{
+ struct sw_pipe_callbacks *swpc = sw_pipe_callbacks(swc);
+ struct pipe_texture templ;
+ struct pipe_texture *tex;
+ memset(templ, 0, sizeof(templ));
+
+ templ-width0 = width;
+ templ-height0 = height;
+ templ-format = format;
+ /*
+ * XXX How do we tell the difference between displaytargets and primary
(scanout)?
+ * Aslo should all be rendertargets?
+ * What about depthstencil?
+ * XXX we pretty much need get usage passed down, maybe even the template.
+ */
+ templ-usage = 0;
+ /* XXX alignment isn't needed for DRM platform */
+ /* XXX stride isn't needed for DRM platform */
+
+ tex = swpc-screen-texture_create(swpc-screen, templ);
+
+ return sw_pipe_dt_wrap_texture(tex);
+}
+
This looks wrong. The software drivers will call this function from
inside texture_create, so you're setting up a recursive loop here.
The intent is that textures are implemented on top of displaytargets,
not the other way around. Look at llvmpipe for an example of this
already in use.
It really seems like there is confusion about how layering is supposed
to work here, and that the requirement in the dri2 state tracker to be
able to turn existing drm handles into textures is contributing to
this.
Keith
--
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] Mesa (master): util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats .
On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote: Module: Mesa Branch: master Commit: aa0b671422880b99dc178d43d1e4e1a3f766bf7f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=aa0b671422880b99dc178d43d1e4e1a3f766bf7f Author: Michal Krol mic...@vmware.com Date: Fri Feb 12 13:32:35 2010 +0100 util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats. Michal, Is this more like two different users expecting two different results in those unused columns? In particular, we definitely require the missing elements to be extended to (0,0,0,1) when fetching vertex data, and probably also in OpenGL texture sampling (if we supported these formats for that). Brian added a table of differences between GL and other APIs recently to gallium/docs - does your change agree with that? Keith -- 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] Mesa (master): util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats .
On Fri, 2010-02-12 at 05:09 -0800, michal wrote: Keith Whitwell wrote on 2010-02-12 13:39: On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote: Module: Mesa Branch: master Commit: aa0b671422880b99dc178d43d1e4e1a3f766bf7f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=aa0b671422880b99dc178d43d1e4e1a3f766bf7f Author: Michal Krol mic...@vmware.com Date: Fri Feb 12 13:32:35 2010 +0100 util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats. Michal, Is this more like two different users expecting two different results in those unused columns? In particular, we definitely require the missing elements to be extended to (0,0,0,1) when fetching vertex data, and probably also in OpenGL texture sampling (if we supported these formats for that). Gallium should follow D3D rules, so I've been following D3D here. Also, util_unpack_color_ub() in u_pack_color.h already sets the remaining fields to 0xff. Hmm, I'm not sure that's an absolute rule to be applied in every circumstance. The reason we tend to do that is because that's often what hardware implements. Brian added a table of differences between GL and other APIs recently to gallium/docs - does your change agree with that? Where's that exactly, I can't find it? At the bottom of tgsi.rst. Keith -- 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] Mesa (master): util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats .
On Fri, 2010-02-12 at 05:09 -0800, michal wrote: Keith Whitwell wrote on 2010-02-12 13:39: On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote: Module: Mesa Branch: master Commit: aa0b671422880b99dc178d43d1e4e1a3f766bf7f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=aa0b671422880b99dc178d43d1e4e1a3f766bf7f Author: Michal Krol mic...@vmware.com Date: Fri Feb 12 13:32:35 2010 +0100 util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats. Michal, Is this more like two different users expecting two different results in those unused columns? In particular, we definitely require the missing elements to be extended to (0,0,0,1) when fetching vertex data, and probably also in OpenGL texture sampling (if we supported these formats for that). Gallium should follow D3D rules, so I've been following D3D here. Also, util_unpack_color_ub() in u_pack_color.h already sets the remaining fields to 0xff. Note that D3D doesn't have the problem with expanding vertex attribute data since you can't have X or XY vertex positions, only XYZ (with W extended to 1 as in GL) and XYZW. But surely D3D permits two-component texture coordinates, which would be PIPE_FORMAT_R32G32_FLOAT, and expanded as (r,g,0,1)... Brian added a table of differences between GL and other APIs recently to gallium/docs - does your change agree with that? Where's that exactly, I can't find it? It seems like we'd want to be able to support both usages - the alternative in texture sampling would be forcing the state tracker to generate varients of the shader when 2-component textures are bound. I would say that's an unreasonable requirement on the state tracker. It seems like in GL would want (0,0,0,1) expansion everywhere, but D3D would want differing expansions in different parts of the pipeline. That indicates a single flag in the context somewhere isn't sufficient to choose between the two. Maybe there need to be two versions of these PIPE_FORMAT_ enums to capture the different values in the missing components? EG: PIPE_FORMAT_R32G32_0001_FLOAT PIPE_FORMAT_R32G32__FLOAT ? or something along those lines?? Keith -- 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] Mesa (master): util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats .
On Fri, 2010-02-12 at 05:44 -0800, michal wrote: Keith Whitwell wrote on 2010-02-12 14:28: On Fri, 2010-02-12 at 05:09 -0800, michal wrote: Keith Whitwell wrote on 2010-02-12 13:39: On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote: Module: Mesa Branch: master Commit: aa0b671422880b99dc178d43d1e4e1a3f766bf7f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=aa0b671422880b99dc178d43d1e4e1a3f766bf7f Author: Michal Krol mic...@vmware.com Date: Fri Feb 12 13:32:35 2010 +0100 util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats. Michal, Is this more like two different users expecting two different results in those unused columns? In particular, we definitely require the missing elements to be extended to (0,0,0,1) when fetching vertex data, and probably also in OpenGL texture sampling (if we supported these formats for that). Gallium should follow D3D rules, so I've been following D3D here. Also, util_unpack_color_ub() in u_pack_color.h already sets the remaining fields to 0xff. Note that D3D doesn't have the problem with expanding vertex attribute data since you can't have X or XY vertex positions, only XYZ (with W extended to 1 as in GL) and XYZW. But surely D3D permits two-component texture coordinates, which would be PIPE_FORMAT_R32G32_FLOAT, and expanded as (r,g,0,1)... Brian added a table of differences between GL and other APIs recently to gallium/docs - does your change agree with that? Where's that exactly, I can't find it? It seems like we'd want to be able to support both usages - the alternative in texture sampling would be forcing the state tracker to generate varients of the shader when 2-component textures are bound. I would say that's an unreasonable requirement on the state tracker. It seems like in GL would want (0,0,0,1) expansion everywhere, but D3D would want differing expansions in different parts of the pipeline. That indicates a single flag in the context somewhere isn't sufficient to choose between the two. Maybe there need to be two versions of these PIPE_FORMAT_ enums to capture the different values in the missing components? EG: PIPE_FORMAT_R32G32_0001_FLOAT PIPE_FORMAT_R32G32__FLOAT ? or something along those lines?? You are right. Alternatively, follow the more sane API (GL apparently), assume 0001 as default and use the infix to override. That sounds good to me too. Thanks Michal, Keith -- 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] Mesa (master): util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats .
On Fri, 2010-02-12 at 09:56 -0800, Roland Scheidegger wrote: On 12.02.2010 18:42, Keith Whitwell wrote: On Fri, 2010-02-12 at 09:28 -0800, José Fonseca wrote: On Fri, 2010-02-12 at 06:43 -0800, Roland Scheidegger wrote: On 12.02.2010 14:44, michal wrote: Keith Whitwell wrote on 2010-02-12 14:28: On Fri, 2010-02-12 at 05:09 -0800, michal wrote: Keith Whitwell wrote on 2010-02-12 13:39: On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote: Module: Mesa Branch: master Commit: aa0b671422880b99dc178d43d1e4e1a3f766bf7f URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=aa0b671422880b99dc178d43d1e4e1a3f766bf7f Author: Michal Krol mic...@vmware.com Date: Fri Feb 12 13:32:35 2010 +0100 util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats. Michal, Is this more like two different users expecting two different results in those unused columns? In particular, we definitely require the missing elements to be extended to (0,0,0,1) when fetching vertex data, and probably also in OpenGL texture sampling (if we supported these formats for that). Gallium should follow D3D rules, so I've been following D3D here. Also, util_unpack_color_ub() in u_pack_color.h already sets the remaining fields to 0xff. Note that D3D doesn't have the problem with expanding vertex attribute data since you can't have X or XY vertex positions, only XYZ (with W extended to 1 as in GL) and XYZW. But surely D3D permits two-component texture coordinates, which would be PIPE_FORMAT_R32G32_FLOAT, and expanded as (r,g,0,1)... Brian added a table of differences between GL and other APIs recently to gallium/docs - does your change agree with that? Where's that exactly, I can't find it? It seems like we'd want to be able to support both usages - the alternative in texture sampling would be forcing the state tracker to generate varients of the shader when 2-component textures are bound. I would say that's an unreasonable requirement on the state tracker. It seems like in GL would want (0,0,0,1) expansion everywhere, but D3D would want differing expansions in different parts of the pipeline. That indicates a single flag in the context somewhere isn't sufficient to choose between the two. Maybe there need to be two versions of these PIPE_FORMAT_ enums to capture the different values in the missing components? EG: PIPE_FORMAT_R32G32_0001_FLOAT PIPE_FORMAT_R32G32__FLOAT ? or something along those lines?? You are right. Alternatively, follow the more sane API (GL apparently), assume 0001 as default and use the infix to override. Note it's not just GL. D3D10 uses same expansion. Only D3D9 is different. Well for texture sampling anyway, I don't know what d3d does for vertex formats. Though for most hardware it would make sense to have only one format per different expansion, and use some swizzling parameter for sampling, because that's actually how the hardware works. But not all drivers will be able to do this, unfortunately. You mean, having a swizzle in pipe_sampler_state ? It sounds a good idea. In the worst case some component will inevitably need to make shader variants with different swizzles. In this case it probably makes sense to be the pipe driver -- it's a tiny shader variation which could be done without recompiling the whole shader, but if the state tracker does it then the pipe driver will always have to recompile. In the best case it is handled by the hardware's texture sampling unit. It's in theory similar to baking the swizzle in the format as Keith suggested, but cleaner IMHO. The question is whether it makes sense to have full xwyz01 swizzles, or just 01 swizzles. Another alternative is to just add the behaviour we really need - a single flag at context creation time that says what the behaviour of the sampler should be for these textures. Then the driver wouldn't have to worry about varients or mixing two different expansions. Hardware (i965 at least) seems to have one global mode to switch between these, and that's all we need to choose the right behaviour for each state tracker. It might be simpler all round just to specify it at context creation. Yes, for rg01 vs rg11 this is easiest. It doesn't solve the depth texture mode problem though. Also, we sort of have that flag already, I think there's no reason why this needs to be separate from gl_rasterization_rules (though I guess in that case it's a bit a misnomer...) I'd prefer to avoid a big I'm a GL/DX9 context flag, and split different behaviours into different flags. Sure, a GL state tracker might set them all one way, but that doesn't mean some future state-tracker wouldn't want to use a novel combination. The GL rasterization rules
Re: [Mesa3d-dev] Gallium query types
On Thu, 2010-02-11 at 10:13 -0800, michal wrote: Hi, I can't find any information regarding two Gallium query types. No documentation, no source code. #define PIPE_QUERY_PRIMITIVES_GENERATED 1 #define PIPE_QUERY_PRIMITIVES_EMITTED2 Do they have something to do with NV_transform_feedback extension? If not, do they mean the number of primitves before clipping, and after clipping, respectively? It looks like these have been there since the initial commit of the gallium query code. (Use git blame p_defines.h, find the line you're interested in, then git show 09fbb383) At that stage, it looked like there was a use for them in an nvidia extension, GL_PRIMITIVES_GENERATED_NV and GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_NV. Keith -- 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] Proposed gallium buffer/texture evolution
On Wed, 2010-02-10 at 07:22 -0800, Chia-I Wu wrote: On Tue, Feb 09, 2010 at 11:34:08AM +, Keith Whitwell wrote: I'm interested in exploring all of these options. My goal at this point is to make a first pass over the problem and fix the most significant architectural issues, specifically making transfers context-private, unifying the gpu-side aspects of buffers and textures, etc. In EGL, eglCopyBuffers can copy a pbuffer surface to a pixmap. In st/egl, it comes down to copy the contents of a pipe_texture to another one. Or, in the ximage backend of st/egl, when flush_frontbuffer or SwapBuffer, the backend uploads the contents of a privately owned pipe_texture to a window or pixmap using XPutImage. Either st/egl or its ximage backend has access only to a pipe_screen. What is the suggested way to read/write a pipe_texture after the change? Should I change them to create pipe_contexts of their own? I've been looking at the ximage backend. I think the issue there is that the interface to the software rasterizers is wrong. We could get egl just to create a pipe_context and use that, but I think a better change would be to avoid the need and have an equivalent to drm_api for the software drivers that provides the tools to avoid this. I've got a possible version of this in progress, I'll push it out for comments in the next couple of days. Keith -- 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] Proposed gallium buffer/texture evolution
On Tue, Feb 9, 2010 at 8:34 AM, Luca Barbieri luca.barbi...@gmail.com wrote: Instead of combining create/map and unmap/destroy it would be better to make map more powerful. If I understand correctly, you are proposing to add a subrectangle parameter to map/unmap, so that you can collect multiple rectangle updates in a single upload happening at transfer destruction time. This is interesting: I think a better effect can be obtained by merging the functions as described and also adding a validate_subrect and flush_subrect ranges that would respectively read back and upload a transfer subrectangle to/from the GPU object (and of course, destruction would no longer implicitly flush and creation no longer implicitly validate unless possibly told to so with a specific flag). At map/unmap time if you know the subset of data being read/written you can optimize the amount of data being transferred, especially in the write-only case where you can keep track of the dirty ranges and possibly combine them to fewer uploads. If you combine create+map and unmap+destroy you end up limiting yourself for no reason other than minor convenience. I think adding an explicit validate_subrect and flush_subrect allows to do this, and is actually better since it also allows efficient implementation of glFlushMappedBufferRange. However, I'm not sure whether, in the OpenGL case, this would be an optimization and not a pessimization. I'm interested in exploring all of these options. My goal at this point is to make a first pass over the problem and fix the most significant architectural issues, specifically making transfers context-private, unifying the gpu-side aspects of buffers and textures, etc. Once that's done, looking at the details of how we're doing transfers, and indeed what a transfer really is, is completely feasible. One option would be to say that a transfer is really just an abstraction of piece of AGP/DMA memory, and that up/downloads from specific gpu-side entities can be made by copy-to/from-transfer commands. Another might be to say that transfers turn into something like DX staging resources, with internal structure like width, height, mipmaps etc, which can be mapped by the CPU but never bound to the GPU, and again copy-to/from-staging-resource commands mediate the up/downloads. Yet a third would be to drop the transfer map/unmap commands and make their lifetime explicitly limited to a single up/download. Once the current round of changes is done, it may be easier to see what the best path forwards is. Keith Keith -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements
On Mon, 2010-02-08 at 07:20 -0800, Brian Paul wrote: be propagated through the pipeline when doing flat shading, no lighting, etc. Is this is the perennial problem that GL's float-unorm and unorm-float conversion rules are not strict inverses of one another? IE, if you take 255, convert to float, convert back to int, do you get 255? Keith -- 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] [xserver patch v4 4/5] glx/dri2: Notify the driver when its buffers become invalid.
Francisco,
Will Mesa continue to build after these changes for people who have not
tracked the latest glproto and dri2proto repos?
I'd prefer to be able to build Mesa on at least the most recently
released major distros, which may require the use of some #ifdefs in the
changes.
Keith
On Mon, 2010-02-08 at 10:25 -0800, Francisco Jerez wrote:
Signed-off-by: Francisco Jerez curroje...@riseup.net
---
glx/glxdri2.c | 28 +---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 0f998de..dae7b42 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -67,6 +67,7 @@ struct __GLXDRIscreen {
xf86EnterVTProc *enterVT;
xf86LeaveVTProc *leaveVT;
+PreConfigureWindowProcPtr PreConfigureWindow;
const __DRIcoreExtension *core;
const __DRIdri2Extension *dri2;
@@ -217,13 +218,13 @@ __glXDRIdrawableSwapBuffers(ClientPtr client,
__GLXdrawable *drawable)
__GLXDRIscreen *screen = priv-screen;
CARD64 unused;
-if (screen-flush)
- (*screen-flush-flushInvalidate)(priv-driDrawable);
-
if (DRI2SwapBuffers(client, drawable-pDraw, 0, 0, 0, unused,
__glXdriSwapEvent, drawable-pDraw) != Success)
return FALSE;
+if (screen-flush)
+ (*screen-flush-invalidate)(priv-driDrawable);
+
return TRUE;
}
@@ -607,6 +608,24 @@ glxDRILeaveVT (int index, int flags)
}
static void
+glxDRIPreConfigureWindow(WindowPtr pWin, int x, int y, int w, int h, int bw,
+ WindowPtr pSib)
+{
+ScreenPtr pScreen = pWin-drawable.pScreen;
+__GLXDRIscreen *screen = (__GLXDRIscreen *)glxGetScreen(pScreen);
+__GLXDRIdrawable *draw = (__GLXDRIdrawable
*)glxGetDrawableFromWindow(pWin);
+
+if (screen-PreConfigureWindow)
+ (*screen-PreConfigureWindow)(pWin, x, y, w, h, bw, pSib);
+
+if (!draw || (draw-height == h draw-width == w))
+ return;
+
+if (screen-flush)
+ screen-flush-invalidate(draw-driDrawable);
+}
+
+static void
initializeExtensions(__GLXDRIscreen *screen)
{
const __DRIextension **extensions;
@@ -782,6 +801,9 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
screen-leaveVT = pScrn-LeaveVT;
pScrn-LeaveVT = glxDRILeaveVT;
+screen-PreConfigureWindow = pScreen-PreConfigureWindow;
+pScreen-PreConfigureWindow = glxDRIPreConfigureWindow;
+
LogMessage(X_INFO,
AIGLX: Loaded and initialized %s\n, filename);
--
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] [xserver patch v4 4/5] glx/dri2: Notify the driver when its buffers become invalid.
On Mon, 2010-02-08 at 10:41 -0800, Francisco Jerez wrote: Keith Whitwell kei...@vmware.com writes: Francisco, Will Mesa continue to build after these changes for people who have not tracked the latest glproto and dri2proto repos? I'd prefer to be able to build Mesa on at least the most recently released major distros, which may require the use of some #ifdefs in the changes. That's one of the reasons of the last rebase, see the comments in [mesa patch v4 1/3] dri2: Event driven buffer validation.. Ah, fantastic! Thanks Francisco. Keith -- 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] Latest Mesa (Gallium st:dri) does not compile
OK, hopefully fixed with latest push. Keith On Mon, 2010-02-08 at 11:06 -0800, Johannes Obermayr wrote: (Please CC me - I am only subscribed for posting ...) Compiled commit: authorKeith Whitwell kei...@vmware.com 2010-02-08 17:15:47 (GMT) committer Keith Whitwell kei...@vmware.com 2010-02-08 17:17:59 (GMT) commit0b99303d1c6244094c24844f86f4e7677ee69f18 I think it is broken by this commit: authorKeith Whitwell kei...@vmware.com 2010-02-08 12:55:59 (GMT) committer Keith Whitwell kei...@vmware.com 2010-02-08 13:05:36 (GMT) commit7f41f5447c8f9113c8956901e1c5fff6081ecd94 As every time: I can provide a full log ... gmake[4]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium/drivers/nv50' gmake[3]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium/drivers' gmake[3]: Entering directory `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers' gmake[4]: Entering directory `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers/dri' rm -f depend touch depend /usr/bin/makedepend -fdepend -I/usr/lib64/gcc/x86_64-suse-linux/4.4/include -I/usr/lib64/gcc/x86_64-suse-linux/4.4/include-fixed -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I/src/gallium/include -I/src/gallium/auxiliary -I/src/gallium/drivers -I../../../../include -I../../../../src/mesa -I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main -I/usr/include/drm dri_context.c dri_screen.c dri_drawable.c dri_extensions.c 2 /dev/null gmake[4]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers/dri' gmake[4]: Entering directory `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers/dri' gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I/src/gallium/include -I/src/gallium/auxiliary -I/src/gallium/drivers -I../../../../include -I../../../../src/mesa -I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main -I/usr/include/drm -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 dri_context.c -o dri_context.o dri_context.c: In function 'dri_create_context': dri_context.c:72: error: 'struct pipe_screen' has no member named 'create_context' gmake[4]: *** [dri_context.o] Error 1 gmake[4]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers/dri' gmake[3]: *** [subdirs] Error 1 gmake[3]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src' make: *** [default] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.ggUmZc (%build) -- 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] glx: Fix SwapBuffers regression introduced by 01923fb72d.
OK, that's pretty wierd as I compared the binaries before/after the change and they seemed to be the same. I'm sorry for the mix up. Keith On Mon, Feb 8, 2010 at 10:15 PM, Francisco Jerez curroje...@riseup.net wrote: After that commit, some dri2 protocol symbols were being checked from places that weren't including dri2proto.h, effectively disabling some valuable SwapBuffers codepaths. --- src/glx/x11/dri2_glx.c | 1 + src/glx/x11/glxext.c | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c index 736cd3a..c4ce73e 100644 --- a/src/glx/x11/dri2_glx.c +++ b/src/glx/x11/dri2_glx.c @@ -37,6 +37,7 @@ #include X11/extensions/Xdamage.h #include glapi.h #include glxclient.h +#include X11/extensions/dri2proto.h #include xf86dri.h #include dlfcn.h #include fcntl.h diff --git a/src/glx/x11/glxext.c b/src/glx/x11/glxext.c index dde694b..c2de1a3 100644 --- a/src/glx/x11/glxext.c +++ b/src/glx/x11/glxext.c @@ -41,6 +41,7 @@ #include glxclient.h #include X11/extensions/Xext.h #include X11/extensions/extutil.h +#include X11/extensions/dri2proto.h #include glxextensions.h #include glcontextmodes.h -- 1.6.4.4 -- 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] empty vertex buffers
On Fri, Feb 5, 2010 at 2:46 PM, Joakim Sindholt b...@zhasha.com wrote: Let's assume I have an array of vertex elements that indicate position/color in vertex buffer #3. Let's also for the sake of argument say that there is nothing else in my vertex elements. No other buffers are being pointed to. Is it legal for me to pipe_context::set_vertex_buffers with an array size of 3 and set buffer 1 and 2 == NULL? Not to mention buffer 0... At the moment I'd say that, yes this is permitted. I'm not sure if there is any state-tracker out there that really wants to be able to do this, though, so it is something we could look at tightening up if it is causing real pain at the driver level. Keith -- 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-cylindrical-wrap branch
On Fri, Feb 5, 2010 at 5:29 PM, Brian Paul bri...@vmware.com wrote: michal wrote: michal wrote on 2010-02-05 11:05: Brian Paul wrote on 2010-02-04 22:07: michal wrote: Brian Paul wrote on 2010-02-03 17:58: Keith Whitwell wrote: Michal, why do you need this for linear interpolator and not perspective? I think d3d mobile let you disable perspective correct texturing, but it is always enabled for normal d3d. I could not think of a use case that uses perspective and cylindrical interpolation at the same time. If you think it's valid, we can implement cylindrical wrapping for perspective interpolator, but then I am not sure how exactly it should be done, i.e. should we divide and then wrap or the opposite? Is there some way we can figure out what DX9 does here? Maybe a quick test? I suspect cylindrical wrapping would be done after the divide. A quick test shows it is legal to have perspective and cylindrical interpolation. In fact, I see no difference between projected and non-projected version with REF device -- both are perspective correct. I think I am stuck at this point and need further help. I am trying to modify tri_persp_coeff() in softpipe in a similar manner to tri_linear_coeff(), but all I get are lousy rendering artifacts. If we need do cylindrical wrapping after divide, it must be done as part of shader interpolator, but the only place where we have enough information to do wrapping is in primitive setup. Do you have a patch relative to gallium-cylindrical-wrap? I'll take a look. Brian, I have no half-working patch for you, sorry. I tried a few approaches, but they were nonsensical. The linear coeff calculation is simple: calculate distance between two coordinates, and if it's greater than 0.5, apply wrapping by adjusting the distance. However, for the perspective correct coeffs, we divide early by position.w before calculating the distance, and so my approach that worked for linear fails here. I am either not comprehending the math here (why do we divide the second time in interpolator, for instance?) or we need to put more information into struct tgsi_interp_coef so that the interpolator code has enough information to do wrapping on its own without help of primitive setup. OK, I managed to correctly implement cylindrical wrap in softpipe both for linear and perspective interpolation, both for lines and triangles. Tested with Brian's cylwrap test app -- it works. Please re-review. Thanks. Seems to work as expected. The code looks good. Thanks. -Brian I had one question about whether it's neccesary to do three wrapping calculations per triangle, or just two. Once that's resolved, I'm fine to see this merged. Keith -- 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] call for testers: galllium-screen-context branch
We've had a couple of cleanups that we've wanted to do in gallium for as long as I can remember. One of which is to remove all the random context-creation calls and funnel them through something sensible like a context_create() call in pipe_screen. The gallium-screen-context branch does exactly that. The trouble is this change touches every driver and state-tracker in every combination. I can't even build half the drivers (what do I need to install to build nouveau?), let alone test them in any meaningful way. So, I really need people to take a look at this branch and make sure you can still at least build the driver, run some simple apps, etc. Keith -- 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] Continue to allow building src/glx on current distros
Jesse,
Can you take a look at the attached patch? I'd really like to be able
to build mesa and the DRI drivers on current distros (eg Ubuntu 9.10)
without having to pull in heaps of dependencies. The patch adds
#ifdefs to protect against the newer DRI2 protocol changes, meaning I
can build-test linux-dri and related targets with just the
distro-supplied packages.
Keith
commit d7b57f4061b82322cbcae176125913d9f0dea6c1
Author: Keith Whitwell kei...@vmware.com
Date: Thu Feb 4 12:46:21 2010 +
glx: permit building with older protocol headers
I'd like to be able to build mesa on current distro releases without
having to upgrade from the standard dri2proto and glproto headers. With
this change I'm able to build on ancient releases such as Ubuntu 9-10...
In general, it would be nice to be able to build-test mesa to check for
unintended breakages without having to follow the external dependencies
of every group working on the codebase.
diff --git a/src/glx/x11/dri2.c b/src/glx/x11/dri2.c
index 832935a..91053d3 100644
--- a/src/glx/x11/dri2.c
+++ b/src/glx/x11/dri2.c
@@ -94,6 +94,8 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
XextCheckExtension(dpy, info, dri2ExtensionName, False);
switch ((wire-u.u.type 0x7f) - info-codes-first_event) {
+
+#ifdef X_DRI2SwapBuffers
case DRI2_BufferSwapComplete:
{
GLXBufferSwapComplete *aevent = (GLXBufferSwapComplete *)event;
@@ -123,6 +125,8 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
aevent-sbc = ((CARD64)awire-sbc_hi 32) | awire-sbc_lo;
return True;
}
+#endif
+
default:
/* client doesn't support server event */
break;
@@ -455,6 +459,7 @@ DRI2CopyRegion(Display * dpy, XID drawable, XserverRegion region,
SyncHandle();
}
+#ifdef X_DRI2SwapBuffers
static void
load_swap_req(xDRI2SwapBuffersReq *req, CARD64 target, CARD64 divisor,
CARD64 remainder)
@@ -496,7 +501,9 @@ void DRI2SwapBuffers(Display *dpy, XID drawable, CARD64 target_msc,
UnlockDisplay(dpy);
SyncHandle();
}
+#endif
+#ifdef X_DRI2GetMSC
Bool DRI2GetMSC(Display *dpy, XID drawable, CARD64 *ust, CARD64 *msc,
CARD64 *sbc)
{
@@ -527,7 +534,9 @@ Bool DRI2GetMSC(Display *dpy, XID drawable, CARD64 *ust, CARD64 *msc,
return True;
}
+#endif
+#ifdef X_DRI2WaitMSC
static void
load_msc_req(xDRI2WaitMSCReq *req, CARD64 target, CARD64 divisor,
CARD64 remainder)
@@ -571,7 +580,9 @@ Bool DRI2WaitMSC(Display *dpy, XID drawable, CARD64 target_msc, CARD64 divisor,
return True;
}
+#endif
+#ifdef X_DRI2WaitSBC
static void
load_sbc_req(xDRI2WaitSBCReq *req, CARD64 target)
{
@@ -610,7 +621,9 @@ Bool DRI2WaitSBC(Display *dpy, XID drawable, CARD64 target_sbc, CARD64 *ust,
return True;
}
+#endif
+#ifdef X_DRI2SwapInterval
void DRI2SwapInterval(Display *dpy, XID drawable, int interval)
{
XExtDisplayInfo *info = DRI2FindDisplay(dpy);
@@ -627,5 +640,6 @@ void DRI2SwapInterval(Display *dpy, XID drawable, int interval)
UnlockDisplay(dpy);
SyncHandle();
}
+#endif
#endif /* GLX_DIRECT_RENDERING */
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index 7a5740a..6200df9 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -380,8 +380,10 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
return 0;
}
+#ifdef X_DRI2SwapBuffers
DRI2SwapBuffers(pdraw-psc-dpy, pdraw-xDrawable, target_msc, divisor,
remainder, ret);
+#endif
#if __DRI2_FLUSH_VERSION = 2
if (pdraw-psc-f)
@@ -576,18 +578,24 @@ dri2CreateScreen(__GLXscreenConfigs * psc, int screen,
psp-swapBuffers = dri2SwapBuffers;
psp-waitGL = dri2WaitGL;
psp-waitX = dri2WaitX;
+ psp-getDrawableMSC = NULL;
+ psp-waitForMSC = NULL;
+ psp-waitForSBC = NULL;
+ psp-setSwapInterval = NULL;
+ psp-getSwapInterval = NULL;
+
if (pdp-driMinor = 2) {
+#ifdef X_DRI2GetMSC
psp-getDrawableMSC = dri2DrawableGetMSC;
+#endif
+#ifdef X_DRI2WaitMSC
psp-waitForMSC = dri2WaitForMSC;
psp-waitForSBC = dri2WaitForSBC;
+#endif
+#ifdef X_DRI2SwapInterval
psp-setSwapInterval = dri2SetSwapInterval;
psp-getSwapInterval = dri2GetSwapInterval;
- } else {
- psp-getDrawableMSC = NULL;
- psp-waitForMSC = NULL;
- psp-waitForSBC = NULL;
- psp-setSwapInterval = NULL;
- psp-getSwapInterval = NULL;
+#endif
}
/* DRI2 suports SubBuffer through DRI2CopyRegion, so it's always
@@ -643,8 +651,10 @@ dri2CreateDisplay(Display * dpy)
pdp-driPatch = 0;
pdp-swapAvailable = 0;
+#ifdef X_DRI2SwapBuffers
if (pdp-driMinor = 2)
pdp-swapAvailable = 1;
+#endif
pdp-base.destroyDisplay = dri2DestroyDisplay;
pdp-base.createScreen = dri2CreateScreen;
diff --git a/src/glx/x11/glxext.c b/src/glx/x11/glxext.c
index 1b4ab71..dde694b 100644
--- a/src/glx/x11/glxext.c
+++ b/src/glx/x11/glxext.c
@@ -158,6 +158,16
