Describe what you’re doing (specifically), what problems you’re having with it, and what you have tried to resolve the problem and the results, and I’ll bet someone here will chime in with some ideas for you to try. Post a code snippet to increase your chances of a useful reply.
For tips in constructing your post to maximize the chance of useful feedback, please see The Forum Posting Guidelines. In particular, Posting Guidelines #4 and #5.
Hi
Currently we are using sdl application for scrolling large tiff files (1 bit depth) with a resolution ranging from 1000 dpi to 2000 dpi approximately image width 51840 and height 115200.
This we are doing using tile function i.e cropping the input image into smaller images of width and height 540 X 1080 size and the scrolling them parallel in a matrix format on a row by row basis…however there is a minor stuttering observed while doing so…we have observed that the scrolling is not being done uniformly across all the rows in a consistent fashion, the scrolling velocity in fps remains inconsistent across different rows i.e out of 10 rows 5 rows give an inconsistent performance.
We have tried using vsync, hardware acceleration, software acceleration etc but the problem is still persistent.
Image information
Image DPI - 1000 dpi and 2000 dpi
Image width and height = Width - 51840 and Height - 115200
Image size in MB - 711 MB.
Cropped image are = Width and height 540 and 1080.
The system configuration is :
Intel core i5 7th generation processor, 8 gb ddr4 ram, windows 8.1 os and 2gb nvidia graphic card ( recently added ) and a lcd monitor with 60hz frequency.
Even after trying with hardware acceleration on a gpu there seems to be no change in scrolling, we are still not sure if the graphic card is being utilized or not.
Also i am attaching the source code which were using that using SDL 2.0. i hope openGL will fix the issue. any solution in openGL.
I can’t able to attache the source code here and also link to source.
Ok, so 5.6 Gtexels for 1 image. 695 MB, if it can be kept bit-packed at 8 texels per byte.
Ok.
Questions:
Have you run a CPU profiler on this to see where you’re bottlenecked?
Do you have the entire 51840 x 115200 texel image pre-loaded into CPU RAM before scrolling, or are you doing run-time disk paging to progressively load parts of the image while scrolling?
Do you have the entire 51840 x 115200 texel image pre-loaded into GPU RAM before scrolling, or are you doing run-time GPU paging to progressively load parts of the image while scrolling?
What GL internal texture format are you using for the 540 x 1080 sub-regions.
How (and where in your program) are you
a) creating the textures backing each sub-region of the image
b) updating the contents of those sub-regions during scrolling?
The key to fixing this is profiling to find your largest bottleneck that’s causing the stuttering while scrolling. That’s what you need to do first. Then you can eliminate that bottleneck.
Which one?
If you’re bottlenecked on the CPU, you could throw a top-of-the-line GPU at this and it’s not going to fix the problem. You need to profile to identify the primary bottleneck driving the stuttering during scrolling. My guess is that’s going to be either disk paging or inefficiencies with way GPU paging is being performed.
You run a CPU profiler on your entire application. That tells you where you’re spending the bulk of your time (on the CPU). Be sure to profile when you’re scrolling heavily to exercise the code paths with the bottleneck(s) in them.
You need to look at the available CPU profiling options on your platform, pick one, and learn to use it.
Then it’s very likely (given that it doesn’t sound like you’ve even started profiling yet) that your main bottleneck is with disk loading of the image into RAM. This has nothing to do with OpenGL, graphics drivers, or the GPU.
If you’re loading from disk on the same thread that you’re using for OpenGL rendering, then it is almost definitely the bottleneck. I’ve seen production systems designed and implemented with disk loading on the draw thread, and this fails miserably when they start trying to achieve consistent frame rates.
Step #1: Run a CPU profiler on your app. A CPU profiler will reveal where you are spending all your time. If it’s loading from disk, it will reveal that.
Ok, well you need to know (or figure out) what your application is doing. If you don’t, you can’t optimize it.
Step #1 is to run a CPU profiler on your app. If it reveals that the bottleneck is related to OpenGL, and that prompts a specific OpenGL question, feel free to post it here. If it reveals that the bottleneck isn’t related to OpenGL, you need to go solve that first.
Answering my question about what GL internal texture format you’re using doesn’t involve posting any code. You need to get into that code and figure it out. But in the future, you can post code by copy-pasting it between lines with only 3 back-ticks on them (```). For example :
And in your application, you can print out the values of GL_RENDERER and GL_VERSION to verify that you are connected to the correct GPU through the same graphics driver.
However, this is really academic at this point. Step #1 is to run a CPU profiler to determine your bottlenecks when scrolling. Be sure to profile across frames when you are scrolling heavily to capture those bottlenecks. You might also consider snapping some timers around major parts of your CPU frames (especially disk loading) and logging them to catch when one part pops up and takes hundreds of milliseconds.
I am checking with visual studio profiler. will update you once done.
I am using SDL application only not using openGL, i have posted the query in SDL forum NO response form them, so i thought i could have get solution in openGL forum changing SDL application to openGL.
I will check the GPU part using the software which you shared the link.
And many thanks for the revert. Appreciate your patience and time.
I did run CPU profiler on visual studio 2015 along with CPU and GPU usage
GPU (2gb memory Nvidia Ge-Force GT710) is using 99.9% of memory both at 400 and 100 pixel per second velocity. However results at 100 pixels speed is near perfect but becomes inconsistent on higher speeds.
CPU memory usage remains almost constant at around 50% during the whole operation. No major bottlenecks found when compared at different pixel speeds, but at higher speed scrolling tends to stutter at times or could be more visible at higher speed. Can you please have a look at our codes and see if you can find something.
Also, since this is my first project on sdl, I am not quiet sure either about preloading or paging of images. Currently I have simply tried using cropping to 540 x 1080 pixels and tiling of large tiff file based on inputs received from sdl forums, cant really say what is going-on underneath the specific functions.
Looking forward for your help. I am stuck on this since past 2-3 weeks and well passed deadline and in very bad shape as well.
if you want i can share the report in diagsession format.
Does GPU Shark report that you are evicting GPU memory. That is, under Tools → NVidia - GPU Memory Info, is the “Eviction count” or the amount of “Evicted memory” increasing at any time after starting your application.
If so, you’re overrunning GPU memory. This has very bad performance implications. When the driver runs out of GPU memory, your app stalls for a while in some random GL API call while the driver shuffles data off the GPU to make room for new data that your app (or some other app utilizing the GPU) has asked it to load.
No, no updates. You’re on your own with diagnosing this one. I’ve just provided you a few tips to help get you started in isolating the bottleneck(s). And so far I haven’t seen any smoking guns in what you posted (I’m not going to sift, profile, and fix your code for you though).
You obviously brought up a profiler on this, but didn’t expand the bullets where most of the CPU time is being spent. You also brought up GPU Shark, but didn’t say whether or not the “Evicted” numbers are changing at any time after you started your app.
As I said before, the first step is to determine where your program is spending most of its time. Then you can determine what you can do about it. Good luck! You can do this!