« on: February 18, 2016, 03:09:37 PM »
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
I like the list a lot It looks almost like the list of my favorites, except just:
- FastStone Image Viewer - IMHO best image browser. Freeware (not for commercial use). XnView is also a good alternative.
- foobar2000 - music player. Previously I used Aimp, which looks more like lightweight version of Winamp.
- jEdit - my favorite plain text editor. Very powerful. Its only drawback: it's written in Java
- WinDirStat - shows statistics and draws treemap of disk usage.
Hello and welcome to our series of blog posts covering performance advice for Direct3D® 12 & Vulkan™. You may have seen the #DX12PerfTweets on Twitter, and asked yourself where you can find some more background information – search no more, we’ve got you covered. Today, we’ll be looking at command lists, a feature which is only present in explicit APIs that expose fairly directly the DMA command buffer architecture of most modern 3D hardware.
The most important fact about command lists is that they can be recorded from multiple threads. This is one of the major advantages of Direct3D 12 and Vulkan over previous APIs. Optimal performance will be achieved by using as many CPU threads as there are available to record command lists. There are no hidden driver threads in Direct3D 12 and Vulkan that could interfere with you – all the threading performance comes directly from the application.
EASTL stands for Electronic Arts Standard Template Library. It is a C++ template library of containers, algorithms, and iterators useful for runtime and tool development across multiple platforms. It is a fairly extensive and robust implementation of such a library and has an emphasis on high performance above all other considerations.
Ion is a portable suite of libraries and tools for building client applications,
especially graphical ones. It is small, fast, and robust, and is cross-platform
across many platforms and devices, including desktops, mobile devices, browsers,
and other embedded platforms.
Why Use Ion?
* Small: < 500k binary size on mobile platforms, often much smaller
* Powerful: Tools for faster productivity when developing applications
* Robust, portable application infrastructure aids in:
* Object lifetime management
* Memory allocation
* Application start-up and static instances
* Run-time setting editing
* Automatic performance instrumentation
* Tools for graphics:
* Analyze graphics scenes to find performance bottleneck
* Trace all OpenGL calls and examine their arguments
* Use scene resources in multiple contexts, automatically
* Run-time graphics state introspection
* Run-time shader editing: change your shaders and immediately see the results
* Fast graphics: Minimal overhead between your application and OpenGL / ES
* Tested: Well-tested and facilitates testing your application
* ~100% test coverage
* Black- and white-box tested, unit tests and integration tests
* Mock implementation of OpenGL API allows direct renderer unit tests and
* Integrated Remote: extensible API allows changing arbitrary application
settings on-the-fly for faster development, testing, and debugging
* Desktop: Linux, Mac OSX, Windows (OpenGL)
* Handheld: Android (ARM, x86 MIPS), iOS (ARM and x86), and their 64-bit
* Browser: Emscripten/asm.js, NaCl / pNaCl
* Used by many teams across Google, running on billions of devices through
multiple Google products
Excellent, but i don't know how to port those multipass shaders to GeeXLab
Vulkan offers another key difference to OpenGL with respect to memory allocation. When it comes to managing memory allocations as well as assigning it to individual resources, the OpenGL driver does most of the work for the developer. This allows applications to be developed, tested and deployed very quickly. In Vulkan however, the programmer takes responsibility meaning that many operations that OpenGL orchestrates heuristically can be orchestrated based on an absolute knowledge of the resource lifecycle.