ATI R600/700 OSS 3D Driver Reaches Gears Milestone

[bridgman]

Aah I see.
But I shouldn't try this on a 2.6.30 kernel?

Not if you want it to work

AFAIK the next step on the drm side would be to get it synced with the latest kernel code in preparation for merging it upstream. That probably means skipping over some of the kernel versions between 2.6.28 and 2.6.31.

[nanonyme]

Not if you want it to work

AFAIK the next step on the drm side would be to get it synced with the latest kernel code in preparation for merging it upstream. That probably means skipping over some of the kernel versions between 2.6.28 and 2.6.31.

Actually 2.6.29 and 2.6.30 run glxgears just the same as 2.6.28 for me. (as we all know, r6xx-r7xx-3d DRM requires a bit of patching to compile on 2.6.30) I managed to get all three to reproducably lockup with it though. I first started glxgears, then Firefox and it lockups.
Edit: another user said he's getting the same lockup with Xv so might be related to EXA.

[pingufunkybeat]

First of all, great work, this is very exciting.

Now let me see if I understand the current state.

- you need the latest drm (master), newer than the one that went into 2.6.31 kernel. A merge with the kernel is planned
- you need the latest mesa (r600-rewrite branch). A merge with the master branch is currently being worked on

So, the prospect is that soon we'll be able to install a stock kernel and, with recent enough stock Mesa, get glxgears on r600/r700?

[nanonyme]

- you need the latest drm (master), newer than the one that went into 2.6.31 kernel. A merge with the kernel is planned

You need kernel modules from agd5f's r6xx-r7xx-3d drm branch and libdrm seems so far to be a free choice, drm master appears to be fine for that. Just have to be a bit careful before the r6xx-rewrite merge into Mesa master if you have libdrm with --enable-radeon-experimental-api since r6xx-rewrite is not all the time with sync with master until then. (and the API might change)
Rephrase: don't compile libdrm with --enable-radeon-experimental-api unless you have a good reason to.
Edit: "A merge with the master branch is currently being worked on" is an optimistic way imo to talk of r6xx-rewrite since currently what's being worked on is the implementation for r6xx-rewrite itself. :3 Developers probably have some kind of milestones for the functionality that it has to pass before they actually want to merge. (and they'll make sure the merge won't break any other drivers)

[pingufunkybeat]

Thanks for the clarification.

I guess I got too optimistic after reading "Alex just merged the last few weeks of changes from master into r6xx-rewrite (in preparation for merging r6xx-rewrite back into master)"

[nanonyme]

I guess I got too optimistic after reading "Alex just merged the last few weeks of changes from master into r6xx-rewrite (in preparation for merging r6xx-rewrite back into master)"

Well, that's probably the reason for the recent sync, yes. I wouldn't read too much into the syncs, keeping r6xx-rewrite and master close together is smart since it makes the eventual merge easier but the developers only merge when they feel the code is ready enough. (I could always be wrong and they could merge the code immediately, I'm no mind-reader; all I'm saying reading between developers' lines isn't a good idea)

[bridgman]

Actually 2.6.29 and 2.6.30 run glxgears just the same as 2.6.28 for me. (as we all know, r6xx-r7xx-3d DRM requires a bit of patching to compile on 2.6.30) I managed to get all three to reproducably lockup with it though. I first started glxgears, then Firefox and it lockups. Edit: another user said he's getting the same lockup with Xv so might be related to EXA.

Nanonyme, was the lockup on 2.6.28 with the drm code straight from agd5f's repo, or was that with the patches for 2.6.30 already in ?

There does seem to be some kind of interference between EXA and 3D, more so than between Xv and 3D. Best guess is that EXA is setting some state which 3D is not. Unfortunately there's a lot of state info to compare.

We do hope to merge the mesa code into master as soon as we can be confident that it won't impact existing drivers. It's not like radeon-rewrite, where the new code replaced existing code that people were already using so the new code had to be "comparable" to the old code in terms of functionality and stability; for 6xx/7xx the choices are running the new code or swrast so the bar is relatively low. IIRC MostAwesomeDude's 3xx-5xx Gallium code went in as soon as there was confidence that it wouldn't break the builds, which I thought made sense.

The bar will be quite a bit higher for merging drm, since we have the added requirement of being pretty confident the API between client and DRM will be able to stay stable from that point on. That means most of the important functionality will have to have been tested and verified, at least enough to know that the drm ioctls can be frozen.

[forum1793]

Alex's last changes for 780g did help with glxgears.

Current test using slackware64-current with qt4+/kde4+

I still get a complete black screen (entire monitor) but when moving the mouse and clicking, the screen comes back, and I can see the familiar gears spinning. If I click on the glxgears window the complete black screen toggles back.

If I grab any window and move it or leave it even partially over the glxgears window, screen corruption below the glxgears window occurs. Closing the gears window and clicking on the corrupt area makes it go away.

bash-3.1$ glxgears
IRQ's not enabled, falling back to busy waits: 2 18
139 frames in 5.0 seconds = 27.706 FPS
142 frames in 5.0 seconds = 28.277 FPS
190 frames in 5.0 seconds = 37.948 FPS
198 frames in 5.0 seconds = 39.402 FPS

Devs you're doing great.

[forum1793]

Another observation.

I'm getting around 28 fps. But if I cover some of the glxgears window the fps shoots up. If I totally cover it the number goes up to >1000 fps.

Question: what options should we be using for xorg.conf
This is my current relevant section:

Section "Device"
	Identifier  "RadeonVid"
	Driver "radeon"
	Option "AccelMethod"  "exa"
#	Option "EXANoComposite" "true"
#	Option "EXANoUploadToScreen"
#	Option "EXANoDownloadFromScreen"
#	Option "MigrationHeuristic" "greedy"
		
EndSection

I'll try in a bit with some alternatives.

[nanonyme]

Nanonyme, was the lockup on 2.6.28 with the drm code straight from agd5f's repo, or was that with the patches for 2.6.30 already in ?

Iirc it was straight from repo but never hurts to check again.

We do hope to merge the mesa code into master as soon as we can be confident that it won't impact existing drivers. It's not like radeon-rewrite, where the new code replaced existing code that people were already using so the new code had to be "comparable" to the old code in terms of functionality and stability; for 6xx/7xx the choices are running the new code or swrast

I'd probably still consider swrast to be the better choice for casual users before the memcpy issue gets sorted out and replaced with something in the DRM and this EXA/Xv vs OpenGL confrontation ends up in at least a ceasefire, preferably a peace. :3