Page 4 of 4 FirstFirst ... 234
Results 31 to 39 of 39

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

  1. #31
    Join Date
    Oct 2008
    Location
    Poland
    Posts
    183

    Default

    Quote Originally Posted by nhaehnle View Post
    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/D...VideoCardsWork
    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.

  2. #32
    Join Date
    Feb 2009
    Posts
    161

    Default

    Quote Originally Posted by Zajec View Post
    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/D...VideoCardsWork
    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!

  3. #33
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote Originally Posted by Zajec View Post
    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/D...VideoCardsWork
    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.

  4. #34
    Join Date
    Oct 2008
    Location
    Poland
    Posts
    183

    Default

    Quote Originally Posted by pvtcupcakes View Post
    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.

  5. #35
    Join Date
    Dec 2007
    Posts
    2,371

    Default

    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
    Last edited by agd5f; 10-12-2009 at 06:42 PM.

  6. #36
    Join Date
    Aug 2008
    Posts
    77

    Default

    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.

  7. #37
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,144

    Default

    Quote Originally Posted by nhaehnle View Post
    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 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.
    Last edited by BlackStar; 10-13-2009 at 04:21 AM.

  8. #38
    Join Date
    Oct 2008
    Location
    Poland
    Posts
    183

    Default

    Quote Originally Posted by BlackStar View Post
    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.

  9. #39
    Join Date
    Dec 2007
    Posts
    2,371

    Default

    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.
    Last edited by agd5f; 10-13-2009 at 11:12 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •