XvBA on Evergreen

[Kano]

@gbeauche

It can not share that much code with win because 10-7 can decode h264 l 5.1 with vlc now. Never saw that on linux.

[gbeauche]

Can you explain what you mean by "oversized" here - I might be oversimplifying your question.

IIRC the "rectangle=1" setting uses the GL_ARB_texture_rectangle extension rather than GL_ARB_texture_non_power_of_two but I haven't heard about any problems with that option up to the hardware limits of the GPU (8K x 8K on 6xx/7xx I think). I don't remember trying rectangle=2 though...

OK, I thought mplayer was also trying to use GL_ARB_texture_non_power_of_two by default so the fact that you said to try GL_ARB_texture_rectangle made me think that the former probably would create a texture larger than the user-requested size, internally under certain conditions.

Hum, put it simpler: does an NPOT texture always match user-requested size internally? Sure, he will always get his values back through glGetTexLevelParameteri() but does this always mean the driver uses a texture of that exact same size internally, even for small ones (<128x128)?

[curious.developer]

The main thing to watch out for is the cpu and video card... Most current processors (Like the Athlon II x4) have enough power to stay at the lowest speed stepping and still decode 1080p h264 video with very few dropped frames. Anyways, It'd be interesting to see 1080p and 720p videos that are encoded with h264 ( or AC1) be able to be decoded with the radeon hd 5000 series graphics card.

I've bought the Athlon II X4 600e (still waiting for delivery) - sucky price/performance ratio but promises a low power consumption and a low temperature. We will see...

That said, I want to put on the HTPC some dev tools (like Mercurial or Redmine) so it would be nice to offload to the GPU as much as possible.

[gbeauche]

It can not share that much code with win because 10-7 can decode h264 l 5.1 with vlc now. Never saw that on linux.

The code is shared, they clearly don't have the resources like Intel or NVIDIA to write another core implementation from scratch for Linux. The fact you don't see the expected results on Linux doesn't mean the capability is not there... Linux support is "just glue code". That glue code can:

1. not be available to Linux
2. be available to Linux and
2.1. working
2.1.1. by default
2.1.2. through a specific configuration
2.1.3. partially (missing cases in the implementation)
2.2. not working (bugs)

You have no means to be certain which case applies here though. i.e. you just can't say (1) because you don't see the expected results in VLC... Your conclusion, as stated in your quote, is innerly broken. You just can't say that. You can't define a supposed and absolute truth simply from an example. This is illogical. No matter we are talking about XvBA or not.

Look for other features of the driver, there are many symbols that can suggest X or Y but we can't be certain that (1), (2.1.1), (2.1.2), (2.1.3) or (2.2) applies to each simply by testing a random application.