[Most Recent Entries] [Calendar View]
Thursday, August 1st, 2013
| Time | Event |
| 2:00p | AMD Frame Pacing Explored: Catalyst 13.8 Brings Consistency to Crossfire In the continuing saga of AMD's efforts to improve their framerate consistency, back in March AMD set a deadline of this summer to deliver their first driver implementing advanced frame pacing for Crossfire. At long last the first phase of that driver has finally arrived today in the form of Catalyst 13.8. With the driver in hand, today we'll be taking a look at the performance of AMD's cards in Crossfire mode, evaluating the consistency of AMD's frame pacing approach, and looking at what AMD can further improve. Has AMD finally solved their multi-GPU frame pacing woes? Let's find out. |
| 3:00p | A Quick Look at the Moto X - Motorola's New Flagship Since being acquired by Google, there’s been a lot of speculation about what’s coming next from Motorola. Last week they announced their Droid lineup for Verizon, this week they’re ready to talk shop about the much-rumored, very-hyped Moto X. It’s official and we just were handed one at a Motorola event in New York City.Read on for our initial impressions and thoughts after some time with the device. |
| 6:00p | Happy 20th Birthday Second Reality
Every so often I get asked about what caused me to be interested in GPUs, and consequently how I ended up at AnandTech. The answer to either of those is something of a long story that I rarely go into, but in short it has a lot to do with the history of PC graphics itself, and in particular a very important and very historical piece of software: Second Reality. Consequently with today being the 20th birthday of Second Reality, I wanted to take a moment to wish its developers a happy birthday, and reminisce a bit on one of the most significant pieces of software in the history of PC graphics. Without rehashing what Wikipedia does better, Second Reality holds a very important place in the annals of the PC graphics industry. The PC was not always the graphics powerhouse it was today, and for many years in the 1980s and up to the early-to-mid 1990s that honor went to the much more graphically capable Commodore Amiga platform. But like the rest of the PC industry in general, the early 90s was a period of rapid improvement and PC graphics was no exception. Second Reality, a demoscene demo, holds the distinction of being one of the pieces of software that changed how the world viewed PCs, and in many ways marks the beginning of the PC being a serious platform for consumer graphics. So what is Second Reality? In a nutshell, it’s a compilation of code, graphics, art, and music. But it’s probably more meaningful to say that before “can it play Crysis?” was a thing, it was “can it run Second Reality?” Even more so than Crysis in 2007, in 1993 Second Reality greatly pushed the envelope for what could be done with PC graphics. Developed by the Finnish group The Future Crew, Second Reality pulled off effects previously only scene on the Amiga, demonstrated other effects that the Amiga couldn’t replicate, and demonstrated real time 3D years before consumer video cards gained 3D capabilities. Graphically it was impressive, and a lot of that impressiveness had to do with just how clever its various graphics hacks were. Real time raytracing, voxels, mesh deformation, plasma effects, vector balls, and of course 3D were all used to great effect in Second Reality, and all of which ran in software on a lowly 486. It was quite frankly the most graphically impressive thing you would see on a PC in 1993. And it ultimately set the stage for the PC to become the graphics powerhouse that it became later in the 1990s and beyond.
YouTube doesn’t really do Second Reality justice, but as it used a mix of 60Hz and 70Hz effects and non-square pixels it’s difficult to capture to video (hey, it was 1993) The developers of Second Reality ultimately went on to form various companies, most of which our long-time readers can recall. Remedy (Max Payne), Futuremark (benchmarks), and Biyboys Oy (graphics hardware, now owned by Qualcomm) can all trace their roots to the individuals responsible for Second Reality. As important as Second Reality was to proving the PC as a graphics powerhouse, it in some ways also laid the groundwork for future graphical advancements, which we continue to see the repercussions of today. As for myself? Well let’s just say that it’s hard not to be interested in 3D graphics after seeing Second Reality running at the local white box computer store. It sold computers, but to a fledgling nerd it also offered a glimpse of what could be done with real time PC graphics, forming a fascination that has lived on since. Ultimately we have of course long since surpassed what Second Reality can do. But even at 20 years old it still holds a very special place in the history of PC graphics, offering a watershed moment that has rarely been replicated since. |
| 6:15p | Android 4.3 update for Nexus 10 and 4 removes unofficial OpenCL drivers
We had previously reported that Android 4.2 firmwares for Nexus 10 and Nexus 4 were found to contain OpenCL drivers. The drivers were an internal implementation detail and not officially supported for use by developers, and we had mentioned that the drivers may be removed in future updates. Android 4.3 is now rolling out to these devices and OpenCL drivers are no longer present in the new update. OpenCL is an API for parallel and heterogeneous computing defined by Khronos, the same group that also stewards OpenGL. On the desktop and server side, AMD, Intel and Nvidia (and some others, such as Altera) support OpenCL on Windows and Linux. Apple in particular heavily pushes OpenCL on OSX and is providing drivers for latest version of OpenCL (1.2) in OSX Mavericks for all shipping Macs. Mobile hardware vendors including Qualcomm, ARM and Imagination Technologies tout OpenCL readiness for their hardware, but without shipping drivers on commercial devices, it is not possible to use OpenCL. Google is pushing their own proprietary solution called Renderscript on Android. At a very high level, Renderscript is to OpenCL as Java is to C+Assembly. Renderscript is meant to be portable to any Android device irrespective of underlying hardware and does not expose lower level details of the hardware to the programmer. For example, Renderscript does not allow the programmer to choose whether a particular piece of code should run on the CPU, GPU or DSP etc. Such decisions are taken automatically by the Renderscript driver provided on the Android device. Renderscript's approach promotes portability and ease of use but there maybe a (potentially large) performance cost compared to well-optimized code in a lower-level language. Renderscript Compute has some other shortcomings such as lack of interoperability with graphics and lack of support in the Android NDK. The lack of programmer control, associated potential performance costs and other limitations make it unsuitable for some applications such as high performance game engines. Renderscript should be fine for some applications such as some of the simpler image processing filter applications and indeed Google is promoting Filterscript, a subset of Renderscript, which particularly targets image processing type applications. OpenCL and Renderscript are largely complementary. OpenCL exposes more of the details of the hardware and can be a powerful tool in the hands of experienced programmers, but more power requires more responsibility on the part of the programmer. For example, OpenCL allows one to get really close to the hardware and it is possible to obtain close to peak performance if the programmer invests the effort in optimizing for the platform. However, code that is heavily optimized for one vendor's hardware may perform poorly on hardware from other vendors. Experienced developers typically therefore write multiple code versions with each optimized for different architectures, and provide a fallback code for platforms they do not know well. According to some unofficial comments from Google engineers, which I will clarify is not an official statement, Google's concern is that inexperienced developers may not use OpenCL's power properly. For example, developers may test and optimize code for only one hardware, and may not realize that the code performs poorly on others. Given the diversity of hardware in the Android world, Google is preferring Renderscript over OpenCL. I think Google would prefer consistent performance everywhere, even if it means not reaching the peak on any platform. My understanding is that the drivers were removed at Google's request, to promote Renderscript over OpenCL, though that is speculation and not an official word. It is a little unfortunate that Google appears uninterested in even providing OpenCL as an option, at least on Nexus devices where it (presumably) controls the firmware and the drivers shipped with the firmware. It remains to be seen whether Google will provide access to any low-level heterogeneous computing API in Android in the standard SDKs. I also wonder how Google will react to NVIDIA's quest to bring technologies like CUDA to the Android world given that Google appears to be entirely uninterested in allowing any parallel compute API except Renderscript. It is perfectly possible that device makers will ship OpenCL or alternate low-level solutions (like CUDA) as a differentiating factor on non-Nexus devices as hardware vendors often provide additional SDKs specific to their devices. Renderscript joins the ranks of existing parallel and heterogeneous computing technologies such as CUDA, OpenCL, C++ AMP, DirectCompute, OpenGL compute shaders, OpenACC and OpenMP 4.0 as yet another option for heterogeneous computing. Ultimately, each of the APIs has its own strengths and weaknesses. And much like other technical domains, such as programming languages, browser standards and graphics APIs, various parallel computing APIs are being driven by a mix of technical and business interests. Ultimately, there will be a consolidation but it is difficult currently to guess which APIs will remain in end. We will continue to watch how this space evolves.
|
| << Previous Day |
2013/08/01 [Calendar] |
Next Day >> |