Future of ATI Linux drivers

[Svartalf]

From what I can see there is no reason at all the "driver" can't be installed ON THE CARD making it "autonomous" and therefore usable to any "operating" system. A simple translation stub could then be written to support various operating environments.

What you're describing is an F-Code, Open Firmware centric, solution.

It's certainly doable- at a price. There's a reason we use drivers and not BIOS wedges (which is what you're describing).

It takes resources to make calls to those system portions, and in the case of what you're describing, you need a bytecode interpreter of some sorts because even within the same CPU architecture there's going to be differences in stack usages, etc. This means slowing down the speed to drive the device by the amount that the bytecode interpreter will take to process the requests.

This is not to say that we can't do this to some level and have a common denominator level of performance, perhaps even acceptable levels thereof. It's just not going to be something that you can obtain peak performance on.

[Porter]

What you're describing is an F-Code, Open Firmware centric, solution.

It's certainly doable- at a price. There's a reason we use drivers and not BIOS wedges (which is what you're describing).

It takes resources to make calls to those system portions, and in the case of what you're describing, you need a bytecode interpreter of some sorts because even within the same CPU architecture there's going to be differences in stack usages, etc. This means slowing down the speed to drive the device by the amount that the bytecode interpreter will take to process the requests.

This is not to say that we can't do this to some level and have a common denominator level of performance, perhaps even acceptable levels thereof. It's just not going to be something that you can obtain peak performance on.

Isn't it equally resource-intensive to have a large, complex driver interacting with the device?

[forrestcupp]

Enable the 'Extra WM Actions' plugin in the CompizConfig Settings Manager, and assign a keyboard shortcut for 'Toggle Fullscreen' - use that shortcut to get apps fullscreen and the flickering goes away (though you may have to toggle it fullscreen a couple of times if it appears corrupted).

My flickering happens even with things that are already fullscreen. Would this help things that are already fullscreen?

[siggma]

I can't seem to get a clear answer on that either.

I found some answers in the fglrx driver. See this thread on Ubuntu forums.

http://ubuntuforums.org/showthread.php?t=702997

There is a way to force AIGLX and the hardware vidwo playback.
-Tom

[siggma]

Hardware Independent Computing

What you're describing is an F-Code, Open Firmware centric, solution.

What is F-Code?

It's certainly doable- at a price. There's a reason we use drivers and not BIOS wedges (which is what you're describing).

No, that's not what I'm describing. With a serial bus there is no "byte" limitation, no need to make a "call" to the BIOS. There is no BIOS. You send a command to the video card via the serial bus to "fetch and play /home/tom/vids/mega-monster" and the video card sends the request to wherever "/home/tom/vids/mega-monster" is stored. It then opens the file as a bitstream because it's a SERIAL bus, not a parallel bus, no predefined bit blocks. No 8 bit, 16 bit 32 bit etc.

It takes resources to make calls to those system portions, and in the case of what you're describing, you need a bytecode interpreter of some sorts because even within the same CPU architecture there's going to be differences in stack usages, etc. This means slowing down the speed to drive the device by the amount that the bytecode interpreter will take to process the requests.

An autonomous hardware-based code pre-processor with it's own RAM and integral processor is what I'm suggesting. Input would be "bit blocked" based on the
library definition for the specific processor. But, in a serial bus architecture there is no "forced" bit blocking so instructions can be varying length. In fact they are easier to use if they are mapped to processor tokens.
Add a multi core processor without any predefined register lengths in it's own register isolated, hardware bound address space.

This is not to say that we can't do this to some level and have a common denominator level of performance, perhaps even acceptable levels thereof. It's just not going to be something that you can obtain peak performance on.

That's where I disagree. When the video card is doing all the decoding work without any main processor help, how can you say performance would be lower?

Read this and comment in email so we don't get too off topic here:http://home.trbailey.net/trb/2007/10...dent-computing

[Porter]

I found some answers in the fglrx driver. See this thread on Ubuntu forums.

http://ubuntuforums.org/showthread.php?t=702997

There is a way to force AIGLX and the hardware vidwo playback.
-Tom

The thread seems to be dealing with ways to get Compiz to work. What exactly in that discussion relates to forcing hardware video playback?

[siggma]

[solved] AIGLX Compix-fusion video playback radeon x1650

The thread seems to be dealing with ways to get Compiz to work. What exactly in that discussion relates to forcing hardware video playback?

Actually I finally found the solution. I compiled up a copy of vidix (xvidix to mplayer) and it solved the playback problems in both Totem and mplayer. Vlc works OK but it doesn't have the ffmpeg decoder with all it's options like mplayer.

Here's what I did:
download and install the source for the current mplayer and add the svgalib helper to execute it with appropriate permissions.
Here is the link to a HOW TO but it doesn't include compiling vidix, which is easy:

http://ubuntuforums.org/archive/index.php/t-519369.html

I had to search for the correct source on the mplayer site. I think the current version is MPlayer-1.0rc1 but the download link points you at rc2.
Here is the link to the current source gutsy 7.1 (Feb 22 2008):http://www.mplayerhq.hu/MPlayer/rele...1.0rc1.tar.bz2

Download and compile vidix:
site:http://vidix.sourceforge.net/

All I did was ./configure, make and sudo make install vidix and rebooted and it's working fine

You may need to run gstreamer-properties and set the default to "custom", hit test then OK. It defaults back to X11 but works fine.
Very Happy now...

[givemesugarr]

The thread seems to be dealing with ways to get Compiz to work. What exactly in that discussion relates to forcing hardware video playback?

maybe he intends this:

Option "TexturedVideo" "True"
#->New!! Plays accelerated video! Important!
Option "TexturedVideoSync" "True"
#-> Synchronizes Textured Video
Option "Textured2D" "True"
# ->Experimental! See Note 1...
Option "TexturedXrender" "True"
#->Experimental! See Note 2...
Option "BackingStore" "True"
# ->Helps alot. See Note 3...
Option "MaxGARTSize" "512"
# ->For PCI-Express cards it sets the amount of VRAM to be allocated by the #driver. "000"=Put your amount of VRAM here. See Note 4...

i'll try out the texturedvideo on my board and let you know how it behaves.

[siggma]

maybe he intends this:



i'll try out the texturedvideo on my board and let you know how it behaves.

Actually I found out why I've been having trouble. A bug in mplayer prevents it from recognizing the newer radeon cards. see this article:

http://ubuntuforums.org/showthread.php?t=519369&highlight=vidix

I'm installing it now to see if it will accept: -vo xvidix as an output device.
-Tom

[Svartalf]

Isn't it equally resource-intensive to have a large, complex driver interacting with the device?

Less so than an equally large complex driver residing in BYTECODE that would have to be interpreted. In order to accomplish most of what we're needing out of the 3D support, unfortunately, it's going to be complicated no matter what you think might go.