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:
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.
actually, nvflash utility is NVIDIA software or third party software?
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.
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
Change log for October 25, 2016 Vulkan 1.0.32 spec update:
* Bump API patch number and header version number to 32 for this update.
* Add automatic visibility operations to the presentation engineE when
doing a queue present in flink:vkAcquireNextImageKHR. Removed all
references to MEMORY_READ that referenced WSI - they no longer make
sense (some aspects of public issues 128, 131, 132, 261, and 298).
* Document valid non-boolean +externsync+ attribute values for <param>
tags in +vk.xml+ (public issue 265).
* Add valid usage to slink:VkImageCreateInfo requiring that
pname:arrayLayers be 1 for images of type ename:VK_IMAGE_TYPE_3D
(public issue 319).
* Add missing captions to figures in the <<textures,Image Operations>>
chapter (public issue 334).
* Clarify WSI interaction with exclusive sharing mode (public issue
* Added explicit language clarifying the allowed queue usage of
resources created with ename:VK_SHARING_MODE_CONCURRENT (public
* Require that the
slink:VkDescriptorSetLayoutCreateInfo::pname:binding members of the
pname:pBindings array passed to
flink:vkDescriptorSetLayoutCreateInfo all be distinct (public issue
* Remove empty validity blocks from +vk.xml+ and suppressed broken
validity statements and added missing statements to explicit
validity. Doesn't affect output, other than some statements
appearing in another block now (internal issue 513).
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.
“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.”
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.
I just "upgraded" our home network with a Pi-Hole, an interesting project that implements a DNS server with a known-list of ad- and privacy trackers. The result is that everyone on your network that uses that DNS server gets an adblocker for free, without configuration work.
For those looking for some in-depth written explanation, I’ve also decided to write a series of blog posts that should hopefully shed some light on the basics of using SG’s in rendering. The first post provides background material by explaining common approaches to storing pre-computing lighting data in lightmaps and/or probes. The second post focuses on explaining the basics of Spherical Gaussians, and demonstrating some of their more useful properties. The third post explains how the various SG properties can be used to compute diffuse lighting from an SG light source. The fourth post goes even deeper and covers methods for approximating the specular contribution from an SG light source. The fifth post explores some approaches for using SG’s to create a compact approximation of a lighting environment, and compares the results with spherical harmonics. Finally, the sixth posts discusses features present in the the lightmap baking demo that we’ve released on GitHub.
- OpenSSH DSA key generation has been disabled by default. It is important to update OpenSSH keys prior to upgrading. Additionally, Protocol 1 support has been removed.
- OpenSSH has been updated to 7.2p2.
- Wireless support for 802.11n has been added.
- By default, the ifconfig( 8 ) utility will set the default regulatory domain to FCC on wireless interfaces. As a result, newly created wireless interfaces with default settings will have less chance to violate country-specific regulations.
- The svnlite( 1 ) utility has been updated to version 1.9.4.
- The libblacklist( 3 ) library and applications have been ported from the NetBSD Project.
- Support for the AArch64 (arm64) architecture has been added.
- Native graphics support has been added to the bhyve( 8 ) hypervisor.
- Broader wireless network driver support has been added.