udovdh: slightly related question:
udovdh: what is the pciE clock for my pciE 2.0 EAH 3650 (rv635) card?
udovdh: and how does the pciE clock relate to the data transfer speed?
udovdh: 2.5 GHz for pciE 2.0 giving 5 GT/s
udovdh: so what clock do I set for my 3650?
edman007: udovdh, the gpu speed shouldn't really relate to the PCIe speed
edman007: if anything it should relate to the VRAM speed
edman007: PCIe is much slower then either of em
edman007: PCIe 2.0 16x is ~8GB/s, the VRAM on a 3650 is 12.8GB/s...and thats a slow card
udovdh: edman007, yes, of course, but I want to udnerstand how the 100 MHz goes up to the 2.5 GHz for 2.0 pciE
udovdh: I don't see a multiplier setting
udovdh: on the other hand:
edman007: there is none...
udovdh: any interesting radeonhd updates? ;-)
edman007: PCIe has a specific speed per lane (depending on the version)...
edman007: udovdh, http://en.wikipedia.org/wiki/PCIE
udovdh: so you imply a locked multiplier
udovdh: depending on card capabilities
udovdh: I did see the wiki article
udovdh: annd the Specs for each generation per lane table doesn't say everything
udovdh: just higher level info
udovdh: but it's Ok
udovdh: thanks
edman007: udovdh, multiplier for what?
edman007: the datarate of of the bus is locked to the clock by the paraity, yes, but the GPU is not bound to the PCIe bus is any way (from what i know), since overclocking video cards does not require the bus to be overclocked at all
edman007: take for example all the stock overclocked video cards, they are all overclocked from the stock settings, its not a multiplier in there for the GPU at all, the whole assembly is separate from the PCIe bus, its all about communicating to the VRAM
edman007: anyone hear anything about R600 docs yet? is phoronix going to give me accurate info about it? they said before x-mas...
airlied: edman007: nobody really knows.
edman007: cries
edman007: decides to email amd and see what happens
edman007: ...maybe
bridgman: edman007; ping
bridgman: anyways, you can email me; first.last at amd.com (first name john)
bridgman: but the reality is that even we don't know until we get a package that everyone agrees is ok to release
bridgman: I think we're close, and we have some working code to go with it
bridgman: schedule is "it'll be done when it's done"
bridgman: but we also want it done sooner rather than later ;)
bridgman: when it happens phoronix will know about it
edman007: bridgman, alright, well thanks for the info
bridgman: no prob; it's a lot easier to schedule development work than to schedule IP release, unfortunately
bridgman: or maybe it's just that I have a lot more experience scheduling development work...
edman007: lol