I am interested in a way how to read GPU temperature (graphics processing unit, main chip of graphic card), by using some video card driver API?
Everyone knows that there two different chip manufacturers (popular ones, at least) - ATI and nVIDIA - so there are two different kinds of drivers to read temperature from. I'm interested in learning how to do it for each different card driver.
Language in question is irrelevant - it could be C/C++, .NET platform, Java, but let's say that .NET is preferred.
Anyone been doing this before?
For nVidia you would use nvcpl.dll.
Here's the documentation:
http://developer.download.nvidia.com/SDK/9.5/Samples/DEMOS/common/src/NvCpl/docs/NVControlPanel_API.pdf
I found this: AMD Display Library SDK (ADL for short). That covers ATI cards.
http://developer.amd.com/display-library-adl-sdk/
Link to the original page, via Wayback Machine:
http://web.archive.org/web/20101103020811/http://developer.amd.com/gpu/adlsdk/Pages/default.aspx
Related
I'm running Android Things on a Raspberry Pi 3 Model B. I want to read NFC Tags, is it possible to do this? I've got like zero hardware knowledge about this stuff. All I know is how to write the necessary code.
A Raspberry Pi (or the other Dev kit) does not have NFC hardware. If you want to read NFC tags you need to get some hardware.
In addition to that, there is not user space driver for NFC, so you'd need to read it using a driver.
I only know of 2 chips that are sort of supported, both drivers are very limited. In fact, the simplest way to get them to work is to plug then into an Arduino and then communicate with the Arduino either using UART or I2C.
The best supported chip is RC-522. It reads mifare, but not sure how many other formats. You have a driver ported from arduino here: http://github.com/Galarzaa90/android-things-rc522
One of the important limitations is that it does not support card emulation.
I've had success with the ACR122U running over USB. It supports Mifare.
I'm trying to record timing video from a Thorlabs DCC cmos 1280x1024 with a code in Matlab but Matlab don't recognize it as a video device in imaqhwinfo,
a=imaqhwinfo('winvideo',1) command.
How can I fix it?
It's not supported hardware, see the Supported Hardware page.
Your options are to either request for your hardware to be added to the supported hardware list (if you're prepared to wait a few years...) or use the adaptor kit to write a communication layer between the Image Acquisition Toolbox acquisition engine and the third-party SDK and drivers for your hardware. However, this is a very advanced manoeuvre for experienced users and requires extensive knowledge of the hardware vendor's SDK (and is not something I can help you with).
I have seen many smartphones coming with hardware accelerated video decoding supporting mpeg2 and h264, but unlike in desktop and laptop systems, it is not clear to me how to interact with the hardware acceleration.
For desktops/laptops there is DXVA, VDPAU and OpenMax.
Is any of those supported in Mobile phones? I think OpenMax is, but I am not sure of how widely supported it is.
Is anyone familiar with what is usually used to write hardware accelerated media players and decoders for platforms like Snapdragon, Tegra 2 or Omap 4 running Android or Windows Phone?
I know that ffmpeg can be compiled for arm and I wonder what kind of hardware video acceleration it supports on that platform.
For ARMs, these are going to be vendor specific based on the silicon. I've seen some offer speedups by integrating subsets of the video decoding algorithms in hardware and you need to set up special registers to point to the data, flip a bit to go and wait for the output.
I think the majority of these though are going to be APIs to whatever embedded GPU is being used (Nvidia's Tegra, PowerVR SGX). I don't know a whole lot more about these, because they usually require NDAs and all you get is a header file and a ELF binary.
OpenGL ES seems to be supported pretty much everywhere.
What is the Direct3D? It is an API, is not it? Is it implemented by Windows or by graphics cards?
If the graphics cards implement the Direct3D API, why can not other operating systems use Direct3D resources from the graphics card?
If Direct3D is implemented by Windows, it has to use graphics card resources, such as OpenGL or OpenCL. If Direct3D calls are not directly to the graphics card, it would be slower due to intermediate calls.
Please, help me to understand what the Direct3D is.
What is the Direct3D? It is an API, is
not it? Is it implemented by Windows
or by graphics cards?
Yes, Direct3D is an API. It is implemented (mostly) by Windows itself. However, Windows will offload a considerable part of the actual work to the drivers of the graphics card and ultimately to the gfx card itself, so one can also say that a gfx card "implements" D3D.
If the graphics cards implement the
Direct3D API, why can not other
operating systems use Direct3D
resources from the graphics card?
They can, and they do, but only a relatively small (but often critical part) of D3D functionality is implemented directly by the card's hardware, so a lot more work in software is required to implement D3D.
If Direct3D is implemented by Windows,
it has to use graphics card resources,
such as OpenGL or OpenCL.
No, that's a misunderstanding. OpenGL and OpenCL are also APIs, and only partially implemented by the gfx hardware (just like D3D). The gfx hardware usually has a (proprietary) "native" API, which is what the gfx drivers (both for D3D and OpenGL) use.
If Direct3D calls are not directly to
the graphics card, it would be slower
due to intermediate calls.
There are not necessarily any "intermediate calls" - the D3D driver uses the cards native API, as explained above.
Direct 3D is a graphics API created by Microsoft. Its similar in function to opengl. OpenGL is a competing 3D graphics API created as a open standard. D3D doesn't need OpenGL to function.
Card manufactorers decide which APIs they want to implement; most always include DirectX (which includes Direct3D) and possibly OpenGL.
There is indirection as it doesn't go directly to the card, the cards D3D in turn calls the drivers, but this typicially is insignificant.
Direct3D is an API developed by Microsoft designed to help developers render 3D graphics. OpenGL and Direct3D are two separate APIs, but they must both interface to the video card using the drivers developed by the companies who manufacture the video cards. Both APIs (Direct3D and OpenGL) must both go through the driver in order to access the video card, and their speeds are dependent upon their design and their implementation in the video card drivers.
OpenCL is something different -- it's designed to help developers write programs which perform general-purpose computing on the GPU (not just for graphics). OpenCL is comparable to CUDA, but the latter in only supported on NVIDIA cards. Using CUDA instead of OpenCL may have some advantages, depending on your target system, since NVIDIA can make new features available to the CUDA API before they are accepted into the OpenCL API. However, even OpenCL and CUDA must interface to the driver in order to get anything done on the GPU.
As you already know, Direct3D only works on Microsoft and on Wine (for the most part), but its structure as an API is vastly different from that of OpenGL. Direct3D makes use of structures and includes more OOP elements in its API, while OpenGL acts as a state machine, lacking any structures or OOP features. Direct3D can often progress a little faster than OpenGL in terms of the features which it claims to officially support in its API because it is not designed for maximum compatibility with a wide range of devices; on the other hand, OpenGL has typically exhibited more inertia when it has come to adopting new features because of the inherent difficulty in adding new features to its API (the Khronos Group is influenced heavily by the CAD industry as well as many others, so it must cater to a wide range of needs). The time it took for the Khronos Group to finally adopt asynchronous API calls in the OpenGL is testament to this fact, and caused many people to lose faith in OpenGL.
However, OpenGL is cross-platform, endorsed by Apple, and it works on all operating systems on which it is implemented. You can easily use it with many popular window toolkits (Qt, SDL, FreeGLUT, JogAmp, gtk, etc.) and have confidence that your application will compile on other operating systems if you wrote it properly. The OpenGL API, unlike Direct3D, is an open-source industry standard.
As far as performance goes, it's still debatable as to which one is faster: depending on how you structure your program or batch your calls, this could change. However, performance should not really be a consideration for which API you use unless you have tested your application and have evidence that the choice of API is the cause of your bottleneck.
From Wikipedia:
Direct3D is a Microsoft DirectX API
subsystem component. The aim of
Direct3D is to abstract the
communication between a graphics
application and the graphics hardware
drivers. It is presented like a thin
abstract layer at a level comparable
to GDI (see attached diagram).
Direct3D contains numerous features
that GDI lacks.
Direct3D is an Immediate mode graphics
API. It provides a low-level interface
to every video card 3D function
(transformations, clipping, lighting,
materials, textures, depth buffering
and so on). It also had a higher level
Retained mode component, that has now
been officially discontinued.
My company is trying to build a pcb with an obsolete xilinx fpga (XC3042A) which is part of the XC3000 series chips. Does anyone have any experience programming the data to the chip? I'm looking for what software, hardware, etc. people have used.
I have programmed old Xilinx chips (XC4010XL) using a custom built interface to the ISA bus.
I used Turbo-C on a DOS box and a home-made ISA card with '245 (bidir transceiver) and a 74LS74 (dual flip flop D) for strobe signals on a slave parallel configuration.
It is not difficult to implement the same using a parallel port, for instance.
You should be able to find the programming specs from the Xilinx website. They provide documentation on the different methods used in programming their FPGA. It should be in their AppNotes. They have several modes - typically slave serial or select map (parallel). That means some sort of SPI flash, or parallel flash, or JTAG.
If you look around, you may find schematics for a DIY programming cable too! You can also interface a small micro, say a 8-bit PIC to handle the programming specs while you design your own custom interface to it or interface it to a SD card or something else.
The current Xilinx tools and cables will program old parts.
The XC3000 series does not use the JTAG interface, so you can not use the Xilinx programmer to download your configuration.
You can do so by either using an external EPROM or an embedded processor to download the code.
Take a look at this applications note from Xilinx:
http://www.xilinx.com/support/documentation/application_notes/xapp090.pdf
For daisy chain:
http://www.xilinx.com/support/documentation/application_notes/xapp091.pdf
It describes the data format as well as signal info for downloading the configuration file to the FPGA.
You can use older version of the Xilinx programmer from their web site and configure the devices, I believe the last version of the xilinx supporting the 3000 series was version 8 but I am not sure.
Check out FTDI. You might be able to convince them to go with some updated hardware. It's currently $150 CAD for USB + FPGA, and $80 CAD extra if you bundle it with a Manual. Plus shipping.
It even supports the free web kit available from the Xilinx website.