|
Malte Mundt(deleted)
04/07/2009 4:39 AM
post26168
|
Hi,
before I spend hours of searching in the labyrinth of F27, I try asking here. :-) A potential QNX partner (hardware
vendor) wants to develop a graphics driver for Photon. I guess he will do it for 6.3.2 and 6.4.
- Where is the Graphics DDK for 6.3.2? I guess it is 'somewhere' in the old Download Center?
- Where is the Graphics DDK for 6.4? It's not under 'Project Downloads' of this project...
Malte
|
|
|
|
|
|
Derek Leach
04/07/2009 4:49 AM
post26169
|
a very general reply ...
Yes, for 6.3.2, 'somewhere' in the old Download Center
http://www.qnx.com/download/group.html?programid=9380
There is no DDK for 6.4 per se, all the source relevant to build a devg will be posted to Foundry27. I suppose Wiki
pages will need to be created if there is not already a document on how to use the source.
-Derek
________________________________
From: Malte Mundt [mailto:community-noreply@qnx.com]
Sent: Tue 07/04/2009 4:39 AM
To: photon-graphics
Subject: Graphics Driver DDK
Hi,
before I spend hours of searching in the labyrinth of F27, I try asking here. :-) A potential QNX partner (hardware
vendor) wants to develop a graphics driver for Photon. I guess he will do it for 6.3.2 and 6.4.
- Where is the Graphics DDK for 6.3.2? I guess it is 'somewhere' in the old Download Center?
- Where is the Graphics DDK for 6.4? It's not under 'Project Downloads' of this project...
Malte
_______________________________________________
Photon microGUI
http://community.qnx.com/sf/go/post26168
|
|
|
|
|
|
Mike Gorchak
|
Re: RE: Graphics Driver DDK
|
|
Mike Gorchak
04/07/2009 4:59 AM
post26171
|
Re: RE: Graphics Driver DDK
BSP&drivers project have released sources of some graphics drivers and updated headers to build 6.4 graphics drivers,
recently I finish porting one of the my graphics driver to 6.4 graphics DDK framework. There is no source for libffb
only, but it is needed for me only :), since I prefer to recompile it with very aggressive optimization options, this
trick could speed up unaccelerated fallback functions almost twice comparing to default libffb.
|
|
|
|
|
|
Derek Leach
|
RE: RE: Graphics Driver DDK
|
|
Derek Leach
04/07/2009 5:00 AM
post26172
|
RE: RE: Graphics Driver DDK
How did you optimize the libffb, was it with assembler, or "smarter" C routines?
________________________________
From: Mike Gorchak [mailto:community-noreply@qnx.com]
Sent: Tue 07/04/2009 4:59 AM
To: photon-graphics
Subject: Re: RE: Graphics Driver DDK
BSP&drivers project have released sources of some graphics drivers and updated headers to build 6.4 graphics drivers,
recently I finish porting one of the my graphics driver to 6.4 graphics DDK framework. There is no source for libffb
only, but it is needed for me only :), since I prefer to recompile it with very aggressive optimization options, this
trick could speed up unaccelerated fallback functions almost twice comparing to default libffb.
_______________________________________________
Photon microGUI
http://community.qnx.com/sf/go/post26171
|
|
|
|
|
|
Mike Gorchak
|
Re: RE: RE: Graphics Driver DDK
|
|
Mike Gorchak
04/07/2009 5:09 AM
post26173
|
Re: RE: RE: Graphics Driver DDK
> How did you optimize the libffb, was it with assembler, or "smarter" C
> routines?
No, there is no any assembly optimizations, often GCC generates much faster code, than I could write. Some functions has
been completely rewritten, especially alpha-blending routines, ROPs, blitters, etc... to minimize data reading from
video memory, using larger memory blocks. And I use -O3 -funroll-all-loops with a lot of other specific gcc's
optimization options. One unfinished thing is rest: I can't touch MTRR registers under QNX to enable write-combine
caching of video memory region - this could speed up all graphics stuff.
|
|
|
|
|
|
Derek Leach
|
RE: RE: RE: Graphics Driver DDK
|
|
Derek Leach
04/07/2009 5:12 AM
post26174
|
RE: RE: RE: Graphics Driver DDK
Ah, in simple terms, for the memory block you do one 'large read' from the video memory, then use that memory block for
obtain/apply the alpha information, or even ROPs, then you do one 'large write' back to video memory, correct?
________________________________
From: Mike Gorchak [mailto:community-noreply@qnx.com]
Sent: Tue 07/04/2009 5:09 AM
To: photon-graphics
Subject: Re: RE: RE: Graphics Driver DDK
> How did you optimize the libffb, was it with assembler, or "smarter" C
> routines?
No, there is no any assembly optimizations, often GCC generates much faster code, than I could write. Some functions has
been completely rewritten, especially alpha-blending routines, ROPs, blitters, etc... to minimize data reading from
video memory, using larger memory blocks. And I use -O3 -funroll-all-loops with a lot of other specific gcc's
optimization options. One unfinished thing is rest: I can't touch MTRR registers under QNX to enable write-combine
caching of video memory region - this could speed up all graphics stuff.
_______________________________________________
Photon microGUI
http://community.qnx.com/sf/go/post26173
|
|
|
|
|
|
Mike Gorchak
|
Re: RE: RE: RE: Graphics Driver DDK
|
|
Mike Gorchak
04/07/2009 5:20 AM
post26175
|
Re: RE: RE: RE: Graphics Driver DDK
> Ah, in simple terms, for the memory block you do one 'large read' from the
> video memory, then use that memory block for obtain/apply the alpha
> information, or even ROPs, then you do one 'large write' back to video memory,
> correct?
In simple terms, yes, it is correct :) But I tried also to get rid of "universal" code, which could handle all
conditions and states in one function, like this done in libffb. One function for simple alpha blended rectangle, one
function for alpha+ROP, one for alpha+source/destination key, etc.
I did this in my Geode LX800 graphics driver, at 500MHz CPU clock SBC could play HDTV video content + additional complex
graphics output without any slowness.
|
|
|
|
|
|
Derek Leach
|
RE: RE: RE: RE: Graphics Driver DDK
|
|
Derek Leach
04/07/2009 5:27 AM
post26177
|
RE: RE: RE: RE: Graphics Driver DDK
very cool, very cool :)
________________________________
From: Mike Gorchak [mailto:community-noreply@qnx.com]
Sent: Tue 07/04/2009 5:20 AM
To: photon-graphics
Subject: Re: RE: RE: RE: Graphics Driver DDK
> Ah, in simple terms, for the memory block you do one 'large read' from the
> video memory, then use that memory block for obtain/apply the alpha
> information, or even ROPs, then you do one 'large write' back to video memory,
> correct?
In simple terms, yes, it is correct :) But I tried also to get rid of "universal" code, which could handle all
conditions and states in one function, like this done in libffb. One function for simple alpha blended rectangle, one
function for alpha+ROP, one for alpha+source/destination key, etc.
I did this in my Geode LX800 graphics driver, at 500MHz CPU clock SBC could play HDTV video content + additional complex
graphics output without any slowness.
_______________________________________________
Photon microGUI
http://community.qnx.com/sf/go/post26175
|
|
|
|
|
|
