Does anyone know why this seems to be impossible to get for us? I'm guessing Amd does not open source this part. But can't it be possible through some nda? Or maybe a money issue?
This is something i'd donate money for. Could mean a simple sam460 could playback full hd movies without problems.
Antique wrote: Does anyone know why this seems to be impossible to get for us? I'm guessing Amd does not open source this part. But can't it be possible through some nda? Or maybe a money issue?
AMD has said that they cannot open up the video decoder docs because the UVD block (Unified Video Decoder) is too intertwined with the HDCP digital rights management stuff, which itself is under NDA. They say that they have been working on separating these functions out in the last few chipset generations, but they still haven't released any documentation. Hopefully it will come some day.
Generally speaking, to get an NDA with a company for technical documentation requires convincing them that giving us the docs will make them a lot of money. This is because we'd be taking up their engineers' time with questions about any confusing and missing parts of the documentation. We're not really in the position to make them a lot of money.
However, all is not lost if they don't release the documentation. There is a VDPAU state tracker in the Gallium3D source tree, which is for GPU based video decoding. While I'd prefer to use the dedicated video decoder, a GPU based decoder should work too.
Deniil wrote: Yeah, this would be nice to have. Even the PA6T can't do 1080p h264 decoding, and not even 720p without overlay and some quality switches.
There are three things that would help with CPU based video decoding: - Textured video (overlay is obsolete) - GART for fast data transfer to/from VRAM (boosts the transfer rate from ~450 MiB/s to a theoretical 4 GiB/s on the A1-X1000, which is great for HD video) - Multi-core support (helps a lot with H.264 1080p decoding)
All of these are on the to-do lists. We'll get there eventually. Once these are in place, the PA6T will probably have the power to do H.264 1080p video decoding.
I'm guessing you will be the one working on these issues? Any way to help you get those fixed faster? And curoius about GART? What is that and what makes the transfer so much higher? Is the tranfer rate now on the x1000 at about 450MIB/s? Is this a bottleneck as in now?
And too bad we don't have the money to give amd so we could get those documents. That would probably mean in millions of euro. Wish i could win the lottery.
Quote:
There are three things that would help with CPU based video decoding: - Textured video (overlay is obsolete) - GART for fast data transfer to/from VRAM (boosts the transfer rate from ~450 MiB/s to a theoretical 4 GiB/s on the A1-X1000, which is great for HD video) - Multi-core support (helps a lot with H.264 1080p decoding)
All of these are on the to-do lists. We'll get there eventually. Once these are in place, the PA6T will probably have the power to do H.264 1080p video decoding.
I'm guessing you will be the one working on these issues?
It will take more than just me. Taking advantage of GART will require improvements to Picasso96, and video players such as DvPlayer and mplayer will need to be updated for textured video. I've already had discussions with other developers about these things.
Quote:
Any way to help you get those fixed faster?
Hmmm. I personally have limited time as I'm working on building my company. Since success there is critical for me, that is top priority. So, simply donating won't magically give me more time to work on it.
However, this isn't a one man show (see above). Right now I think that your best bet is to encourage those "sitting on the fence" to go out and get PCI-Express capable machines and/or Radeon HD cards (plus the latest drivers). That will provide more funds for development, which will help move things along. Plus, the more users we have the better. Of course, this will be a lot easier once the Warp3D drivers for Radeon HD 5xxx-6xxx cards are out.
Oh yeah, supporting DvPlayer is also worthwhile.
Quote:
And curoius about GART? What is that and what makes the transfer so much higher?
Graphics Address Remapping Table (GART) is a technique where main memory is mapped into the graphics card's internal address space next to VRAM. This allows the GPU to directly access data in main memory using DMA.
Quote:
Is the tranfer rate now on the x1000 at about 450MIB/s? Is this a bottleneck as in now?
Yes, that is roughly the current limit. This is because the only way to achieve fast and efficient transfers across PCI/PCIe is to transfer large blocks of data at a time.** Using DMA is the only way to make this happen. DMA also has the advantage that the CPU isn't involved and can, therefore, be working on something else.
Quote:
And too bad we don't have the money to give amd so we could get those documents. That would probably mean in millions of euro. Wish i could win the lottery.
With that much money we could probably develop our own graphics card.
Hans
** PCIe has a particularly large penalty for transferring small blocks (e.g., 32-bits) at a time. On the A1-X1000, altivec is used to transfer 128-bits (16 bytes) at a time, but that's still not big enough for top speeds.
Antique wrote: Any way to help you get those fixed faster?
Actually, what would help is if someone provided sample YUV images and a small test program that displays them using the existing overlay functionality. I need test images in the following format: - RGBFB_YUV422CGX - RGBFB_YUV420P - RGBFB_YUV410P
Basically, the test program would open a Picasso96 overlay window in each of these formats, and display a test image. The source-code would also have to be provided, so that I could adapt it for testing the textured video functionality.
LiveForIt wrote: I can do RGBFB_YUV422 PIP, I have something like that somewhere I think, I was experimenting whit Mplayer some years ago.
That would be helpful, thanks. If you have that, then it shouldn't be hard to add the other pixel formats too. You just need image data in the two planar formats. Ffmpeg could be used to dump a frame or two to disk in those formats (link). The test program could then, load in the dumped file and display it using overlay.
Generally speaking, to get an NDA with a company for technical documentation requires convincing them that giving us the docs will make them a lot of money. This is because we'd be taking up their engineers' time with questions about any confusing and missing parts of the documentation. We're not really in the position to make them a lot of money.
I've had far more success than rejections. Successes include ATI (before AMD), AMD, Uli, PA Semi, Via, PLX Tech, Jmicron, Freescale, and others. Rejections include Nvidia, Intel, Ricoh. Nether list is all-inclusive, but what I can remember off the top of my head has more than doule the successes than failures.
My guidelines to getting an NDA with such people, for a hobbyist sort of project like I've ben involved in myself: 1) Try. you certainly don't get what you don't ask for. Heck, Via's response to my NDA request was a PDF file in a reply email, nothing else. 2) Have a legitimate company in a relevant industry. Your company sounds like image processing, which is related to video processing, which is very relevant to this thread's stated topic. 3) Have a professional website for said company of yours. Most vendors do check up on you before calling or emailing. 4) It's OK to be a startup company. (I talk about our company here being an embedded system design house, which we do aspire to be, and have a variety of non-Amiga projects like that) 5) Do NOT say the A-word. No one takes Amiga seriously anymore out there. Sorry. Instead, talk Linux, QNX, or some other embedded OS that may need driver improvement in, and would reasonably be part of or host to your intended product, with the intent of sharing code with what we in this discussion want to happen. (same for design modularity/reuse in a hardware project) 6) Be honest. Try not to talk about Amiga. If you find yourself getting herded into saying that, don't lie your way out of it. Code sharing with an oddball platform that interests you isn't a bad thing. Exaggerate a little, but liing will get you in trouble at some point. 7) Be closed-source/proprietary. you won't get NDA protected documentation for an open-source project. Closed-source is the way to go.
I believe Hans fits my own guidelines pretty well, and I'd encourage him to have a go at requesting NDA to these things. I'd encourage trying via the AMD Embedded Developer Support site. it's relatively easy to get into that, and it has a path to the Embedded Discrete Graphics products group NDA. That wasn't hard either. Once there, you may have contact with the right people to ask about the video acceleration NDA, or someone who can help get you to the right people.
Doesn't hurt to ask. Maybe they'll say no, but at least give them the opportunity to say yes.
Doesn't hurt to ask. Maybe they'll say no, but at least give them the opportunity to say yes.
I already did try. At first the "developer relations" guy fobbed me off with the generic "wait for the open documentation" reply. When I reiterated that his own boss had said that the UVD docs wouldn't be opened up ... the line went dead.
NOTE: I didn't mention Amiga by name, and was very clear about what documentation I was requesting access to and that it was for a closed-source driver.
To be honest, someone else needs to pick up the ball on this. I don't have the time to add HW video decoding to my workload.
@Hans >Actually, what would help is if someone provided sample YUV images and a small test program [...] in the following format:- RGBFB_YUV*
Do you think that Warp3D may be used to decode YUV with the multi-texturing feature ?
@all Can someone describe (Input format (yuv nnn?) -> Output format (rgba?) precisely what kind of "overlay_like conversion" need all those video players ???? So perhaps I can have a look too..
** PCIe has a particularly large penalty for transferring small blocks (e.g., 32-bits) at a time. On the A1-X1000, altivec is used to transfer 128-bits (16 bytes) at a time, but that's still not big enough for top speeds.
So the X1000 currently does all gfx operations by PIO??! Even rectfill and moving windows and screens, draw shadows etc. and obviously BltBitMap for painting the video on a window?
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
thellier wrote: @Hans >Actually, what would help is if someone provided sample YUV images and a small test program [...] in the following format:- RGBFB_YUV*
Do you think that Warp3D may be used to decode YUV with the multi-texturing feature ?
Could Warp3D's multitexturing handle the equations that Karlos posted if the Y, U, and V channels were in separate textures? If so, then you might be able to display the planar modes YUV420P and YUV410P. The interleaved format YUV422 won't be possible, because the U and V data is shared between pixels. This requires explicit driver (and HW) support.
** PCIe has a particularly large penalty for transferring small blocks (e.g., 32-bits) at a time. On the A1-X1000, altivec is used to transfer 128-bits (16 bytes) at a time, but that's still not big enough for top speeds.
So the X1000 currently does all gfx operations by PIO??! Even rectfill and moving windows and screens, draw shadows etc. and obviously BltBitMap for painting the video on a window?
I'm not sure what you're asking. All of the functions that you're talking about are HW accelerated, so the RAM to VRAM transfer speed is almost irrelevant.
>Could Warp3D's multitexturing handle the equations that Karlos posted if the Y, U, and V channels were in separate textures?
Yes,I think it may be possible to use Warp3D's multitexturing for converting YUV to RGB W3D_MODULATE is a multiply operation so can multiply a coef (stored in vertices colors) with a (quad)texture Y is the first texture * ycoefs U is the second smaller texture * ucoefs V is the third smaller texture * vcoefs
If someone can post an YUV image (with the same format as the amiga-video-player that miss overlay) then I can give a try...
>The interleaved format YUV422 won't be possible, because the U and V data is shared between pixels Perhaps no: if we consider that U (or V) is a separate texture with a smaller size
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
