ATI R300-R500 Gallium3D Driver Is "Mostly" Done

[phoronix]

Phoronix: ATI R300-R500 Gallium3D Driver Is "Mostly" Done

It has been a while since talking specifically about ATI's Gallium3D driver, but there is some good news coming out now for the driver that supports the ATI R300 through R500 (Radeon X1000) series hardware. Corbin Simpson, the developer that has largely been working on porting the 3D work from the classic Mesa driver to Gallium3D, has updated the Radeon Feature Matrix page on the X.Org Wiki last night.According to this update, the status of Gallium3D on ATI R300 through R500 hardware has changed from "TODO" and "WIP" to being "DONE" for the Softpipe pass-through and being "MOSTLY" for the core driver...

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

[Zajec]

The ATI Gallium3D driver that supports the R600 and R700 (and R800) hardware is still being worked on as well.Could you share source of that information? AFAIK AMD wants to /finish/ r300g first, to learn what should be avoided when writing r600g. I was eve talking with Bridgman about this yesterday.
So, where did you get that info?

[iznogood]

Hello,

thanks for the updates on the ati driver status. Can someone explain what features is gallium going to offer against the mesa driver ?

I read the matrix but i do not understand what parts of the mesa driver are going to be replaced by the gallium driver. For example is it going to replace only the mesa 3d features or other parts of the matrix as well like XXA - EXA acceleration and xv - xvmc video support ? I don't really understand how gallium is working on the existing graphics stack.

Also i want to ask why there is no gallium on r100 chips?

Finally, i tried to check on the feature matrix of the intel driver http://www.x.org/wiki/IntelGraphicsDriver (http://www.x.org/wiki/IntelGraphicsDriver) but it seems that no one is updating this.

[Michael]

Could you share source of that information? AFAIK AMD wants to /finish/ r300g first, to learn what should be avoided when writing r600g. I was eve talking with Bridgman about this yesterday.
So, where did you get that info?

It's being worked on still as in it's not done yet either.

[DanL]

Michael, I think Zajec is asking where the r600 gallium work is happening (if it is happening). http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers

[Louise]

Michael, I think Zajec is asking where the r600 gallium work is happening (if it is happening). http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers

I think he just made that up.

If someone was working on it, Corbin would have changed the state from TODO to WIP.

[Ant P.]

I think he meant still being worked on as in they haven't forgot about it and it'll get done eventually.

[Zhick]

So what does this mean? Does this get us OpenGL >= 2.0 (and most importantly GLSL) now? Or is there still work that needs to be done for this, except of debuging of course?
I had the understanding that as soon as the Gallium3d-driver was done one should be able to just use the OpenGL 2.1 etc state-trackers on it. Is this really something we can expect to be working in the foreseeable (say 3 months) future? If so then development is much faster than I anticipated.

[bridgman]

I read the matrix but i do not understand what parts of the mesa driver are going to be replaced by the gallium driver. For example is it going to replace only the mesa 3d features or other parts of the matrix as well like XXA - EXA acceleration and xv - xvmc video support ? I don't really understand how gallium is working on the existing graphics stack.

The Gallium3D driver does two things :

- replaces the existing Mesa HW driver API with a new API designed around programmable shaders rather than a fixed-function 3D pipeline
- provides a driver API which is sufficiently generic that it can be used for more than just 3D, eg EXA, Xv, video decode etc..

The most important thing to understand is that Gallium3D is not a replacement for Mesa itself, only for the HW driver layer inside Mesa (ie the src/mesa/drivers sub-tree). The upper level Mesa code (which is what actually implements the GL API) calls Gallium3D drivers rather than classic Mesa HW drivers.

There is a project in the Mesa tree called the xorg state tracker. This is an X driver which calls into KMS for modesetting and uses Gallium3D for EXA and Xv acceleration. The xorg state tracker (aka st/xorg) is the "missing link" which plumbs the non-3D parts of the graphics stack into Gallium3D.

http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/xorg

You would need to configure X to use the "xorg state tracker" driver rather than your existing X driver (radeon/radeonhd).

Also i want to ask why there is no gallium on r100 chips?

The Gallium3D API is designed for shader-based GPUs starting with approximately DX9 functionality. The R300 was the first ATI GPU with DX9-level shaders. The R100 basically had no programmable shader hardware. The R200 had a fixed function pipeline *and* DX8-level shader hardware. Right now the plan is to support r300 and up with Gallium3D, then go back and look into whether a subset of Gallium3D could be useful on older parts.

So what does this mean? Does this get us OpenGL >= 2.0 (and most importantly GLSL) now?

GLSL is somewhat orthogonal to Gallium3D. The shader compiler is common between classic and Gallium3D drivers; nhaehnle has been looking into adding the necessary support for GLSL to the shader compiler but I think there's still a fair amount of work to be done. In theory the rest of the GL 2.x functionality should come along more or less for free with a Gallium3D driver but I expect every new GL feature will require some fixing.

The most important milestone, however, is getting 300g to the point where 3xx-5xx users can switch over to using the Gallium3D code as their primary 3D driver - IMO that's the point where you'll see all the developers pile onto Gallium3D and work there rather than on the classic mesa driver.

That is also the point where it seems to make sense to start merging the classic r600 driver and Gallium3D 300g driver to make a 600g driver. In the meantime, Richard is working on adding support for flow control instructions to the 6xx/7xx shader compiler as a first step to supporting GLSL on the 6xx and higher parts.

[Eosie]

In theory the rest of the GL 2.x functionality should come along more or less for free but I expect every new feature will require some testing and fixing.

However, there is a little problem. As far as I know, r3xx-r5xx does not fully support non-power-of-two textures (e.g. the repeat wrap mode and mipmapping) and it is the prerequisite for GL2.0. If r300g gets GL2.x, this will imply falling back to software rasterizer in some situations, as was done in the proprietary drivers, am I right? Or will developers stick to GL1.5 + GLSL? I guess violating the GL spec in order to get GL2.x is out of the question, but that would be a pleasant solution in practice because people could use a newer GL API than what they have now.

[smitty3268]

However, there is a little problem. As far as I know, r3xx-r5xx does not fully support non-power-of-two textures (e.g. the repeat wrap mode and mipmapping) and it is the prerequisite for GL2.0. If r300g gets GL2.x, this will imply falling back to software rasterizer in some situations, as was done in the proprietary drivers, am I right? Or will developers stick to GL1.5 + GLSL? I guess violating the GL spec in order to get GL2.x is out of the question, but that would be a pleasant solution in practice because people could use a newer GL API than what they have now.

Isn't that the whole point of the "Softpipe pass-through" stuff that Michael said was marked done? Performance of apps that require that would be very bad but developers would just have to realize that can't be used on those cards, as I'm sure they already do. And the drivers would fully support GL2 - there's no requirement for doing it at any certain speed.

[Deagleson]

Good news for ATI owners then. :)
I have no clue what Gallium3D is (Better check Wikipedia ;) ), but i like improvements.

[Adarion]

Bwahaha, it's not the 1st time I regret a little to have only these modern R600 based chips. When I see all the goodness happening on R100-500 first. I guess I'll have to be patient a few more months.

[Eosie]

Isn't that the whole point of the "Softpipe pass-through" stuff that Michael said was marked done? Performance of apps that require that would be very bad but developers would just have to realize that can't be used on those cards, as I'm sure they already do. And the drivers would fully support GL2 - there's no requirement for doing it at any certain speed.

The history tells us not to believe Michael on these things. I highly doubt it's that easy to switch hardware/software rasterizer in real-time since a GPU must share the same data with a CPU, which cannot be done without endlessly moving data around. I'd like someone informed to clear that up.

[rohcQaH]

The history tells us not to believe Michael on these things.
A good way to deal with phoronix news is to click on every link that doesn't lead back to phoronix and read them. Most of the time, the news contain no more than a short summary of the linked article, and sometimes Michael rushes the news and gets it wrong.

Now I'm not expecting him to be fault-free or an expert in anything he's writing news about. In fact I enjoy the aggregate news, if only to click on the links. I just wish there was a way to prevent the ensuing forum-drama every time something's off :D

[Zhick]

However, there is a little problem. As far as I know, r3xx-r5xx does not fully support non-power-of-two textures (e.g. the repeat wrap mode and mipmapping) and it is the prerequisite for GL2.0.
Well, ATi Catalyst is able to pull it off somehow, so I guess it's actually is not that a big problem.

[smitty3268]

Well, ATi Catalyst is able to pull it off somehow, so I guess it's actually is not that a big problem.

Couldn't the drivers just treat any non power of 2 texture as the next power of 2 size larger? It's not a great situation to have a 600px texture treated as a 1024 pixel one, but that seems like a relatively simple solution.

[Maxim Levitsky]

And in meanwhile, gallium3d i965 driver was removed....

[Ant P.]

A good way to deal with phoronix news is to click on every link that doesn't lead back to phoronix and read them. Most of the time, the news contain no more than a short summary of the linked article, and sometimes Michael rushes the news and gets it wrong.

Now I'm not expecting him to be fault-free or an expert in anything he's writing news about. In fact I enjoy the aggregate news, if only to click on the links. I just wish there was a way to prevent the ensuing forum-drama every time something's off :D

Seriously. It's gotten to the point where I went and used userCSS to highlight the offsite links in articles because finding the actual content was so hard.

[elanthis]

Also i want to ask why there is no gallium on r100 chips?


I believe Gallium pretty much requires modern hardware. It's designed around how all modern cards work (programmable pipelines) instead of the fixed function pipelines of older graphics hardware.

The hardware types are so different there's really no way to come up with a sane driver architecture for both.

[madman2k]

has anybody tried already to run the Gallium3D based drivers and can provide some experiences?

[MostAwesomeDude]

I'm very tired (just got off the road after a couple hours) so I'll respond without quoting.

This status update is to reflect that r300g is pretty much done in terms of structure; nearly all remaining issues are blocker bugs rather than the result of shoddy or incomplete code. I mainly wanted to nuke the individual rows since the GalliumStatus page has those already, and in greater detail.

As far as I know, nobody, including myself, has started work on r600g. The current code should permit software passthrough without modification, provided that one is running the r600 KMS/CS kernel, but I have not actually verified it so it is listed as incomplete.

Gallium requires shaderful cards. r100g is impossible, r200g could happen if somebody writes the shader->FF auxiliary code required. (I wouldn't recommend it.)

r600g required KMS, GEM/TTM, and CS, just like r300g. (DRI2 only; I didn't want to bend backwards to support old, fail interfaces.) Now that the r600 KMS/CS code is there, and nearly stable, the biggest blocker is that I'm waiting for the cash to send away to Newegg for a PCIe motherboard to replace my old fried one. Then away we'll go, to the land of Gallium.

Dave, Nicolai, and I, talked about NPOT. In a nutshell, we can do rectangles but not NPOT, which technically means that full HW-accelerated GL 2.0 is not possible on r500. So, why does fglrx advertise it anyway? Simple. fglrx lies and advertises GL 2.0 (for the GLSL entrypoints) without actually advertising the NPOT extension. Bad fglrx, bad. Jakob and I are thinking that we'll either write out fallbacks in the state tracker, or we'll just lie like fglrx. One of the two.

i965g was nuked because it never actually worked. It never actually ran on real hardware, and was broken badly. Removing it helps people understand this, and paves the way for an eventual, non-suck i965g driver.

I think that's everything. Thanks for the questions, time for sleep now. :3

~ C.

[whizse]

Now that the r600 KMS/CS code is there, and nearly stable, the biggest blocker is that I'm waiting for the cash to send away to Newegg for a PCIe motherboard to replace my old fried one. Then away we'll go, to the land of Gallium.


Can't you set up a PayPal account (or something similar). Paying for hardware for you (and other developers) seems like the least we could do. :)

[MostAwesomeDude]

Can't you set up a PayPal account (or something similar). Paying for hardware for you (and other developers) seems like the least we could do. :)

Anonymous donors have already given me video cards in excess of the hardware I'm planning to buy, so don't sweat it. I'm just trying to keep a hobbyist thing (video drivers) from causing me to blow through all my savings. :3

[Pitabred]

Anonymous donors have already given me video cards in excess of the hardware I'm planning to buy, so don't sweat it. I'm just trying to keep a hobbyist thing (video drivers) from causing me to blow through all my savings. :3

If you want to pm me your address (if it's a suitable model), I have an older Gigabyte motherboard (http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=2579) with a Radeon x1250 embedded and a single PCIe slot on it and an Athlon X2 4600+ I'd be willing to send you gratis. I've got all the original packaging and everything. You'd have to pick up some DDR2 for it, but otherwise it's been a pretty decent motherboard. I just upgraded to a Phenom II X4 955, so it needed a new mobo but not new RAM. Only concern with Linux is the PMP code for the SATA chips on it. But I think it's fixed in recent kernels.

You can also hit me sometimes on AIM, "david is supar"

[yoshi314]

Full HW-accelerated GL 2.0 is not possible on r500i never knew that. i don't recall any tech review that said that. now i feel somewhat cheated.

[MostAwesomeDude]

i never knew that. i don't recall any tech review that said that. now i feel somewhat cheated.

You and me both, man. You an me both.

If it makes you feel better, we can emulate nearly all of it with fallbacks of various kinds; so far, I think the only case we're missing is repeating or mirrored-repeating NPOT texturing with custom mipmaps, which nobody would ever do because NPOT mipmaps are so expensive, and even then, it'll still look close enough for just about any regular use.

Everything else *should* be handled in the state tracker. This is part of the Gallium fun -- things the pipe driver can't do, the state tracker can handle itself.

[nhaehnle]

Corbin aka MostAwesomeDude said pretty much everything that needs to be said. From my side, GLSL support is progressing, if slowly. However, I doubt we'll be able to recommend r300g for common use in the Mesa 7.7 timeframe.

What we really need is developer manpower. If you're curious about this stuff, try running r300g and fixing one of the many problems that Piglit reports. Once we have the majority of Piglit tests running, there's a fair chance that complex apps (Compiz, games) have reasonable support. So get out those debuggers, or don't get your expectations up too high, because this thing is still crawling full of seriously bad bugs.

[quintesse]

If you're curious about this stuff, try running r300g and fixing one of the many problems that Piglit reports

I wouldn't mind, but I guess I won't be of much help (yet) with my r600 based card?

[nhaehnle]

I wouldn't mind, but I guess I won't be of much help (yet) with my r600 based card?

True, this is R300-R500 only at the moment.

[Zajec]

What we really need is developer manpower. If you're curious about this stuff, try running r300g and fixing one of the many problems that Piglit reports. Once we have the majority of Piglit tests running, there's a fair chance that complex apps (Compiz, games) have reasonable support. So get out those debuggers, or don't get your expectations up too high, because this thing is still crawling full of seriously bad bugs.Unfortunately you lack manpower, and ppl who could involve in Mesa lack documentation. You work on drivers, nobody have time to create howtos, and ppl can't start working on drivers without howtos. We have some sad loop there :(

When I decided to hack on radeonhd to improve something I found:
http://wiki.x.org/wiki/Development/Documentation/
especially:
http://wiki.x.org/wiki/Development/Documentation/HowVideoCardsWork
which have me some idea how modesetting is made.

Unfortunately I can't find any such a nice howto on 2D, Xv or 3D. I've heard many times "read the driver/code" and I agree it's kind of way of learning, but... not without any knowledge.

When I read /HowVideoCardsWork/ I knew what is VRAM, CRTC, PLL and driver code made sense to me. It's hard to read it without basic knowledge. You don't even know where to start.

It would be nice if you could guys think about some documentation on how 2D/Xv/3D works. This won't give you any new developer in a months, but maybe some ppl will able to produce single patches for little issues.

[mdias]

Unfortunately you lack manpower, and ppl who could involve in Mesa lack documentation. You work on drivers, nobody have time to create howtos, and ppl can't start working on drivers without howtos. We have some sad loop there :(

When I decided to hack on radeonhd to improve something I found:
http://wiki.x.org/wiki/Development/Documentation/
especially:
http://wiki.x.org/wiki/Development/Documentation/HowVideoCardsWork
which have me some idea how modesetting is made.

Unfortunately I can't find any such a nice howto on 2D, Xv or 3D. I've heard many times "read the driver/code" and I agree it's kind of way of learning, but... not without any knowledge.

When I read /HowVideoCardsWork/ I knew what is VRAM, CRTC, PLL and driver code made sense to me. It's hard to read it without basic knowledge. You don't even know where to start.

It would be nice if you could guys think about some documentation on how 2D/Xv/3D works. This won't give you any new developer in a months, but maybe some ppl will able to produce single patches for little issues.

+1.

I tried helping before, and failed exacly because of this. I don't know where to start.
I'll be reading those links now, they seem to be full of great info I've never been able to find before.

Thanks! :)

[pvtcupcakes]

Unfortunately you lack manpower, and ppl who could involve in Mesa lack documentation. You work on drivers, nobody have time to create howtos, and ppl can't start working on drivers without howtos. We have some sad loop there :(

When I decided to hack on radeonhd to improve something I found:
http://wiki.x.org/wiki/Development/Documentation/
especially:
http://wiki.x.org/wiki/Development/Documentation/HowVideoCardsWork
which have me some idea how modesetting is made.

Unfortunately I can't find any such a nice howto on 2D, Xv or 3D. I've heard many times "read the driver/code" and I agree it's kind of way of learning, but... not without any knowledge.

When I read /HowVideoCardsWork/ I knew what is VRAM, CRTC, PLL and driver code made sense to me. It's hard to read it without basic knowledge. You don't even know where to start.

It would be nice if you could guys think about some documentation on how 2D/Xv/3D works. This won't give you any new developer in a months, but maybe some ppl will able to produce single patches for little issues.

AMD released a bunch of documentation, but I don't know where you can find it. I believe bridgeman worked on it.

[Zajec]

AMD released a bunch of documentation, but I don't know where you can find it. I believe bridgeman worked on it.Hm, I thought they released only chipsets programming docs. Like "Put 0x01 to register 0x5000 to enable CRTC1".

AFAIK all they released is available on: http://www.x.org/docs/AMD/

Will browse that in free time. For now I've checked R6xx_R7xx_3D.pdf and it seems to explain for ex. what CP is. That can be really nice document. Now I think we still need some Mesa API documentation. Does anyone how about such?

Thanks a lot for pointing that docs, it may be really useful.

[agd5f]

Things like Xv using textures is a basic example of a 3d operation (drawing a textured quad). This post explains it:
http://www.botchco.com/agd5f/?p=22
and can be extrapolated to other 3d operations. The basic idea is:
1. set up engine state (textures, render buffers, shaders, etc.)
2. send verts for primitives or setup vertex buffer
3. issue draw command
These guides explain how to set up the 3d pipeline of AMD GPUs:
http://www.x.org/docs/AMD/R5xx_Acceleration_v1.3.pdf
http://www.x.org/docs/AMD/R6xx_R7xx_3D.pdf
Looking at some basic GL apps/tutorials is a good starting point.
these posts give some basic info on the AMD GPU architecture:
http://www.botchco.com/agd5f/?p=14
http://www.botchco.com/agd5f/?p=15
http://www.botchco.com/agd5f/?p=16
http://www.botchco.com/agd5f/?p=17

[nhaehnle]

Indeed, documentation is a problem. For those who are interested in Mesa: do you know OpenGL? Knowing about OpenGL is kind of a prerequisite, unfortunately, and I don't see a way around it. Once you know OpenGL, a lot of the terminology etc. should already make more sense.

Apart from that, if you seriously want to get into it and get stuck in some place, maybe you can just ask? I'm sure we'll be able to answer questions, if you promise to the produce patches that add useful comments. After all, I don't even know *where* you get stuck, so how can I write better documentation? It's not impossible, just very difficult, and I'm not convinced that it's the best way for me to spend my time.

[BlackStar]

Indeed, documentation is a problem. For those who are interested in Mesa: do you know OpenGL? Knowing about OpenGL is kind of a prerequisite, unfortunately, and I don't see a way around it. Once you know OpenGL, a lot of the terminology etc. should already make more sense.

Apart from that, if you seriously want to get into it and get stuck in some place, maybe you can just ask? I'm sure we'll be able to answer questions, if you promise to the produce patches that add useful comments. After all, I don't even know *where* you get stuck, so how can I write better documentation? It's not impossible, just very difficult, and I'm not convinced that it's the best way for me to spend my time.

Is there a list of todo tasks WRT Mesa? How do we set up a development and testing environment? Where do we post patches? (they seem to get ignored in the bugtracker) What license must they be in?

In my experience, there's a big difference between "start coding and ask if you have any problems" and "here's what we need, here's how you start, ask if you have any problems". Such a guide wouldn't take more than a couple of hours to write and, unlikely as that may seem now, it will help people get involved.

Some developer guidelines (http://www.mesa3d.org/devinfo.html) are here. Add a few notes on the dev and review process (i.e. "post a bug at http://foobar.com and attach your patch there" or "subscribe to mesa-dev and post your patch there"), add a couple of todo items (i.e. "implement ARB_foo_bar on R600") and you'll have a good starting point for contributors.

Edit: I'd also love a rough overview of how the OpenGL state tracker works. I have a rough idea of the dispatching mechanism but I haven't seen any documentation on the who (what, where and how) tracks the actual GL state.

[Zajec]

Edit: I'd also love a rough overview of how the OpenGL state tracker works. I have a rough idea of the dispatching mechanism but I haven't seen any documentation on the who (what, where and how) tracks the actual GL state.+1, please. I god some short conversation about this on IRC but would like to see this explained once more in more suitable form.

[agd5f]

The basic idea is that mesa manages state and provides driver callbacks where the driver can hook in hardware specific functions. The driver updates the hardware state in those functions and flushes command buffers to the GPU as needed. For example, in the r600 3D driver, see r700InitStateFuncs() at the end of r700_state.c; you can see the driver specific state callbacks registered there. r700BlendColor updates the hardware blend color state. mesa calls the the BlendColor driver callback when the GL app changes the blend color state. Next lets looks at r700BlendColor. First it calls R600_STATECHANGE which marks the blend color state as dirty so that when the updated command buffer is sent to the hardware we make sure to include the new blend color. Next the driver updates its copy of the blend color state regs (r700->CB_BLEND_*) with the new blend color from mesa (cf[4]). Finally when either the accumulated state gets big enough or the driver flush function is called, the driver's copy of the register state is written to a command buffer and send to the GPU. If the blend color was updated (and henced marked as dirty), r700SendCBBlendColorState in r700_chip.c would eventually be called. It appends the new blend color state to the command buffer.