Show Posts

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.


Topics - JeGX

Pages: [1] 2 3 ... 34
1
Quote
Recently we introduced the VK_NVX_device_generated_commands (DGC) Vulkan extension, which allows rendering commands to be generated entirely on the GPU.

Earlier this week, we added support for VK_NVX_device_generated_commands to our Windows and Linux release drivers.

Today we are releasing the ‘BasicDeviceGeneratedCommandsVk’ SDK GameWorks sample. We highly recommend reading the introductory Vulkan Device-Generated Commands article in addition to this blog post.

VK_NVX_device_generated_commands is available in R376.09.

Links:
- Driver and New Sample for VK_NVX_device_generated_commands
- Vulkan Device-Generated Commands
- BasicDeviceGeneratedCommandsVk sample @ github

2
Quote
Understanding concurrency (and what breaks it) is extremely important when optimizing for modern GPUs. Modern APIs like DirectX® 12 or Vulkan™ provide the ability to schedule tasks asynchronously, which can enable higher GPU utilization with relatively little effort.

Link: http://gpuopen.com/concurrent-execution-asynchronous-queues/

4
Quote
As a PBF solver FleX can't directly compete with a specialized FLIP one like Cataclysm when it comes to simulating hundreds of thousands of fluid particles in real-time, but it was never meant to do such large-scale simulations by design. FleX is a different type of solver, it can model not only liquids but solids, cloth and soft bodies (hence the term: "unified"). It also supports phase changes between different material types, which means you can take a mesh, turn it into liquid, freeze the liquid and vaporize it, for example.

In the role of a fluid solver, FleX is free to use, runs on any consumer-grade GPU newer than GTX 650, requires no simulation domes to be set up or voxel resolutions to be calculated, can be easily integrated into pretty much any game engine or DCC, produces very high-quality results and is FAST (again: for a PBF solver). To me it looks like sort of a middle-ground solution for small or medium-scale simulations.

Link: http://cgicoffee.com/blog/2016/11/nvidia-physx-flex-fluid-simulation-and-other-solvers

5
matrixmultiplication.xyz is an interactive calculator for matrices.

Link: http://matrixmultiplication.xyz/
 

6
3D-Tech News Around The Web / A practical guide to securing macOS
« on: November 24, 2016, 05:52:28 PM »
Quote
This is a collection of thoughts on securing a modern Apple Mac computer using macOS (formerly "OS X") 10.12 "Sierra", as well as steps to improving online privacy.

This guide is targeted to “power users” who wish to adopt enterprise-standard security, but is also suitable for novice users with an interest in improving their privacy and security on a Mac.

There is no security silver bullet. A system is only as secure as its administrator is capable of making it.

Link: https://github.com/drduh/macOS-Security-and-Privacy-Guide

7
Quote
Our productivity tremendously depends on the tools we use. One of the fundamental tools for the software developers, researchers and analysts is the programming language. There are no silver bullets, each language fits the best for the specific purpose. Sometime it’s critical to prototype fast and we often use Python, but when it comes to the performance then C/C++ is the standard choice.
The Open Source movement significantly accelerated evolution and capabilities of the software ecosystems. It was literally impossible to build a full-fledged operational system within one-two yeas no so long ago. You can argue that Linux did it, but Linux was only a kernel that uses GNU ecosystem being developed many years before. In contrary, Redox OS appeared in the end of 2015 being developed using Rust language ecosystem and become probably the most secure existing OS. This is an excellent example of how the language selection impacts the project destiny (execution speed, reliability, security, development community, etc.).

Link: https://eprolangs.blogspot.ch/2016/11/overview-of-efficient-programming.html

8
English forum / Shadertoy Multipass Demopack
« on: November 24, 2016, 05:43:08 PM »
I finally released the demopack with Shadertoy multipass demos for GeeXLab  :P

The demopack is available in the gl-21/shadertoy-multipass/ folder of the code sample pack.

Complete story + all useful links:
http://www.geeks3d.com/20161124/shadertoy-multipass-demopack-for-geexlab/


9
English forum / Rendering real time 3D on RGB LED Matrix Panel with GeeXLab
« on: November 21, 2016, 05:09:24 PM »
First article: Adafruit 32×32 RGB LED Matrix Panel unboxing

Quote
I’m starting a series of articles about how to render real time 2D/3D graphics on RGB LED matrix panels with a Raspberry Pi. Even if the resolution of graphics is very low (32×32 pixels for a 32×32 LED display), drawing 3D stuff on that kind of display is very cool!

Link: http://www.geeks3d.com/20161121/adafruit-32x32-rgb-led-matrix-panel-4mm-pitch-unboxing/


10
3D-Tech News Around The Web / globjects 1.0.0 released
« on: November 21, 2016, 04:52:25 PM »
CG Internals releasedglobjects version 1.0.0. globjects is a cross-platform, object-oriented open source library for the OpenGL API. It facilitates a modern, less cluttered, and less error-prone use of the OpenGL API: e.g., it reduces the amount of OpenGL code required for rendering and facilitates coherent OpenGL use by means of a type-safe abstraction layer based on glbinding and OpenGL Mathematics (GLM). Common rendering processes are automated and missing features of specific OpenGL drivers are partially simulated or emulated at run-time.

OpenGL uses the concept of states (e.g., point size, rasterization state) and objects (e.g., textures and shaders) by design. Since OpenGL is a C API, objects are referenced classically using handles. globjects replaces these handles with classes for each object and exposes their associated OpenGL functions and provides additional tools for convenience. For example, a globjects texture encapsulates OpenGL texture creation, initialization, modification, and deletion, as well as a default texture setup.

Code snippet:
Code: [Select]
auto program = new globjects::Program();

program->attach(
  globjects::Shader::fromString(GL_VERTEX_SHADER, vertexShaderSource),
  globjects::Shader::fromString(GL_FRAGMENT_SHADER, fragmentShaderSource));

program->setUniform("extent", glm::vec2(1.0f, 0.5f)));

globjects can be used in rendering frameworks and engines as a rendering API wrapper for ease of use. Furthermore, it is well suited for learning OpenGL and its concepts as it communicates modern OpenGL (and automatically uses fallback implementations within unified interfaces).

Links:
- Press release
- globjects @ github

11
English forum / Logitech G Products and RGB LED Illumination Functions
« on: November 19, 2016, 02:51:35 PM »
Quote
GeeXLab 0.13.0 comes with a new set of functions to deal with all of the LED backlighting and RGB capabilities of Logitech G products.

Thanks to this support, every owner of a Logitech G product can easily control the RGB lighting of its device.

The new set of functions (on Windows only) is available in Lua and Python and the documentation is available here: gh_logiled.

Article: http://www.geeks3d.com/hacklab/20161118/logitech-rgb-led-illumination-functions/



12
English forum / GeeXLab 0.13.0.0 released
« on: November 16, 2016, 09:21:31 PM »

13
Quote
Support for 7th Generation Intel® Core™ Processors on Microsoft Windows* and Linux* operating systems

Windows 10 Anniversary Update support

Yocto Project* support
- These processors are supported as target systems when running the Apollo Lake Yocto BSP (other OSes are not supported for these processors): 7th Generation Intel® Pentium® Processor J4000/N4000 and 7th Generation Intel® Celeron Processor J3000/N3000 Series for Desktop
- Offline compiler support with GPU assembly code generation
- Debug OpenCL kernels using the Yocto GPU driver on host targets (6th and 7th Generation Intel® Core Processor)

OpenCL™ 2.1 and SPIR-V* support on Linux* OS
- OpenCL 2.1 development environment with the experimental CPU-only runtime for OpenCL 2.1
- SPIR-V generation support with Intel® Code Builder for OpenCL™ offline compiler and Kernel Development Framework including textual representation of SPIR-V binaries

New analysis features in Kernel Development Framework for Linux* OS
- HW counters support
- Latency analysis on 6th and 7th Generation Intel® Core™ Processors


Link: https://software.intel.com/en-us/whats-new-code-builder-2016-r3

14
3D-Tech News Around The Web / NVIDIA GeForce GTX 1080 Ti
« on: November 15, 2016, 03:18:03 PM »
Possible specs:

- GPU: GP102
- CUDA cores: 3328 - between TITAN X (3584 cores) and GTX 1080 (2560 cores)
- Memory: 10GB, 384-bit memory interface, GDDR5 or GDDR5X
- Texture units: 208
- ROPs: 96
- Price: around USD $1000

Links:
- videocardz.com
- techpowerup.com
- hexus.net

15
English forum / VR is coming to GeeXLab
« on: November 14, 2016, 02:03:46 PM »
Virtual Reality (VR) is coming to GeeXLab. I recently bought a HTC Vive headset and I started a new plugin for GeeXLab based on OpenVR:







16
3D-Tech News Around The Web / Vulkan Programming Guide
« on: November 04, 2016, 08:37:12 PM »
The Definitive Vulkan Developer’s Guide and Reference: Master the Next-Generation Specification for Cross-Platform Graphics

Quote
The next generation of the OpenGL specification, Vulkan, has been redesigned from the ground up, giving applications direct control over GPU acceleration for unprecedented performance and predictability. Vulkan™ Programming Guide is the essential, authoritative reference to this new standard for experienced graphics programmers in all Vulkan environments.
 
Vulkan API lead Graham Sellers (with contributions from language lead John Kessenich) presents example-rich introductions to the portable Vulkan API and the new SPIR-V shading language. The author introduces Vulkan, its goals, and the key concepts framing its API, and presents a complex rendering system that demonstrates both Vulkan’s uniqueness and its exceptional power.
 
You’ll find authoritative coverage of topics ranging from drawing to memory, and threading to compute shaders. The author especially shows how to handle tasks such as synchronization, scheduling, and memory management that are now the developer’s responsibility.
 
Vulkan™ Programming Guide introduces powerful 3D development techniques for fields ranging from video games to medical imaging, and state-of-the-art approaches to solving challenging scientific compute problems. Whether you’re upgrading from OpenGL or moving to open-standard graphics APIs for the first time, this guide will help you get the results and performance you’re looking for.
 
Coverage includes
Extensively tested code examples to demonstrate Vulkan’s capabilities and show how it differs from OpenGL
Expert guidance on getting started and working with Vulkan’s new memory system
Thorough discussion of queues, commands, moving data, and presentation
Full explanations of the SPIR-V binary shading language and compute/graphics pipelines
Detailed discussions of drawing commands, geometry and fragment processing, synchronization primitives, and reading Vulkan data into applications
A complete case study application: deferred rendering using complex multi-pass architecture and multiple processing queues
Appendixes presenting Vulkan functions and SPIR-V opcodes, as well as a complete Vulkan glossary



In stock on November 9, 2016:

https://www.amazon.com/Vulkan-Programming-Guide-Official-Learning/dp/0134464540/

17
Intrinsic is a Vulkan based cross-platform game and rendering engine. The project is currently in an early stage of development but evolves rapidly from day to day.

Intrinsic is currently available for Windows only.

Links:

- Intrinsic homepage
- Intrinsic source code @ github

18
Quote
In this post, we’re going to learn how to procedurally generate 2D space scenes like this one:


Links:

- Procedural Generation of 2D Space Scenes in WebGL
- WebGL Space Scene Generator

19
3D-Tech News Around The Web / EVGA GTX 1070/1080 Overheating Issues
« on: October 24, 2016, 05:54:13 PM »
Quote
So it seems like the EVGA series have got a hotspot, which reaches over 100 °C around the VRAM/VRM area (micron vram only allows up to~95°C). This leads to either the weird black screen bug or to combustion of certain modules around the area.

- Word of warning: The EVGA 1080 blackscreen/fan bug is based on a hotspot, which pretty much affects their whole pascal line @ reddit
- EVGA 1080 FTW Thermal imaging might explain black screen issues @ reddit
- Caution: EVGA 1070 and 1080 series cards may have a hardware fault  @ reddit

- Tom's Hardware test of the GTX 1080 FTW with FurMark


- EVGA reply on EVGA forums
Quote
“The test used in the referenced review from Toms Hardware (Germany) is running under Furmark, an extreme usage case, as most overclockers know. We believe this is a good approach to have some idea about the graphics card limit, and the thermal performance under the worst case scenario. EVGA has performed a similar qualification test during the design process, at a higher ambient temperature (30C in chamber) with a thermal coupler probe directly contacting the key components and after the Toms Hardware (Germany) review, we have retested this again. The results in both tests show the temperature of PWM and memory is within the spec tolerance under the same stress test, and is working as originally designed with no issues.
 
With this being said, EVGA understands that lower temperatures are preferred by reviewers and customers.
 
During our recent testing, we have applied additional thermal pads between the backplate and the PCB and between the baseplate and the heatsink fins, with the results shown below. We will offer these optional thermal pads free of charge to EVGA owners who want to have a lower temperature. These thermal pads will be ready soon; and customers can request them on Monday, October 24th, 2016.  Also, we will work with Toms Hardware to do a retest.”
 
Thanks,
EVGA

EVGA GeForce GTX 1080 FTW running FurMark with thermal pad mod (30C Ambient in Chamber) – October 21st, 2016



A damaged GTX 1070 FTW:







20
3D-Tech News Around The Web / AMD's Raja Koduri Interview about GPUOpen
« on: October 24, 2016, 05:34:37 PM »
Quote
This bleeds into GPUOpen. AMD wants to assist developers in taking (some of) the reins for game-GPU optimization. Asked for an introduction to GPUOpen, Koduri told us:

“To get the best performance out of the GPU, the best practices, the best techniques to render shadows, do lighting, draw trees, whatever – there are different ways to do that. But what is the best way to do that? We figured out that that value add kind of moves into engines. It's basically in the game engines, and the games themselves, have to figure out [optimal techniques with new APIs]. They have to do more heavy lifting, figuring out what's the most optimal thing to do.

“The drivers themselves have become very thin. I can't do something super special inside the driver to work around a game's inefficiency and make it better. And we used to do that in Dx11 and before, where when we focus on a particular game and we find that the game isn't doing the most efficient thing for our hardware, we used to have application profiles for each application. You could exactly draw the same thing if you change the particular shaders that they have to something else. We did manual optimization in the drivers. With these low overhead APIs, we can't actually – we don't touch anything, it's just the API, whatever the game passes, it goes to the hardware. There's nothing that we do.

“We have a lot of knowledge in optimization inside AMD, and so do our competitors, so how do we get all of that knowledge easily accessible to the game developers? We have lots of interesting libraries and tools inside AMD. Let's make it accessible to everyone. Let's invite developers to contribute as well, and build this ecosystem of libraries, middleware, tools, and all, that are completely open and would work on not just AMD hardware, but on other people's hardware. The goal is to make every game and every VR experience get the best out of the hardware. We started this portal with that vision and goal, and we had a huge collection of libraries that we [put out]. It's got good traction. It also became a good portal for developers to share best practices. Recently we had nice blogs [...] sharing their techniques and all. More often than not, these blogs have links to source code as well.”

...

The GPU is a black box for 20 years now. A black box abstracted by very thick APIs, very thick runtimes, very thick voodoo magic. We are trying to get the voodoo magic out of the GPU software stack, and we believe there – there is still voodoo magic in transistors and how we assemble them, and in game engines, compute engines, libraries, the middleware. Voodoo magic in the driver middle-layers is not beneficial to anybody, because it's preventing the widepsread adoption of GPUs.

Links:

- Raja Koduri: 'Game Developers Have More Juice Than They Take Advantage Of'
- AMD's Raja Koduri on Dx12 Performance, GPUOpen, Moore's Law @ Youtube

Pages: [1] 2 3 ... 34