Whoops, ATI's Evergreen Will Bring A New Driver

[jonnyh]

4770 has 2d and 3d, 5670 has neither.

The 5000 series has basic 2d KMS (It seems to work with xrandr multiscreen, no acceleration or XV) but you have to build the kernel from git IIRC.
There seems to be the framework starting to come together for acceleration in airlied's git repository in the drm-radeon-testing branch, so that is probably where you will see updates as they happen.

[waucka]

Boot a Fedora LiveCD, because evergreen does 2D

Are you sure it's accelerated 2D? It may be that the driver is just providing a dumb framebuffer. A sufficiently speedy CPU can compensate fairly well for lack of 2D GPU acceleration. I don't think ATI hardware has had dedicated 2D hardware since the r300 (the 3D engine is used instead), so you probably do not have 2D acceleration on Evergreen.

[crazycheese]

Boot a Fedora LiveCD, because evergreen does 2D

Are you sure it's accelerated 2D? It may be that the driver is just providing a dumb framebuffer. A sufficiently speedy CPU can compensate fairly well for lack of 2D GPU acceleration. I don't think ATI hardware has had dedicated 2D hardware since the r300 (the 3D engine is used instead), so you probably do not have 2D acceleration on Evergreen.

So does 5xxx have opensource accelerated 2D? 2D is basic thing, although I really appreciate opensource 3D

Does 4xxx(4770) have really any accelerated 3D via mesa or gallium?

Fglrx will never be an option to me, for the reason mentioned above.
And if it leads fglrx way, I can keep nvidia either.

The question is kinda important to me. The people at net-shop I target now, have "midnight shopping" - stuff gets shipped free at midnight,.. so I pretty can grab 5750 with my budget then. Of course unless I end up with VESA in linux.

[V!NCENT]

Are you sure it's accelerated 2D? It may be that the driver is just providing a dumb framebuffer. A sufficiently speedy CPU can compensate fairly well for lack of 2D GPU acceleration. I don't think ATI hardware has had dedicated 2D hardware since the r300 (the 3D engine is used instead), so you probably do not have 2D acceleration on Evergreen.

[vincent@localhost ~]$ cd /etc/X11/
[vincent@localhost X11]$ ls
applnk prefdm xdm Xmodmap xorg.conf.backup
fontpath.d X xinit xorg.conf Xresources
[vincent@localhost X11]$ less xorg.conf

# Xorg configuration created by system-config-display

Section "ServerLayout"
Identifier "single head configuration"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"

# keyboard added by system-config-display
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
Option "XkbVariant" "intl"
EndSection

Section "Monitor"
Identifier "Monitor0"
ModelName "LCD Panel 1680x1050"
HorizSync 31.5 - 65.5
VertRefresh 56.0 - 65.0
Option "dpms"
EndSection

Section "Device"
Identifier "Videocard0"
Driver "radeon"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
Modes "800x600"
EndSubSection
EndSection

~
xorg.conf (END)

KDE Size & Orientation:

DVI-0 (Connected)
Size: 1680x1050 (Auto)
Refresh: 59.9 Hz

KInfoCenter:

-Server Information
--Name of the Display :0.0
--Vendro String Fedora Project
--Vendor Release Number 10,706,000
--Version Number 11.0
-Available Screens
--Screen # 0 (Default Screen
---Dimensions 1,680 x 1,050 pixels (444 x 277 mm)
---Resolution 96 x 96 dpi
---Depths (7) 24, 1, 4, 8, 15, 16, 32
---Root Window ID 0x0000011b
---Depth of Root Window 24 planes
---Number of Colormaps minimum 1, maximum 1
---Default Colormap
---Default Number of Colormap Cells 256
---Preallocated Pixels Black 0, White 16,777,215
---Options backing-store: No, save-unders: No
---Largest Cursor 64 x 64
-Maximum Requiest Size 16,777,212 Bytes
-Motion Buffer Size 256 Bytes
-Image Byte Order LSBFirst

KDE4 System Monitor widget:

GPU: ATI Technologies Inc Device 68b8

[fhuberts]

why copy???

Just to be clear, there's no intention of "writing a new driver", just creating a new copy of the existing driver and changing the register addresses in the copy rather than modifying all the code to deal with different addresses depending on what GPU is being used.

This is to make things quicker and easier, not harder.

re: understanding how graphics cards work, have you read agd5f's blog posts from a couple of years ago ? If not, they're a pretty good starting point :

http://www.botchco.com/agd5f/?p=14

Once you have the basics, maybe look at the 5xx or 6xx/7xx acceleration guides in the docco list a couple of posts above.

what I don't understand from all this is why you'd want to _copy_ the driver and 'only' update some constants? That's asking for major headaches in the future...

Why not convert these contants to a lookup table based implementation: (for example) when r300-r700 then look for the constants in table 1, when r800+ look in table 2.

Granted, this will cost 2 memory access extra. But maybe there's even a better solution without copying code.

[pvtcupcakes]

Boot a Fedora LiveCD, because evergreen does 2D

I think he's talking about accelerated 2D like EXA or Xv.
But you're right in that r800 can draw stuff on screen. It's just not hardware accelerated.

[bridgman]

what I don't understand from all this is why you'd want to _copy_ the driver and 'only' update some constants? That's asking for major headaches in the future...

Again, the only reason doing this makes sense is if there *is* no future, ie if we move from "classic" to Gallium3D drivers which would be a different code base anyways.

If it turns out that we need to stay with the classic mesa drivers for a while then we probably would want to merge 6xx/7xx with Evergreen and later, but *after* the initial working code is in a public repo and in users hands.

[smitty3268]

what I don't understand from all this is why you'd want to _copy_ the driver and 'only' update some constants? That's asking for major headaches in the future...

Why not convert these contants to a lookup table based implementation: (for example) when r300-r700 then look for the constants in table 1, when r800+ look in table 2.

Granted, this will cost 2 memory access extra. But maybe there's even a better solution without copying code.

To make it a little simpler, which of these (completely made up) scenarios makes more sense:

1. Work 1 week on refactoring the classic driver to include r800 register offsets. Then work 3 weeks trying to get the 3D hardware actually working. Then port everything over to Gallium, throwing away the refactoring work you did.

2. Work 4 weeks trying to get the 3D hardware working. Then port everything over to Gallium.

[Veerappan]

Does 4xxx(4770) have really any accelerated 3D via mesa or gallium?

Yes, it does. I have a Radeon 4770 in my desktop at home and Ubuntu 10.04 has hardware-accelerated 3D via Mesa. Compiz is working, suspend/resume is working, native games (the one's that I've bothered benchmarking using PTS) are working.

[crazycheese]

I think he's talking about accelerated 2D like EXA or Xv.
But you're right in that r800 can draw stuff on screen. It's just not hardware accelerated.

Exactly.
I think, im settled with HD4770. Its 40nm as HD5xxx, has performance similar to 5750(well, a bit slower, but Wattage is lower too), and its R700, that's back'd up.

I was unable to find blow-out air-tube cooler, as with XFX, but oh well. I will create my own from empty DVD cases...

Thanks everyone, and thanks to AMD devs for caring about FOSS. Bb nvidia