I ask you some link, web adress, or any other information to usage of Advanced Graphics (GF) 2D hardware accelerating HOW-TO or some trick.
Platform: x86, QNX 6.4 & GF on Intel ATOM w. 945 chipset, 1GB memory.
The task: move relatively big amount bitmaps, on this a lot of small (65x65px) PNG w. they alpha channel. It run in fullscreen mode, moreover need to drive a 16:9 LCD, not a “standard” 4:3. I studied the GF sample codes (e.g. vsync.c), and QNX internal Helps. They did not manage to attain rather fast velocity (11-12FPS). I try this under Photon w. double buffered OSContainer, the framerate was 4-6 FPS. I think, the hw acceleration not only ~3-4x faster than VESABIOS or Photon.
There was supposed to be a feature in Photon 2.0 which I never looked into. It was supposed to allow you to create an area that you had direct memory access to. I never looked into it, and I think it might have needed some hardware support.
What video mode are you in (number of colors?) and what method are you using to put the images on the screen?
For your question, I have tried the all possible modes but it seems to be the
RGB565 (64k color mode) can gives the best possible performace now.
The others are showed slower operations.
For me the ARGB8888 mode would be required due to transparency.
Now I have been using the gf_draw_blit2() function to put images onto the screen - with double buffering method.
The problems come into real when Alpha Blending operation is used. When it has been used, unfortunately the performance significantly degradated.
The driver’s documentation in the help system declares that this driver ( devg-gma9xx.so ) supports the Alpha Blending.
I am affraid somehow I cannot initialize properly or somehow I cannot use this feature. I have tried to increase the priority of io-display but there was no any changes therefore the root of problems is not there.
Maybe there is a special operational mode in QNX6.4?? It would be good to look into something source code where this feature operates properly…
Are you using multiple layers? or are you doing this all in the same layer? I think if you use multiple layers you’ll get the performance you are looking for. I’m guessing the hardware alpha blending acceleration used by the driver might be between hardware layers.
Yes, this time I am doing this all in the same layer in my sample application. I have also tried to increase the priority levels but the result was near the same frame per sec. value.
Thank you for your advice, I will rewrite it.
The problem is that there is no too much source code samples available.
With more layers new problems will come into play. For example, how could I clear very quickly these memory of new layers before rewrite it?
If I build and use new layers then maybe it will cause overheads again?
Furthermore, how could I store those relative small pictures (with alpha channel, .png file types) in the direct video memory to help the GPU’s shader 2D work in QNX NTO 6.4 ?
Can you advice to me with any kind of technical solution or where could I find some similar code samples?
Any kind of qnx specific advices are welcome…
Create PdOffscreenContext - height, width, RGB888, flags settings is important
Obtain the pointer to the OffscreenContext buffer
Direct you video/images to the buffer above
Create OSContainer
Create Window with parent OSContainer from 4
Create RawWidget with paretn the Window from 5
Create Damage Widget hadler for 6), where you call ContextBlit, blitting the context from 1 to the area of the RawWidet. This takes cae of the scaling as well
Now whenever you want to display your new image/frame, just transfer the image to the offscreen contex buffer and damage the RawWidget. You can easy move your window within the Photon Space.
With this scenario I have reached 30 fps with 1152X1152 frame with hardware driven by i830.s0
Cheers
A question for everybody: the AG sample code, “alphalayer.c” work on 6.4? I get error when try launch: “Failed to create alpha map surface”. I try to play with layers, drivers but no success.
The alphalayer code will only work on a piece of hardware which has a separate alpha layer. A chip such as the Fujitsu Coral/Carmine has a layer which can be used as an alpha layer (mask) for another layer.
Based on my reading you want to render a bunch of 32 bit per-pixel images as fast as possible with GF. Using Photon will work also but you will get the best performance with GF as it does not have to go through the widget library and the damage chain. If your images are 32 bit then you should create an ARGB8888 surface with GF and put the data there. If the hardware supports an ARGB8888 blit then you will need to make sure that the image data is in video memory, I am not 100% sure that the intel driver you talk about support a ARGB8888 blit. For this to work you can load the image directly into a video memory surface. Have a look at the sample code in img_decode_surface. This will show you how to allocate a GF surface and tell the loader to put the image data there. Now that you have a gf_surface_t with the image data in it you can blit the surface when you need to draw it, making sure to setup the per-pixel alpha. Also make sure that the target surface is in the same format otherwise a color conversion will occur and the hardware may not accelerate this. All in all to get the best performance you will need to do the following:
Create a Layer surface at ARGB8888 and attach to a layer
Load an image into a ARGB8888 surface (video memory)
Blit the image to the layer surface setting per-pixel alpha
You need to have both surfaces in the same format and in video memory if you want any chance of hardware acceleration.
I hope this helps, let me know if you are confused and I will write you some sample code for this,
Brian
Thank you, Brian. In the manual of devg-gma9xx.so driver read, it support hw. accelerated alpha-blending. I will rewrite few things in my test code to try it. Will be back…
I look little deeply to img_decode_surface.c When I pass a sample PNG w. alpha, the output w. -v switch:
Display 0:
Resolution: 1024X768
Refresh rate: 60
Pixel format: BGRA8888
Number of layers: 4
Main layer index: 0
Surface:
SID = 0
Flags = 284ff
surface is directly accessible
img is 1024x768x32
Press a key to exit
—
Picture show at {0,0}, but black fill around ball transparency. On the screen’s other place show the standard gray checkerboard.
I put this few line into original source around line ~108 (before read image) to try transparency:
{ gf_alpha_t alpha;
memset(&alpha, 0, sizeof alpha);
alpha.mode = GF_ALPHA_M1_SRC_PIXEL_ALPHA | GF_BLEND_SRC_M1 | GF_BLEND_DST_1mM1;
gf_context_set_alpha(setup.context, &alpha);
}, but transparency stay black on i945. I try devg-gma9xxx & devg-i830 too.
Thanks,
illes
Thanks for reply. I think, its the global alpha operation. I tried:
-In “standard”, one layer operation it give a constans transparency.
-In the GF sample ‘img_decode_surface’ no give transparency (this PNG need per pixel alpha)
Tried w. the 32bit test PNG, that attached in my previous post. In the manual of devg-gma9xx.so, read, it supported w. HW acceleration alpha blending. The one layer methods that work for me under Photon and GF, consume lot CPU. But it’s now true in 100%: the framerate stay low (4-5 FPS), but processor’s usage under animation fall back from ~99% to around ~70%. Another thing: when I tested in >2GHz QUAD Core, 2 core can’t use my application. the frame/sec increased 2-3 frame/sec into the test 1.6GHz Intel Atom CPU. When use Photon, it consume each core.
As I said flags in creating OffscreanContext are very important.
Try this in case using onboard video chipset:
flags = Pg_OSC_MEM_PAGE_ALIGN | Pg_OSC_MEM_HINT_CPU_READ | Pg_OSC_MEM_HINT_CPU_WRITE | Pg_OSC_MEM_SYS_ONLY
Try this in case using PCI{e} video card:
flags = Pg_OSC_MEM_2D_READABLE | Pg_OSC_MEM_2D_WRITABLE | Pg_SCALER_PROP_DRAW_TARGETABLE | Pg_OSC_MEM_PAGE_ALIGN | Pg_OSC_MEM_HINT_CPU_READ | Pg_OSC_MEM_HINT_CPU_WRITE
So I am not sure if your target is to use GF or Photon but here is more on the GF side. Try loading this with img_decode_simple and see if it renders properly. I tried it here on a vmware session and the image looks fine (under QNX 6.4). img_decode_simple will render with the FFB via software fallbacks. If this works and img_decode_surface does not (with the per-pixel flags) then it is possibly a bug in the driver code. Passing the GLOBAL option you mention will apply a global blend factor to the entire image and do nothing with per-pixel values.
koko: i tried as you suggest in my photon graphics test appl. The result’s was same, or too small difference. Tried change each usable driver modes.
Brian: My primary target to take a high quality animated graphics for a 40" LCD. It will be a large, wall-mount common display for a local, 12 PC’s system (this PC will be a MySQL/HTTP server too). I want to realize all task under QNX. The other 11 PC have a much smaller local monitors, smaller CPU, RAM, etc. Nice in this version the QNet. So… after this, I started to test graphics. No fix idea, Photon or GF - the result tell the exact answer - maybe this answer: “use other OS” ? I take two version of my graphics test, Photon and GF, separatelly. Naturally, the first choice is the GF.
Back to here: I tested w. PNG (attached above) each: img_decode_simple and img_decode_surface (w. per_pixel transp).
-the img_decode_simple rendered correctly: like in Photoshop or Picasa.
-the img_decode_surface fill w. black the transparent areas. Around the image visible the deeper layer’s grey checkerboard (in other words: layer2 stay transparent outside of 65x65px square, that contain the sample image.
Thank you so much:
illes
ps: the “alphalayer.c” also not render exactly in my HW.
Sounds like the alpha blit that the driver is doing is broken. If the img_decode_simple example works then the image is loaded properly and the FFB can render it. You may want to post a bug to QNX support about the hardware alpha with this driver. I will look to see if I have a machine with this chipset and try it here.