R600/700 EXA X-Video Code Merged To Master

[phoronix]

Phoronix: R600/700 EXA X-Video Code Merged To Master

In late December AMD had released R600/700 3D code that allowed open-source triangles to be drawn and a AtomBIOS decompiler also came out of Novell just a few days later. In late January we were then greeted by public R600/700 3D documentation...

http://www.phoronix.com/vr.php?view=NzA5NQ

[izual]

Well, great job!
But I want my radeonhd :D

[d2kx]

Nice :D

Now let's wait for Linux 2.6.30!

[bulletxt]

"Now it's time to have a working, open-source 3D stack for the ATI Radeon HD 2000/3000/4000 hardware."

I really can't wait for a phoronix article that says: "And here is your free 3d!" :D

[rotarychainsaw]

gimme gimme!

[bugmenot]

Great steps! But I also wait for radeonhd.
Hopefully the DRI bug gets fixed soon. Here it crashed sometimes while moving and resizing a movie outside of the screen...If that is fixed, I'll stick to it. Atm I use radeonhd+shadowfb again. AFAIK this is also the last reason why DRI is not enabled by default.
Apart from that I really really like radeonhd. It runs really awesome. :)

[timofonic]

When will xf86-video-ati vs RadeonHD drivers will end? What about a merge for not wasting the already limited resources?

This is bad to both developers and users...

[Timo Jyrinki]

The experience should be roughly the same with both -ati and -radeonhd nowadays (or, I think -radeonhd has the HDMI audio support which -ati lacks? but otherwise). The problem of two drivers is basically already ending, because the ddx drivers are becoming irrelevant with the current r6xx-r7xx work in the drm driver and kernel mode setting. The work is independent from these ddx drivers and have eg. no code from -radeonhd.

You can see the similarity also in that you may use the same wiki instructions (http://wiki.x.org/wiki/radeonhd%3Ar6xx_r7xx_branch) for both drivers, although for xf86-video-ati (http://wiki.x.org/wiki/radeon) you naturally do not need the branch anymore since it's in trunk.

It should not be wasting resources much either, since as you can see in the two (1 (http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/?h=r6xx-r7xx-support), 2 (http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/log/?h=r6xx-r7xx-support)) git branches, the last 20+ commits are roughly just the same code committed in two places :)

Correct me if I'm wrong, but it seems there is not much overlapping work done anymore, in the sense it would slow down something. Radeonhd was planned to become different, not using atombios, but now also radeonhd uses atombios like ati.

[bridgman]

It's pretty much the same acceleration code in both drivers (and the same developer ;)) so there's not really a lot of duplication going on right now. It would still be nice to get to a single code base over time.

The drm code and mesa code are *exactly* the same, of course, since there has only ever been one code base.

In the meantime, as libv said on IRC today, if you find that one driver has problems but the other one works for you, please report the problem (via bugzilla or mailing list) for the other driver anyways. Sometimes this gives the devs a real useful clue.

[d2kx]

What are the differences between Radeon and RadeonHD anyway? I hear they've got a different modesetting code, but that too is not the case anymore once KMS is supported by the free drivers I guess? Anything else?

[bridgman]

What are the differences between Radeon and RadeonHD anyway? I hear they've got a different modesetting code, but that too is not the case anymore once KMS is supported by the free drivers I guess? Anything else?

It's mostly the modesetting code that is different (in a number of ways), although there are some changes in other areas as well, eg Luc reworked the bottom end of the acceleration stack in radeonhd.

Even though KMS is pretty much here, it will still be a while before the need for user modesetting goes away since most of the enterprise distro users will be running pre-KMS kernels for a couple of years. I don't expect you'll see the first release of a KMS-enabled enterprise distro until some time in 2010, and realistically we need to keep user modesetting supported until a good chunk of the enterprise distro installed base is running with KMS-enabled kernel code.

[mattst88]

Is the current plan to work on adding R600/R700 support to Mesa, or to jump straight to Gallium?

[tulcod]

It's mostly the modesetting code that is different (in a number of ways), although there are some changes in other areas as well, eg Luc reworked the bottom end of the acceleration stack in radeonhd.

Even though KMS is pretty much here, it will still be a while before the need for user modesetting goes away since most of the enterprise distro users will be running pre-KMS kernels for a couple of years. I don't expect you'll see the first release of a KMS-enabled enterprise distro until some time in 2010, and realistically we need to keep user modesetting supported until a good chunk of the enterprise distro installed base is running with KMS-enabled kernel code.

long live gentoo <3

[bridgman]

Is the current plan to work on adding R600/R700 support to Mesa, or to jump straight to Gallium?

We're going to add basic 6xx/7xx support using the "classic" mesa driver model first, in order to provide support for users running systems which don't have KMS/MM and DRI2. By "basic" support I mean roughly the same functionality we have with 5xx today.

Once that is running, we'll port the hw-specific code across to Mesa-on-Gallium3D and do most of the ongoing work there.

[Linuxhippy]

Do you know if there are plans to merge the r6xx/7xx EXA code back into Catalyst? I've here terrible performance with KDE4.2, and my XRender benchmark results go hand in hand with the user experience.

[rbmorse]

Waddaya know...TVtime works.

[MostAwesomeDude]

Now it's time to have a working, open-source 3D stack for the ATI Radeon HD 2000/3000/4000 hardware.

Patches welcome. :3

[izual]

Do you know if there are plans to merge the r6xx/7xx EXA code back into Catalyst? I've here terrible performance with KDE4.2, and my XRender benchmark results go hand in hand with the user experience.

radeon/radeonhd is GPL code afaik so that shouldn't be possible.

[quintesse]

It's mostly the modesetting code that is different

And the HDMI Audio bit, like Timo Jyrinki mentioned above, as far as I know?

For me that's really the only reason I'm using the radeonhd driver right now.

PS: "open source triangles"? What are those? Triangles where you are allowed to see and changes the vertices? ;)

[Timo Jyrinki]

Forgot that radeon has experimental tv-out support on r6xx, and also tear-free video playback on r5xx, which I think are not available on radeonhd. But radeonhd has the hdmi audio support. Those three probably summarize the user visible differences?

Of course the modesetting code differences mean that different driver might have different outcome on various cards, but that's actually quite neat to find possible problem areas in both drivers.

[bridgman]

The open source driver code is actually MIT/X11 licensed so using it in proprietary drivers is OK, but the fglrx driver architecture is sufficiently different that we probably wouldn't be able to re-use the code anyways.

[bugmenot]

Forgot that radeon has experimental tv-out support on r6xx, and also tear-free video playback on r5xx, which I think are not available on radeonhd.
AFAIK tear-free video playback is now also in radeonhd (git).

And *I* can't see any reason for using radeon. Radeonhd was the first and so the work on radeon to support the newest chips is duplicated effort. Also there are many places that are cleaned up in radeonhd, in radeon not.

Merging together does not really work and does not really make sense also. Those two driver are really pretty different. Let's see how the story continues with KMS....
The easiest thing would be that radeon simply stops supporting newer chips. Having two drivers is simply stupid and does not make sense at all. But we know that already and notice it every time again when a bug is only reported for the one driver and not for the other...

[bridgman]

Radeonhd was the first and so the work on radeon to support the newest chips is duplicated effort. Also there are many places that are cleaned up in radeonhd, in radeon not. Merging together does not really work and does not really make sense also. Those two driver are really pretty different. Let's see how the story continues with KMS.

It's not really that simple either, unfortunately. The radeonhd driver was actually the third, not the first -- we already had airlied's unreleased 5xx support in radeon and the avivo driver before starting work on radeonhd. We proposed replacing both of those drivers with a new driver built over the atombios routines, and the developers working on radeon and avivo felt that was a good plan.

So far so good; there would be a new driver based on atombios, supporting 5xx and up, and everyone would support it.

When radeonhd turned out to be mostly hard-coded there was a "WTF ??" moment in the rest of the dev community and things got complicated again. The devs who had agreed to support a new atombios-based driver rather than their existing hard-coded drivers said "screw this" and added atombios-based support to radeon. The rest, as they say, is history.

Over time (maybe a couple of years) I agree that KMS will solve the issue by eliminating the areas of code where the two drivers differ the most, but my current thinking is that both drivers will continue to exist until user modesetting goes away completely.

[susikala]

Forgot that radeon has experimental tv-out support on r6xx, and also tear-free video playback on r5xx, which I think are not available on radeonhd. But radeonhd has the hdmi audio support. Those three probably summarize the user visible differences?

Of course the modesetting code differences mean that different driver might have different outcome on various cards, but that's actually quite neat to find possible problem areas in both drivers.

Actually, radeon (git) has tear-free video playback on all chips. That is the main reason I use radeon and not radeonhd (although the patch may have been already ported to radeonhd or this was otherwise solved).

[izual]

ah, radeonhd merged to, very nice :D

[quintesse]

Actually, radeon (git) has tear-free video playback on all chips. That is the main reason I use radeon and not radeonhd (although the patch may have been already ported to radeonhd or this was otherwise solved).

When people say "radeon" do they refer to the "ati" driver or is there actually something called "radeon" that I don't know about?

[MostAwesomeDude]

When people say "radeon" do they refer to the "ati" driver or is there actually something called "radeon" that I don't know about?

The radeon driver is in the xf86-video-ati package for historical reasons. The ati driver is actually a wrapper that automatically selects mach64, rage128, or radeon depending on the chipset it detects.

[suokko]

One word: DynamicClocks :) +1 for radeon providing that for r500 cards :)

[PuckPoltergeist]

The radeon driver won't work here, not even without any acceleration. :( I only get a black screen with some artefacts the top border of the screen.

X.org log: http://www.stud.tu-ilmenau.de/~johi-in/Xorg.0.log.radeon

[agd5f]

The radeon driver won't work here, not even without any acceleration. :( I only get a black screen with some artefacts the top border of the screen.

X.org log: http://www.stud.tu-ilmenau.de/~johi-in/Xorg.0.log.radeon

Please file a bug (https://bugs.freedesktop.org) and attach your xorg log and config.

[bugmenot]

The radeonhd driver was actually the third, not the first -- we already had airlied's unreleased 5xx support in radeon and the avivo driver before starting work on radeonhd.
But that does actually not matter at all, because the driver was never released due to the NDA.

We proposed replacing both of those drivers with a new driver built over the atombios routines, and the developers working on radeon and avivo felt that was a good plan.
So far so good; there would be a new driver based on atombios, supporting 5xx and up, and everyone would support it.
Ah, there is the problem. You wanted 'of course' the use of atombios, but did not discuss that with the devs. Otherwise this could not have happened in that way.
I don't know exactly about the technical reasons (only that atombios is kind of proprietary and helps to support newer cards more easily in the future) and it probably does not matter, but if there are people writing a good driver for the cards, and it works, why isn't that enough? And today even radeonhd supports atombios, but the work on radeon still goes on?

I still think it would be the best to stop supporting new chips on one driver, in order to have exactly one driver for the new cards. That gives better stability of that driver because every bug is reported to "that" driver.

[agd5f]

But that does actually not matter at all, because the driver was never released due to the NDA.

Dave's code was never released but avivo was released and a few distros actually offered it as an option.
http://cgit.freedesktop.org/avivo/xf86-video-avivo/

[Timo Jyrinki]

And today even radeonhd supports atombios, but the work on radeon still goes on?


As your previous point (assuming you are the same one using a bugmenot account) was that radeonhd was first, while actually radeon was the first (of those two) with atombios support, shouldn't now radeon be kept because it was the first with that support? Or avivo ;)


I still think it would be the best to stop supporting new chips on one driver, in order to have exactly one driver for the new cards. That gives better stability of that driver because every bug is reported to "that" driver.

There is nothing to back up the claim that somehow limiting a driver's supported chipsets would magically bring quality improvements. The codepaths are different so cards of various eras can be handled separately. Also, r500 is quite close to r300-r400.

The developers are mostly happy nowadays, so I think us users should just shut up and use whatever our distro provides. It's easy for developers to submit code to both drivers, and if viewing optimistically, really the two somewhat different code-bases, now that they already exist, are for everyone's benefit as different kind of bugs can be spotted in either of them and maybe something gets fixed that would otherwise been left unfixed.

It's more like "nothing to see here, move along" situation.

And indeed as was noted earlier in this thread, the r6xx-r7xx branch is now also merged to radeonhd.

[bugmenot]

There is nothing to back up the claim that somehow limiting a driver's supported chipsets would magically bring quality improvements.

In radeonhd the command submission (CS) was cleaned up, it is not only less support for older chipsets.
Also, r500 is quite close to r300-r400.
And from R600 on it is more "new". So imo it makes sense to have a driver only for newer chips.
The developers are mostly happy nowadays, so I think us users should just shut up and use whatever our distro provides.
I see that radeon is used everywhere instead of radeonhd, although the latter has more features. Maybe the users would be more happy with one driver.
It's easy for developers to submit code to both drivers,
Seems not to be the case, because audio over hdmi is still only in radeonhd and tear free video watching was a very long time only in radeon...

and if viewing optimistically, really the two somewhat different code-bases, now that they already exist, are for everyone's benefit as different kind of bugs can be spotted in either of them and maybe something gets fixed that would otherwise been left unfixed.
That is in my opinion not true either. Many bugs only get reported in one of the drivers and so it is less likely that one driver works with as many cards as it would be possible if all bugs got reported to that driver.

It's more like "nothing to see here, move along" situation.
For me it's just stupid. And even more stupid that most distributions use radeon and not radeonhd, although radeonhd has audio over hdmi support.
And indeed as was noted earlier in this thread, the r6xx-r7xx branch is now also merged to radeonhd.
I know and it was developed in radeonhd first.

Sorry for bringing this up again. :(
I just can't understand it. I'll be quite now.

[MostAwesomeDude]

In radeonhd the command submission (CS) was cleaned up, it is not only less support for older chipsets.

And from R600 on it is more "new". So imo it makes sense to have a driver only for newer chips.

I see that radeon is used everywhere instead of radeonhd, although the latter has more features. Maybe the users would be more happy with one driver.

Seems not to be the case, because audio over hdmi is still only in radeonhd and tear free video watching was a very long time only in radeon...

That is in my opinion not true either. Many bugs only get reported in one of the drivers and so it is less likely that one driver works with as many cards as it would be possible if all bugs got reported to that driver.

For me it's just stupid. And even more stupid that most distributions use radeon and not radeonhd, although radeonhd has audio over hdmi support.

I know and it was developed in radeonhd first.

Sorry for bringing this up again. :(
I just can't understand it. I'll be quite now.

Here's all I have to say that hasn't been said before:

The only compelling feature in radeonhd but not in radeon is HDMI audio support, which 1) should probably be in DRM and not DDX and 2) hasn't been ported because I don't have the HW (HDMI audio) and nobody else really cares.

~ C.

[quintesse]

Here's all I have to say that hasn't been said before:

The only compelling feature in radeonhd but not in radeon is HDMI audio support, which 1) should probably be in DRM and not DDX and 2) hasn't been ported because I don't have the HW (HDMI audio) and nobody else really cares.


How about talking to the one that did the development for radeonhd and ask if his code can be included in the radeon driver? Or if it can't be copied easily if he would be willing to help out?

Others I'm sure would be willing to do the testing, I know I did when the first code came out for the radeonhd driver.

[MostAwesomeDude]

How about talking to the one that did the development for radeonhd and ask if his code can be included in the radeon driver? Or if it can't be copied easily if he would be willing to help out?

Others I'm sure would be willing to do the testing, I know I did when the first code came out for the radeonhd driver.

It has to go into the kernel, not the other DDX. HDMI audio setup should be in DRM, and that makes all the difference.

Additionally, it's kind of hard to develop code, period, without local testing HW.

[bugmenot]

The only compelling feature in radeonhd but not in radeon is HDMI audio support, which 1) should probably be in DRM and not DDX and 2) hasn't been ported because I don't have the HW (HDMI audio) and nobody else really cares.
The point is: I don't ask myself why radeon has no support, I ask myself why radeon is the default driver and not radeonhd in most disrtibutions.

It is probably more work to copy the audio over hdmi support to radeon instead of changing the default driver to radeonhd.

[Ex-Cyber]

I don't ask myself why radeon has no support, I ask myself why radeon is the default driver and not radeonhd in most disrtibutions.It doesn't get them anything to add radeonhd as a default. They'd just be stirring up a lot of trouble by making some users' experiences better and other users' experiences worse (radeonhd can very well be worse on R600+, depending on which bugs you run into).

[Ant P.]

How much of the audio support depends on the X driver? I would've thought that could be solely handled by ALSA/OSS, but apparently not.

[bridgman]

Normally the X driver would have nothing to do with audio, but when the audio controller shares an HDMI connector with video the X driver needs to program the GPU to combine the audio and video signals onto the HDMI output.

The rest of the audio functionality is still handled by the audio drivers.

[libv]

The point is: I don't ask myself why radeon has no support, I ask myself why radeon is the default driver and not radeonhd in most disrtibutions.

It is probably more work to copy the audio over hdmi support to radeon instead of changing the default driver to radeonhd.

If you look at the timelines of the two drivers, then people have been copying stuff from radeonhd into radeon and re-inventing the wheel there all along.

When we started with radeonhd we decided from absolute scratch to be able to build a solid, modular and dependable driver suited for the enterprise market. We then, from the outset, also decided to copy parts of the radeon acceleration code (in a clean, modular form) as we knew that, from a hardware point of view, there would be a slight bit of overlap that would be relatively easy to handle. We would still end up with a clean and managable driver.

Notice how the original r5xx support in radeon borrowed more from radeonhd than it ever did from avivo. Notice how, while we at radeonhd were doing the hard labour to support new hardware (with ages spent on solid dotclock calculation routines and vt restoration issues, and finding out all those things that no-one was providing us information for), people were doing some quick and dirty r5xx accel things and claiming it was a solid solution and claiming it was the only solution.

This has been the game all along.

RadeonHD is an attempt to do things properly, to create a solid driver ready for the enterprise market, and as such, ready for average joe user. This means hard labour, not quick statements that boil down to "but it works on my machine". This is a gap in perception, but not in actual usefulness, that cannot be bridged. Quick and dirty will always have the big but rather useless statements. Proper code will always have less visibility, especially since a satisfied user is a silent user.

[Kano]

Do you want that radeonhd is preferred for r500+ hardware in X autodetection code? Also why did radeon enable dri by default and radeonhd not? I backported radeonhd for Xorg 7.1 to use it as better driver than vesa but currently I only backport radeon for Xserver 1.4.2.

[libv]

Do you want that radeonhd is preferred for r500+ hardware in X autodetection code? Also why did radeon enable dri by default and radeonhd not? I backported radeonhd for Xorg 7.1 to use it as better driver than vesa but currently I only backport radeon for Xserver 1.4.2.

That one is pretty straightforward: because we have different standards and we do not see dri support as fully stable yet. If, as a user, you want dri support, you better be aware of what you are doing, and therefor should take hurdle of enabling this option.

Again; big statements versus safe/stable.

[susikala]

Just to add my bit of experience into the discussion, for me radeon and radeonhd work more or less the same. The differences I notice (using a git version from two weeks ago of both drivers):

-radeon had tearfree xv, which is important to me, radeonhd hadn't (I hear this issue's been solved in radeonhd)
-for some reason I don't get, probably just differences in the way the code works, when I play _any_ video with radeonhd, the screen switches to black for 2-3 seconds and then video playback starts. Same thing happens when I close the video (but not when pausing or switching to full screen). On radeon, video playback starts and ends directly, no "buffering".

I have no idea why radeonhd acts like that or whether it's a bug or how it should be, but it's somewhat annoying. So even on a new chip (hd3200), radeon works better for me. This kind of beats the purpose of radeonhd from my point of view as a user.

Honestly, I've been following the git commits for both drivers lately for the r6xx-r7xx development branch, and it looks like the same code keeps being duplicated. Isn't it a waste of work?

[bridgman]

Most of the recent commits (adding 6xx/7xx acceleration) have been in areas where we have been able to keep the code pretty much the same between the drivers, so it's not like the work is actually being done twice.

[elanthis]

Personally, I'm still thankful that we had both drivers. Neither the VESA driver nor RadeonHD were able to actually bring up a useable screen for me for months, but the radeon driver worked right out of the box. (780G chipset.) Both now work wonderfully, of course, but if RadeonHD was the only option, I'd have been stuck.

The same goes for NVIDIA drivers. I had trouble getting either VESA or the nv driver to work with my old 6150 chipset, but nouveau worked fine as did the binary driver.

In a world where everything works perfectly, multiple drivers makes no sense. In a world where all software has bugs, a little choice goes a long way. I'd much rather live in a perfect world, but the reality is that I don't. :)

[Vighy]

In a world where everything works perfectly, multiple drivers makes no sense. In a world where all software has bugs, a little choice goes a long way. I'd much rather live in a perfect world, but the reality is that I don't. :)

You are my new personal guru :D

[Pfanne]

since i didnt want to open a new thread i just ask the question here:
do the open source drivers support compiz + 3d application? (im not speaking of r600/700, but ati cards in general)

[bugmenot]

since i didnt want to open a new thread i just ask the question here:
do the open source drivers support compiz + 3d application? (im not speaking of r600/700, but ati cards in general)
Yes. All cards before have 3d support now, even for many months now. R600/700 will follow hopefully soon. Whats missing and whats important is still power saving for notebooks.

[Pfanne]

Yes. All cards before have 3d support now, even for many months now. R600/700 will follow hopefully soon. Whats missing and whats important is still power saving for notebooks.

so running compiz and for example glxgears work at the same time? no problems there?

[d2kx]

so running compiz and for example glxgears work at the same time? no problems there?

As far as I know, this works even with DRI1 when using the OpenSource drivers, yes. Don't how, but it does.

[adamk]

As far as I know, this works even with DRI1 when using the OpenSource drivers, yes. Don't how, but it does.

Not correctly, it doesn't. It flickers constantly. If you move the glxgears window, you will simply move a black box around and the gears don't actually move till you release the mouse pointer. And, even then, you get the remnant of the gears in their original position. If you rotate the cube, the gears do not rotate with it...

All this will be solved by DRI2, but it certainly does not work properly with DRI1.

Adam

[adamk]

Yes. All cards before have 3d support now, even for many months now. R600/700 will follow hopefully soon. Whats missing and whats important is still power saving for notebooks.

And 3D performance, which is still lacking compared to fglrx.

Adam

[TechMage89]

3d performance should improve a lot when gallium3d support arrives so proper shader optimization can be done by the driver.

[Pfanne]

Not correctly, it doesn't. It flickers constantly. If you move the glxgears window, you will simply move a black box around and the gears don't actually move till you release the mouse pointer. And, even then, you get the remnant of the gears in their original position. If you rotate the cube, the gears do not rotate with it...

All this will be solved by DRI2, but it certainly does not work properly with DRI1.

Adam

well we have xserver 1.6 with dri2
so is there anyone with a driver using dri2 that works fine with a compositer?

[adamk]

3d performance should improve a lot when gallium3d support arrives so proper shader optimization can be done by the driver.

"should improve"... I try not to put too much stock in things that "should" happen :-)

Adam

[adamk]

well we have xserver 1.6 with dri2
so is there anyone with a driver using dri2 that works fine with a compositer?

Juanty has a DRI2 enabled intel driver, but nothing for the radeon. I believe that the developers are working on the final pieces for DRI2 in the radeon driver but that it isn't quite ready yet.

Adam

[Pfanne]

Juanty has a DRI2 enabled intel driver, but nothing for the radeon. I believe that the developers are working on the final pieces for DRI2 in the radeon driver but that it isn't quite ready yet.

Adam

thx for the information

[PuckPoltergeist]

The radeon driver won't work here, not even without any acceleration. :( I only get a black screen with some artefacts the top border of the screen.

X.org log: http://www.stud.tu-ilmenau.de/~johi-in/Xorg.0.log.radeon

Reading helps. The fglrx driver was interfering. I've had to uninstall completely. Now the xf86-video-ati works here. :D

Hm, I was a little to fast. VT-switch to console doesn't work. The monitor is switching of than, but I can switch back to X.

PS: To fast again. Seems that fglrx was responsible for the not working vt-switch too. Reboot helped. (the fglrx kernel module was not loaded!)

[PuckPoltergeist]

No, vt-switch don't work for me. :(

I get lots of

Mar 16 02:08:46 datengrab [drm] wait idle failed status : 0xA0003030 0x00000003

and 100% CPU load from X server. With xf86-video-ati this occurs when switching back to X after switching to console. With radeonhd it happens when switching to console (from X).

[bridgman]

How recent is your drm code ? There were a number of suspend-related fixes added in the last couple of days.

[PuckPoltergeist]

How recent is your drm code ? There were a number of suspend-related fixes added in the last couple of days.

It is the latest of the r6xx-r7xx-support branch. I've did a git pull and rebuild before testing.