Hi rtfss!Some questions about VAAPI, VDPAU, XbVA?
Yes, there was a serios bug around BGRA/RGBA formats. I don't know why
it works on Windows 7 32-bit.
There fixed and slightly optimized demo demo (actually I further
optimize it as much as possible):
http://rapidshare.de/files/49006316/oit_dx11.zip.html
If it works, please let me know, and I re-upload it for public
community as soon as possible.
• GL_ARB_draw_buffersA opengl document for tegra says has this NV nice OpenGL extensions:
• GL_ARB_half_float_pixel
• GL_EXT_packed_float
• GL_EXT_texture_array
• GL_EXT_texture_compression_latc
• GL_EXT_texture_filter_anisotropic
• GL_OES_compressed_ETC1_RGB8_texture
• GL_OES_EGL_image
• GL_OES_fbo_render_mipmap
• GL_OES_shader_binary
o (Indicated by the value of GL_NUM_SHADER_BINARY_FORMATS being nonzero).
Indicates that the implementation supports precompiled binary shaders. All of the
demos use this capability on Tegra. See the nv_shader helper library for details
• GL_OES_texture_float
• GL_OES_vertex_half_float
• GL_EXT_texture_compression_dxt1
o The implementation supports specifying textures with the
GL_COMPRESSED_RGB[A]_S3TC_DXT1_EXT formats. Not exported on Tegra, but
supported
• GL_EXT_texture_compression_s3tc
o The implementation supports specifying textures with the
GL_COMPRESSED_RGBA_S3TC_DXT[1,3,5]_EXT formats.
• GL_OES_framebuffer_object
o (Required extension.) Framebuffer objects are supported. Not exported as an extension
string on Tegra, but supported
• GL_OES_mapbuffer
o The implementation supports the glMapBufferOES and glUnmapBufferOES
functions. These are exported directly and do not need to be queried.
• GL_OES_rgb8_rgba8
o The implementation supports GL_RGBA8_OES and GL_RGB8_OES as FBO color
buffer formats.
• GL_OES_stencil8
o Indicates that the implementation can support an 8-bit stencil buffer for render targets.
Not exported as an extension string on Tegra, but supported.
• GL_OES_texture_half_float
What's New in Version 1.53
* Support for Microsoft DirectX 11.
* Support for Catalyst™ driver 9.9-9.12.
* Support for ATI Radeon™ HD 5870 graphics cards.
* Support for ATI Radeon™ HD 5770 graphics cards.
* Fixed support for IL disassembly.
* Fixed issue with simple GLSL shaders.
What's New in Version 1.53
* Support for Microsoft DirectX 11.
* Support for Catalyst™ driver 9.9-9.12.
* Support for ATI Radeon™ HD 5870 graphics cards.
* Support for ATI Radeon™ HD 5770 graphics cards.
* Fixed support for IL disassembly.
* Fixed issue with simple GLSL shaders.
N-Queen Solver for OpenCL
I rewrote my old n-Queen solver from CUDA into OpenCL. It's not a port, because I rewrite everything from scratch (only the idea remains the same). I was hoping to use OpenCL for comparison between AMD and NVIDIA hardwares.
Unfortunately, for some reason, AMD's OpenCL compiler crashed when compiling my kernel for GPU (it's ok for CPU version though). So right now it doesn't work on AMD's GPU at all, but with AMD Stream SDK 2.0 it's possible to run on CPU devices.
Both source and executable are provided in the attachment.
The arguments are:
nqueen_cl -cpu -clcpu -p -thread # -platform # -local N
-cpu: use CPU implementation (single threaded)
-clcpu: use OpenCL CPU devices
-p: enable profiling
-thread #: set the number of threads. (default: max work group item number * number of devices)
-platform #: select a platform (default: select platform 0)
-local: use local memory (shared memory) for arrays. This runs faster on NVIDIA's GPU because NVIDIA GPU have no indexed registers.
N: the board size (1 ~ 32)
Note: large board size (> 20) takes forever to run (I estimate that 20 queen would take more than 2 hours to run on 9800GT).
The N-queen algorithm is a straightforward one. There is no special considerations to avoid redundant boards (i.e. most boards can be mirrored and rotated to create 8 solutions). Only a simple mirror reduction is used.
Running on my computer (Core 2 Duo E8400 3.0GHz):
16 queen -cpu: 7.27 s
16 queen -clcpu: 3.79 s
On GPU (GeForce 9800GT):
16 queen: 2.36 s
16 queen -local: 1.23 s
About the crash problem: the original kernel I've developed (i.e. the kernel used by clcpu path) doesn't crash the compiler. However, it's extremely slow (> 20 s for 16 queen on my 4850, and > 7s on 9800GT) because it uses a four arrays to simulate a stack for recursion. These arrays are good for CPU version because they reduce the amount of computation, but for GPU they are too hard on registers. So I developed another kernel which uses only one array, but it requires more computation to generate/restore data for each steps. However, this new kernel crashes the compiler (it works when selecting CPU devices, but it's slower). I'm using Cat 9.12 hotfix right now.
Attached Files
File Type: rar nqueen_cl.rar (11.4 KB, 4 views)
File Type: rar nqueen_cl_src.rar (17.9 KB, 4 views)
NVIDIA GeForce GTX 395 Specs :
- Codename "GF104".
- Dual Core GPU Design (Two GF100 "Fermi" Cores).
- 6.4 Billion Transistors In Total (TSMC 40nm Process).
- 32 Streaming Multiprocessors (SM).
- Each SM has 2x16-wide groups of Scalar ALUs (IEEE754-2008; FP32 and FP64 FMA).
- The 32 SMs Have 1536KB Shared L2 Cache.
- 1024 Stream Processors (1-way Scalar ALUs) at 1350MHz.
- 1024 ALUs In Total.
- 1024 FP32 FMA Ops/Clock.
- 512 FP64 FMA Ops/Clock.
- Single Precision (SP; FP32) FMA Rate : 2.76 Tflops.
- Double Precision (DP; FP64) FMA Rate : 1.38 Tflops.
- 256 Texture Address Units (TA).
- 256 Texture Filtering Units (TF).
- INT8 Bilinear Texel Rate : 153.6 Gtexels/s
- FP16 Bilinear Texel Rate : 76.8 Gtexels/s
- 80 Raster Operation Units (ROPs).
- ROP Rate : 48 Gpixels
- 600MHz Core.
- 640bit (2x320bit) Memory Subsystem.
- 4200 MHz Memory Clock.
- 336 GB/s Memory Bandwidth.
- 2560MB (1280MB Effective) GDDR5 Memory.
- New Cooling Design.
- High Power Consumption.
GTX395 is 60% faster than GTX380
GTX395 is 70% faster than HD5970
Release Date : May 2010, Price : 499-549 USD.