« on: November 19, 2016, 02:38:52 PM »
Crimson 16.11.4 + Radeon RX 470 + Win10 64-bit
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.
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
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.