Not yet available for Natty. TI said it should be releasing the new
packages in a few weeks.
> I would also be interested in doing kernel development, but I can't
> find where the 2.6.38 Natty kernel work is taking place. Ubuntu's ti-
> omap4 branch doesn't have any recent changes and the new work in TI's
> repos seems to be on 2.6.35. Is the community mostly focused on
> Android or am I looking in the wrong place?
Check http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4
Cheers,
--
Ricardo Salveti de Araujo
That link seems to be broken.
Regarding video, I'm sure the OP is not the only one confused. Would
it be possible for someone knowledgeable to give us a birds-eye view
of the situation? An article for the wiki perhaps. The discussion
here is usually focused on specific use cases, getting some feature
"X" to work, rumors/promises of impending code releases from TI, and
so on. Admittedly I haven't been following it all, but I wonder
1) What *are* the different layers between X11 and the hardware
nowadays, including stuff needed for accel video decode and accel
graphics? It all used to be so simple...
2) Which pieces are available to hobbyists (in binary or source code
form), and which are not?
3) Which IP is owned by Imagination Tech. and which is owned by TI?
And what do either stand to gain by *not* giving it away for free?
(Ok, not really expecting an answer to the last part :)
4) Put this into the larger context of the PowerVR / Linux train wreck
(compare/contrast with the Intel GMA500 experience) and unpack it for
us. Should we expect a different outcome? Why or why not?
5) Is it likely that TI + the community will arrive at a solution
which enables long-term support (including video decode and graphics
acceleration) in the relevant upstream projects? Or is this likely to
be another case of "get this version of the kernel, this version of X,
this version of ..." with support forever tethered to legacy
packages?
In short, could someone explain to me, in a few well-written
paragraphs, why video support on Pandaboard is different from the
equivalent functionality on my Intel desktop PC?
(Reading over this, it seems a bit accusatory. Sorry. I'm not trying
to assign blame at all, just being frank in the hopes of a similarly
frank reply. I don't expect the corporate contributors here to share
my "world view," but I am honestly curious about theirs.)
4) Put this into the larger context of the PowerVR / Linux train wreck
(compare/contrast with the Intel GMA500 experience) and unpack it for
us. Should we expect a different outcome? Why or why not?
not sure i understand what the question is
The ducati firmware (.xem3 files) would not need to be recompiled for
a9 side to use hardfp.. you aren't directly calling code on m3 side
from a9, but instead there is an RPC layer that turns the call into a
message to the other side.. so the two sides could even be using
completely different instruction sets (such as dsp vs a9)... And
anyways, m3 doesn't have vfp/neon.
And yes, ducati (or more precisely ivahd, managed by ducati) is used
both for video encode and decode. Muxing/demuxing and those sorts of
mm framework layer stuff happens on the a9 side, but the heavy lifting
for decoding/encoding a bitstream are on ivahd/ducati.
BR,
-R
does the sgx API use floating point at all? if not, why does hard
vs soft fp calling convention matter?
> Questions: Given the discussion above, are there hardfp blobs for
> Ducati M3 instead which might address the problem and which could be
> invoked in GST via OpenMax? And is Ducati used for video encode
> (sourcing of an RTP/HTTP stream) as well as decoding? Thanks again.
The ducati "blobs" run on the M3s which are fixed point only...
SGX demos from OGLES2 SDK from Imagination Technology all run great
with 2.6.35 kernel from TI's Ubuntu repo, as previously reported.
The demos work with the MeeGo 1.1 userland as well as the Ubuntu
10.10.
Vladimir Pantelic
> does the sgx API use floating point at all?
Someone who has the source code may know for sure . . . I agree
that it wouldn't make too much sense for the GPU (or DSP, or Ducati)
to use the NEON instruction set of the FPU. However, that doesn't
mean that those drivers will work both with libraries compiled with
-hardfp as they do with drivers compiled with -softfp.
> if not, why does hard vs soft fp calling convention matter?
TI's response that they will make pvr_omap drivers available for Natty
in a few months that are compiled with -hardfp suggests to me that
there's more to solving the problem than "make clean; make -hardfp."
--
Alison Chaiken
(650) 279-5600 (cell)
http://www.exerciseforthereader.org/
A career in Silicon Valley is just like a chess game, only players can
move all the pieces every turn and some of the pawns bite.