-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michał Król wrote: > Ian Romanick pisze: >> Michał Król wrote: >>> Ian Romanick pisze: >>> >>>> Synchronization, memory barriers, atomic operations, etc. are all dark >>>> voodoo. It's one of those things like crypto that really should be >>>> left >>>> to the experts. Re-inventing it is almost universally the wrong >>>> choice. >>>> >>> Ian, >>> >>> How would we use libatomic_ops in Windows environment? Would libatomic >>> code be an integral part of gallium codebase or would it be something >>> the end user would have to pull in from external source in order to >>> compile mesa? >> >> I'd expect the user would have to pull it from upstream. I think there >> is a Windows build available, so that should be too difficult. If there >> isn't we could make a Windows build available on mesa3d.org. This >> wouldn't be any different that with LLVM, right? >> > But is it really worth the effort for such a primitve functionality as > atomic ops? Especially when the operating system provides you with a > neat set of entry points that let you do things with a single call? > > I hardly agree that atomic operations are magic and require non-trivial > amount of effort to do right. I haven't looked at libatomic's sources, > but I bet its value is in a fine support for multitude of systems out > there. I am affraid we are not the target audience of the library in > question -- if you do some big & fancy multithreaded math app it makes > sense to pull in the library and recompile the code for a new platform. > For gallium, however, porting to a new environment is a challenge and an > ultimate goal of gallium development.
The real value of libatomic_ops is in the vast amount of developer knowledge regarding processor inner workings that has been poured into it. I used to think that atomic operations were a trivial thing. Then I picked up a processor manual and started reading about the various synchronization primitives available. I then started reading about how the set of available synchronization primitives changes from processor to processor within the same family. I then started reading about how the various cache and pipeline stages interact in non-trivial and non-obvious ways in different circumstances. I then stopped reading because I had actual work to do. I'm sure the usage model for these operations in gallium is trivial *today*. But what is it going to be in a month? 6 months? A year? Do you really want to keep coming back to this code to patch and tweak it? Or would you rather just use some existing, well tested code written by someone who actually knows all the intricacies of how inter-processor synchronization works? It's your call how your time is best used. I've been down this road enough times that it's not even a choice I have to consciously make. *shrug* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknAF3YACgkQX1gOwKyEAw89QgCgmhmZjea0CcLT8hPArG7+mcYG fY4An1fy3HET6RcCxRQpl2XLJpkqRrPv =yO5L -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
