In the Appendix F of OpenGL ES 3.0.6 Specification, it is mentioned "Vector-wise uniform limits" as a not recommended legacy feature.
I don't know what it means and cannot find the explanation. Could someone help me to explain this terminology?
I think they mean that the constants MAX_FRAGMENT_UNIFORM_VECTORS and MAX_VERTEX_UNIFORM_VECTORS still exist in GLES 3, but that newer code should use MAX_FRAGMENT_UNIFORM_COMPONENTS or MAX_VERTEX_UNIFORM_COMPONENTS instead.
Related
MSVC and ICC both support the intrinsics _addcarry_u64 and _addcarryx_u64.
According to Intel's Intrinsic Guide and white paper these should map to adcx and adox respectively. However, by looking at the generated assembly it's clear they map to adc and adcx respectively and there is no intrinsic which maps to adox.
Additionally, telling the compiler to enable AVX2 with /arch:AVX2 in MSVC or -march=core-avx2 with ICC on Linux makes no difference.
I'm not sure how to enable ADX with MSVC and ICC.
The documentation for MSVC lists _addcarryx_u64 with the technology of ADX whereas _addcarry_u64 has no listed technology. However, the link in MSVC's documentation for these intrinsics goes directly to the Intel Intrinsic guide which contradicts MSVC's own documentation and the generated assembly.
From this I conclude that Intel's Intrinsic guide and white paper are wrong.
This makes some sense for MSVC sense it does not allow inline assembly it should provide a way to use adc which it does with _addcarry_u64.
One of the big advantages of adcx and adox is that they operate on different flags (carry CF and overflow OF) and this allows two independent parallel carry chains. However, since there is no intrinsic for adox how is this possible? With ICC at least one can use inline assembly but this is not possible with MSVC in 64-bit mode.
Microsoft and Intel's documentation (both the white paper and the intrinsic guide online) both agree now.
The _addcarry_u64 intrinsic documentation says produces only adc. The _addcarryx_u64 intrinsic can produce either adcx or adox. With MSVC 2013 and 2015, however, _addcarryx_u64 only produces adcx. ICC produces both.
They map to adc, adcx AND adox. The compiler decides which instructions to use, based on how you use them. If you perform two big-int additions in parallel the compiler will use adcx and adox, for higher throughput. For example:
unsigned char c1 = 0, c2 = 0
for(i=0; i< 100; i++){
c1 = _addcarry_u64(c1, res[i], a[i], &res[i]);
c2 = _addcarry_u64(c2, res[i], b[i], &res[i]);
}
Related, GCC does not support ADOX and ADCX at the moment. "At the moment" includes GCC 6.4 (Fedora 25) and GCC 7.1 (Fedora 26). GCC effectively disabled the intrinsics, but it still advertises support by defining __ADX__ in the preprocessor. Also see Issue 67317, Silly code generation for _addcarry_u32/_addcarry_u64. Many thanks to Xi Ruoyao for finding the issue.
According to Uros Bizjak on the GCC Help mailing list, GCC may never support the intrinsics. Also see GCC does not generate ADCX or ADOX for _addcarryx_u64.
Clang has its own set of issues with respect to ADOX and ADCX. Clang 3.9 and 4.0 crash when attempting to use them. Also see Issue 34249, Panic when using _addcarryx_u64 with Clang 3.9. According to Craig Topper, it should be fixed in Clang 5.0.
My apologies for posting the information under a MSVC question. This is one of the few hits when searching for information about using the intrinsics.
As question says it all I was looking for in depth explanation of data-dependency barrier in SMP especially with respect to Linux Kernel. I have the definition and brief description handy in this link here.
Linux Kernel Memory Barriers Documentation
However I was attempting to get a profound understanding of this concept. Your thoughts and inputs are highly appreciated.
Actually, at least in terms of C++11, this is more closely related to consume semantics. You can read more about it e.g. here. In short, they provide weaker guarantees than acquire semantics, which makes them more efficient on certain platforms that support data dependency ordering.
In C++ terms, it is called memory_order_consume. See this presentation from Paul Mckenney.
Old answer: I believe "acquire semantics" is the more commonly used term for what the document is calling a "data-dependency barrier". See for example this presentation or the C++11 memory_order_acquire.
Update: per comments, the Linux description for Data Dependency Barriers sounds more like C++ "consume semantics".
http://en.wikipedia.org/wiki/Constructive_solid_geometry
I'm much interested in doing what the first pictures describe on this article, only that I'm only interested in doing it on parallelepipeds (cube-like shapes), so no sphere or tube or circular shapes whatsoever.
There is this library, http://www.cgal.org/ , but it has a lot of features, and I don't know if it does what I'm looking for, and if yes, what parts could I use ?
Do you know any other library that does what I want ?
C/C++ is preferred over C#/java, but I'm open... The goal being to not reinvent the wheel.
If you need only rendering (no mesh generation), look at this.
If you need to generate new mesh:
UnBBoolean/J3DBool (Java)
J3DBool ported to C++, modified for QT, modified for Ogre
Carve (C++) (it is used in Blender, but I was unable to make it work + obsolete documentation)
GTS Library (C++) (maybe too overkill)
Personaly, I picked Ogre version, rewrote to use STL containers (it use fixed size for face count) and slightly optimized.
A list of libraries can be found here
I am working on embedded linux, Is there any open source 2D renderer available which can draw on memory, scanline based, complete fixed-point support.
I work in c or cpp programming language.
I know one with which satisfy my all needs that is, Google Skia which google uses in android and chrome, But I found it without documentation, not straight-forward compilable, not straight-forward usable in 3rd party projects.
Regards, Sunny.
Checkout Cairo. I am not sure what you mean by "complete fixed-point support" but other than that it seems to meet your requirements.
Allegro is a games library which includes extensive software rendering, most of which does not rely on floating point. Additionally it has some trig functions and maths functions which work on fixed-point. It has things like sprite-rotation which don't need floating point.
Don't know if it's what you're looking for, but there's libcrtxy
http://libcrtxy.sourceforge.net/
DirectFB.
If you want hardware acceleration , directFB is the most portable way to go.
I would like to learn graphics programming with OpenGL. And since I will just start learning it I decided to learn the new/OpenGL3 way of doing things.As far as I can see one has to create an OpenGL 3 context for this (Core profile in the new OpenGL 3.2 if I understand this correctly). Well I thought about using Qt for this, currently using version 4.5.2, since I know it already and like it and it supports creating the OpenGL widget. What I have the problem with is that it looks like the OpenGL widget is always crated with the old OpenGL 2 context and I can't see the option to make it in/switch it to OpenGL 3 way. Am I missing some obvious thing here or do I need something a bit more tricky to create OpenGL 3 context with Qt? Is it even supported in current version of Qt? I'm using Linux, if it makes any difference.
Mesa software rendering is still stuck on OpenGL 2.1. If you're using the binary NVidia drivers they provide OpenGL 3.2 support on sufficiently recent hardware. AMD's latest fglrx supports 3.1. Open Source drivers seem to top out around 1.3-1.4.
If you've gotten this far you'll probably have to hack the Qt sources to use GLX_ARB_create_context instead of GLXCreateContext to get a OpenGL 3.2 Core context.
This guy seems to have had partial success, if you haven't already come across the thread via Google.