Features Still Being Sought By Open-Source AMD Users

[chrno]

On the bright side, if they fix this, the linux open source driver will be ahead of the windows driver in at least one aspect, since this also affects windows.

Yes, it would be fun if the recommended way to fix this problem would be for people to install Linux (if only temporary) to twiddle a bit in the vBIOS... :-)

[agd5f]

The problem is there are still a good number of hdmi monitors out there that overscan by default and there is no way to detect whether or not the monitor does this. If the vbios didn't compensate, you wouldn't be able to see everything on the screen during boot up prior to the OS loading on the affected monitors. This includes things like the bios setup which are fairly important.

[chrno]

The problem is there are still a good number of hdmi monitors out there that overscan by default and there is no way to detect whether or not the monitor does this. If the vbios didn't compensate, you wouldn't be able to see everything on the screen during boot up prior to the OS loading on the affected monitors. This includes things like the bios setup which are fairly important.

I agree completely that the vBIOS default is sensible, for the reasons that you mention. The problem is that there is no way to change it. My monitor and my TV both overscan by default but have options to permanently disable it. Why doesn't any of my six Radeon cards have an option to permanently disable overscan-compensation?

The optimal solution would be to make it a jumper setting but absent such a jumper on existing cards a driver setting to flip a bit in the vBIOS and make it sticky will suffice.

[agd5f]

I agree completely that the vBIOS default is sensible, for the reasons that you mention. The problem is that there is no way to change it. My monitor and my TV both overscan by default but have options to permanently disable it. Why doesn't any of my six Radeon cards have an option to permanently disable overscan-compensation?

The optimal solution would be to make it a jumper setting but absent such a jumper on existing cards a driver setting to flip a bit in the vBIOS and make it sticky will suffice.

An extra jumper costs money which raises the cost of boards. Providing a way to patch the vbios from the driver starts to get really complex, especially for things like laptops where the vbios is part of the larger system bios. Is the extra cost justified for a display that shows up for 10 seconds or less before the OS loads?

[bridgman]

I agree completely that the vBIOS default is sensible, for the reasons that you mention. The problem is that there is no way to change it. My monitor and my TV both overscan by default but have options to permanently disable it. Why doesn't any of my six Radeon cards have an option to permanently disable overscan-compensation?

The optimal solution would be to make it a jumper setting but absent such a jumper on existing cards a driver setting to flip a bit in the vBIOS and make it sticky will suffice.

Just to be clear, are we only talking about the time between power-up and kernel driver initializing (when the driver takes over) ?

[Rakot]

Alex, thank you for your work!

Is there any chance to see support for automatic vgaswitcheroo for hybrid laptops with AMD video card in 3.12? Dave published some patches in the dri-devel mail list but they are for nouveau only. Also he mentioned that he has some problems with radeon driver in order to add such support. Currently even static switching is very unstable on my 7750M (intel+amd muxless system).

[agd5f]

Alex, thank you for your work!

Is there any chance to see support for automatic vgaswitcheroo for hybrid laptops with AMD video card in 3.12? Dave published some patches in the dri-devel mail list but they are for nouveau only. Also he mentioned that he has some problems with radeon driver in order to add such support. Currently even static switching is very unstable on my 7750M (intel+amd muxless system).

I think Dave has patches for radeon as well.

[Hibbelharry]

What I would really like to see are UVD improvements. Especially deinterlacing is a sensible part when using a radeon gpu for mediastuff. Lots of tv broadcasts (even in HD) are broadcasted in 1080i here in Germany and the temporal spatial nvidia deinterlacer offered by vdpau on binary drivers does a pretty good job on that. I wish that amd hardware/software would be getting in a comparable state.

[chrisr]

My vote: UVD 2 support

On the bright side, it sounds like the code for UVD 2.0 has already been written. There's just an unknown number of review hurdles left for it to clear...

After UVD 2.0, there's on-going OpenGL support. And OpenCL support sounds interesting, although I'm not sure what I'd do with it.

[smitty3268]

What I would really like to see are UVD improvements. Especially deinterlacing is a sensible part when using a radeon gpu for mediastuff. Lots of tv broadcasts (even in HD) are broadcasted in 1080i here in Germany and the temporal spatial nvidia deinterlacer offered by vdpau on binary drivers does a pretty good job on that. I wish that amd hardware/software would be getting in a comparable state.

I'm pretty sure UVD doesn't do any deinterlacing. Someone just has to add that into the Mesa VDPAU support.