I'm converting pdf to images using a nodejs package: https://www.npmjs.com/package/pdf2images-multiple
This works successfully in docker on two different local machines which both have Graphic Cards. However when I try to run this on a server in Google Cloud (which does not have a GPU). The following error occurs for particular pdf pages that have graphs:
error: message=Failed to convert page to image, killed=false, code=1, signal=null, cmd=gm convert -density 150 -quality 100 -sharpen 0x1.0 -trim '/usr/src/app/1161115-30-1kabyqq.2bteimgqfr.pdf[7]' '/usr/src/app/pdfimages1161115-30-10uod6h.siy6pyzaor/1161115-30-1kabyqq-7.png', stdout=, stderr=gm convert: "gs" "-q" "-dBATCH" "-dMaxBitmap=50000000" "-dNOPAUSE" "-sDEVICE=pnmraw" "-dTextAlphaBits=4" "-dGraphicsAlphaBits=4" "-r150x150" "-dFirstPage=8" "-dLastPage=8" "-sOutputFile=/usr/src/app/gmxHC5iw" "--" "/usr/src/app/gm0tibSq" "-c" "quit" (child process quit due to signal 11).
gm convert: Postscript delegate failed (/usr/src/app/1161115-30-1kabyqq.2bteimgqfr.pdf).
I've created an AWS instance with a GPU and this error does not occur. Looking to see if there's an Environment Variable that would be able to skip the GPU variant in GhostScript at least until Google Cloud gets GPUs or some alternative that I'm not seeing here.
The command in the error message called GraphicsMagick has documentation saying it doesn't use any GPU techniques.
http://www.graphicsmagick.org/FAQ.html#are-there-any-plans-to-use-opencl-or-cuda-to-use-a-gpu
Ghostscript does not need, and indeed is not capable of using (beyond using X to display the bitmap) a GPU. There is some SIMD code, but you can compile without that, obviously I have no idea how the Ghostscript you are using was compiled.
For Linux, its often impossible to move a binary from one box to another, because the ABI differs between the two systems in terms of things like the C runtime. Also, if the executable has been compiled with shared libraries (many distributions insist on doing this) then differing versions of the shared libraries might cause problems.
My guess is that, rather than the presence or absence of a GPU, there is some significant difference between the Google Cloud Linux and the AWS Linux.
The best way to deploy Ghostscript on Linux is to build it from source on the machine you intend to use, this is especially true if you intend to put it on multiple machines with different configurations.
Related
I am testing around with EDK2 by Tianocore (https://github.com/tianocore/edk2) and I can build BIOS images as well as UEFI Applications and drivers but when it comes to building a UEFI capsule, I am not sure how to go about doing this.
https://uefi.org/sites/default/files/resources/UEFI%20Fall%202018%20Intel%20UEFI%20Capsules.pdf this points to some ideas but I am not sure the exact path to take here.
I see two possibilities:
https://github.com/tianocore/edk2/tree/master/FmpDevicePkg this is the package mentioned in the PDF link above and the PDF also mentions an integrated build pipeline for making a capsule. It also mentions a standalone python script which is option two.
https://github.com/tianocore/edk2/tree/c640186ec8aae6164123ee38de6409aed69eab12/BaseTools/Source/Python/GenFds there are standalone scripts to make these images and artifacts like capsules and headers at this location but I am unsure if these are intended to be used as is or only as a part of a larger build pipeline.
My end goal here is to produce a UEFI capsule and place UEFI drivers inside it as the payload so any tips or help would be appreciated.
Perhaps this question could be rephrased as 'what would happen if I were to try and run a Vulkan program on a cpu-only build'.
I'm wondering whether the program would run but not produce output, crash or not build in the first place (although I expect the building process to be for a cpu architecture instead of a gpu architecture).
Would it use the on-motherboard graphics to produce output? In that case, what would happen if the program was run on a cpu-only server?
Depends on how the program initialized vulkan.
Any build can have the vulkan loader installed this is the dynamically loaded library that finds the actual driver, if that is missing the program would be unable to load the loader and may either fail to start or show an error message, depending on how they try and load that.
If no device is available then the number of devices is 0. This is again up to the application to manage. Either by going for an alternative graphics API (opengl) or a error message and failing to start.
I have a project in which I am using a Raspberry Pi to print ticket to a thermal printer.
It is pretty much the same principle as in this video.
Tickets are generated from templates that may include text and images. Both text and images are dynamic, for example I may want to print the current time. I receive the template as a .psd from a designer and the thermal printer takes bitmap data. The Raspberry Pi communicates to the printer with a python library. Everything must be done locally as cloud access is not guaranteed. Performance is important.
I investigated several options:
Latex + ImageMagick
Webkit + Phantom.js
Pillow (Python Imaging Library), especially the module ImageDraw
The first option is not quite satisfying because Latex generates a pdf file and then ImageMagick is very slow to convert it to a .png.
The second option is seducing but if I am not mistaken, I would need to start a server locally.
The third option would be great because it will be pure python, but requires to build a basic typesetting system on top of PIL.
Has anyone been confronted to a similar problem ?
I am trying to figure out what a profile result means, before I start to optimize. I am very new with CUDA and profiling in general and I am confused by the result.
Specifically, I want to know what is happening during seemingly unoccupied chunks of computation. When I look from top to bottom at the CPU and GPU there appears to be nothing happening during large portions of the code. These look like columns with nothing in Thread1 and nothing in GeForce. Is this normal? Whats happening here?
The run was done a multicore machine under no load with nvprof. The GPU code was compiled with -arch=sm_20 -m32 -g -G for CUDA 5.
Larger Image
The error here was to profile the code in debug mode (-G compiler flag: "Generate debug information for device code"). The behavior of the program is deeply changed, and this should not be used to profile and optimize one's code.
One other thing: a thorough documentation of nvcc's debug mode is hard to find. nvcc probably dumps the registers/shared memory in global memory for easier host access and debugging, which may in turn hide problems such as race conditions in shared memory (cf. discussion here: https://stackoverflow.com/a/10726970/1043187). Thus, programs such as cuda-memcheck --tool racecheck should be used in release mode too.
I'm newbie in GPU programming , and i work on brute force RAR Password Recovery on ATI Stream Processor using brook+ language, but i see that the kernel written in brook+ language doesn't allow any calling to normal functions (except kernel functions) , my questions is :
1) how to use unrar.dll (to unrar archive files) API in this situation? and is this the only way to program RAR password recovery?
2) what about crack and ElcomSoft software that use GPU , how they work ?
3) what exactly the role for the function work inside GPU (ATI Stream processor or CUDA) in this program?
4) is nVidia/CUDA technology is easier/more flexible than ATI/brook+ language ?
1) unrar.dll is a compiled dynamic link library. These execute on the CPU. GPUs have vastly different machine code and a very different execution model, so they can't run dlls.
You could try to implement a callback from the GPU to the CPU via events, or build an x86 interpreter on the GPU, but these would almost certainly run slower than just running on the CPU.
Using unrar.dll is not the only way to program RAR password recovery. You could instead just build your own code for CPU and GPU from scratch.
2) They work by having the CPU code explicitly request that some GPU code run on the GPU.
3) I don't know exactly. I would guess though that it has a GPU program that tries many different combinations, and benefits from having these run in parallel.
4) CUDA is more mature than brook+. brook+ may be just as easy for simple tasks, but isn't as fully featured. For new projects most people would now choose OpenCL over brook+.
(I'm not sure what you're intending to do, but none of the above seems likely to enable anything sinister.)