hi, and greets to the noble PD forum dwellers (first post and all).

this is an attempt to classify the fitness of some PCI 3.3V cards for use with the EFIKA. this topic partially stems from the original PD thread Debian 4 freezes on PCI Radeon 9250, but is targeted at the EFIKA platform. it also has to do with the fact that my brand new EFIKA has been sitting on my desk video-less for a few days now, and that as of today it seems PCI 9250-based boards are easier to find than their AGP counterparts.

first, i encourage anybody reading this who's successfully paired an EFIKA with a 9250 PCI board, to step up and openly admit it.

from there on, assuming there is such a thing as a 9250 3.3V PCI board, and that it's not all some universal, cruel joke, the following candidates have passed the preliminary round (i.e. intense googling):

Visiontek Xtasy Radeon 9250 PCI 128MB & 256MB DDR
Diamond Stealth Radeon 9250 PCI, 256MB DDR
ATI Radeon 9250 PCI, 256MB

of the above, the first one is openly advertised as 'requiring 3.3V PCI', and the remaining two exhibit 'universal', i.e. double-keyed, PCI connectors, bringing to the thought that they might just as well work on a 3.3V bus. as exhibits, i apply random commercial product pages with close-up photos of those boards:

diamond
visiontek
ATI

i would appreciate your comments on the above, and on the topic in general.

ps: i know of a local b&m that carries the above ATI, and unless i get urged against it, i plan to acquire that board and try it out on my EFIKA this very weekend.

update 0:

ATI Radeon 9250 PCI (256MB) works like a charm. tested with morphos 2.2 installation distro, and with openSUSE10.3, Xfce, Xorg radeon DRI drivers. sole drawback - only 128MB of the board's 256MB are usable - appears to be a common PCI issue. also, board was accepted by xorg only after the obligatory chipId tinkering. on the bonus side, tungsten's r200 DRI driver is rather nice.

ed: for some reason, though, i cannot get vertex shaders (ARBVP1) out of it, even though the same DRI set (different mesa, though) does vert. shaders on mac mini just fine (same RV280 core) :/ update 1:

as of mesa 7.2 + r200 DRI 6.8 support for ARB_vp1 is there (along with ATI_fragment_shader), but there is a major problem in the DRI driver edge, confirmed as of mesa 7.4.1 + r200 6.10:

driver's implementation of VBOs is not actually doing what it is supposed to, i.e. optimising buffer moves. rather, it treats all vertex arrays as volatile, constantly moving data over from host space across the peripheral bus. that leads to a major performance hit with sizable vertex buffers, particularly on PCI boards.

as it turns out, that stems from missing VBO memory management functionality from the DRI edge. issue is open, and i will be looking for a solution for my purposes (read: i'll be hacking something into the DRI edge), but hopefully a mainstream DRI solution will be out one day.

update 2:

well, what do i know, a mainstream DRI (actually DRI2) solution to the VBO problem (among others) is coming as part of the radeon-rewrite DRI branch, mainly addressing memory management and code reuse across the r100-r500 line. no need to hack anything into radeon_dri as very soon we will be able to just take latest mesa (and the kernel of the day, naturally) and enjoy the full potential of the radeon lineup.

the fact that i've been oblivios to this pleasant new development compels me to get to active testing of this new code. you can join in too!

http://www.phoronix.com/scan.php?page=n ... &px=NzIzOA

I would err strongly on the side of getting the Visiontek since the others may not be as "universal" as they seem (some board designers universally key the thing but don't put the appropriate level shifters on there).

It's much rarer that a card would not work in a 3.3V slot than, say, a 5V slot (I know of 10 PCI boards off hand which refuse to work in a 5V slot, the PCI XGI Volari V3XT is a great example. They are all universally keyed). Most PCI chipsets run at 3.3V and the level shifters near the edge connector will basically take anything between 3.3V and 5V and move it to 3.3V for the chipset.

Depending on the quality and choice of those components and how they are wired, and about a billion conditions related to signalling, it may work or it may not :)

The key is your friend, therefore. All 3.3V keyed cards must work at 3.3V in a 3.3V slot or they're violating even the earliest PCI bus specification.

_________________
Matt Sealey

thanks, Matt. from your reply, and from the fact that the visiontek, just like the other two, has a universal connector, i am inclined to think that:

* the visiontek does not properly step-down from 5V, thus is advertised as 3.3V despite the universal connector on the board.

* the remaining two are 3.3V-compliant with very hight probability (they use the same chipset as the visiontek), and possibly even 5V-compliant too, as they come from a somewhat higher profile vendors.

that second point is a pure speculation, of course, which would easilly crumble if the 9250 chip was actually running at an even lower voltage (quite likely the case, given it comes from an AGP family supporting bus voltages as low as 0.8V), and all boards would need to provide proper step-down conversion even from 3.3V inputs. in that case the fitness of their from-3.3V shifters would be the determining factor for their operability in an EFIKA.

ps: i'm yet to see a 3.3V-keyed 32bit PCI board in the wild. do such things exist in nature?

pps: i am sure it's become obvious by now, but to avoid any misunderstandings: i have zero experience in EE, as i'm a strictly SW guy. so if i said something EE-outrageous, don't hesitate to shoot me.

Right.
That doesn't mean anything really. Depending on how lazy they are with their design, or what market it's supposed to be sold to (desktop PCs generally have 5V PCI slots, so there is no point making a 3.3V card unless you intend it for server or embedded use - which they can "bump" the price on) it doesn't matter what chipset they use.

What you need to look for is the level shifters and how they are connected to the PCI edge connector. This is kind of difficult from a tiny online store photograph :D
Possibly but since it has to be PCI compatible it MUST tolerate a 3.3V I/O signalling environment, even if only to the point that it does not just burn instantly (it may not DO anything except not burn, though).
For embedded and server markets, yes.

I really don't think you will have a problem, but I don't actually HAVE any 3.3V PCI graphics cards (or, since I checked last night through the rack of random peripheral goodies I have next to my workstation at the office, ANY dedicated 3.3V cards or ones I am sure work in the Efika) to test at the lab so I am at a loss as to how I can help you check this out.

_________________
Matt Sealey

Down here in the southern hemisphere (Australia) 128MB, low profile, Radeon 9xxx series graphics cards are fairly easy to find. The only thing to note about them is that 128MB does seem to be the limit for these low profile cards and I suspect they're all 64 bit as opposed to 128 bit. I've acquired quite a few of these cards for the Efika systems I've built and I haven't had any trouble with them to date.

are those low profile cards PCI or AGP? otherwise yes, from what i've seen (and i did google *a lot* about those buggers) they all cap at 128MB.

thank you, guys, for your input so far. i belive i will have something to report back after this weekend.

ps: i really like the powercolor (AGP) from the genesi EFIKA photo gallery - seems to be well-built. which is no surprise given that powercolor are responsible for the designs of many an ATI consumer card, AFAIK.

I've only been paying attention to AGP cards but I've also seen PCI Radeons available.

ok, i guess i can report something, as little as it is.

the ATI 9250 PCI 256MB paired with my EFIKA has not been the source of a single problem so far, under the software i've thrown (well, tried to) at it this past weekend. which software, alas, has not been much - basically, morphos 2.2 install image was the most video-intensive environment i got on my EFIKA during that time; while morphos is an interesting piece of desktop os, its install image is not exactly a GPU's proof-of-character.

anyway, the video board has been functioning flawlessly, as little chance it may have been given to fail.

also, i just waned to let this out:

this past weekend was my first actual hands-on with an EFIKA; as of today, monday, 0010 hours, i can say that the EFIKA is a bloody-impressive little bundle of joy. i just wish i had come across it earlier. not because i will not get heaps of fun out of it in the years to come, but because of the time i could've been already doing that. also, big fat kudos to whoever is responsible for the OF in there. *salutes*

final verdict: efika + ati 9250 rock. i just wish my efika had 256MB too (the ati does, alas only half of that is usable) - that'd make xorg so much more enjoyable (and the hdd's life so much less frantic).

an off-topic, RTFM-style question:

how do i read the high-precision (33MHz?) timer?

ed: found the answer myself after reading the g2 reference manual.

so now that we are well past the 'will it work?' stage, the really interesting questions along this videocard are starting to appear. also, i hope you'll excuse the triple-posting, i could have edited one of the previous posts but i deem these new developments interesting enough for a bump. or even an own thread hijack ; )

first, a quick debrief to the situation at hand: with mesa 7.4.1 and ATI r200 DRI edge 6.10 all the functionality one could expect from a (t)rusty rv280 is in place, down to ATI_fragment_shader, etc. the DRI edge works as advertised, all the essential dri options (/etc/drirc) work as expected. in other words, my efika is in a realtime 3d shape. well, almost.

now, the 'welp!' part.

TCL (tansform/clip/lighting), or in other words, the vertex part of the pipeline, appears to be severely stalling. and by 'part of the pipeline' i mean the path starting from taking vertex buffers from user space GL, going through drivers, DMA engines, and up to landing the vertex data into local video memory, but not the actual TCL performance of the rv280 engine as that is known to be fine (bar a defective board).

now, i suspect plenty of things as potential culprits for the situation (including my own performance code, even though it produces orders-of-magnitude better results on another ppc hosting another rv280), but most of all i suspect the following things, so please press the buzzer if any of those sound like plausible explanations to you:

* non-preemptive kernel: the best performance i've measured so far was under the custom suse kernels, which were all preemptive, IIRC. since then i've changed the kernel at least twice (switched to crux along the way too), and changed Xorg/mesa/ati_dri twice too. the original xorg coming with suse 10.3 had really ancient ATI dri missing quite a few features, but it was performing more-or-less within the expecting ballpark. the second candidate (mesa 7.2.x, ATI dri 6.8, IIRC), previous to the current one, was grinding to a halt at ARB_vp1, and was already under a non-preemptive kernel, and the current one is the one i've been referring to in the original description, under kernel 2.6.28.5-Efika #3, as found in crux kernel configs, just with DRM modularization enabled.

* something along the 'DMA engines' carrying the PCI transaction: i've looked into r200_dri debug output (R200_DEBUG=all) and the driver does appear to be sending the vertex data to the videocard over a DMA-style comm protocol. moreover, the r200_dri does not seem to emit warnings, or try to fall-back at any stage of the process, contrary to my original assumption that it was falling back to software TCL. so, in this regard, is there a know condition where some kind of 'severe PCI bus stalling' could occur on the efika? btw, the dri's "fthrottle_mode" is set to '"Let the graphics hardware emit a software interrupt and sleep", which gives a small but clear performance edge over the other fthrottle modes under the present kernel config.

i'm asking these questions with the perfect understanding that they are not on the everyday efika user agenda, but in case somebody has actually bumped into that before, i would hate to miss something that could as well be established lore.

ps: yes, i've already spammed with similar inquiries both the crux boards and the mesa3d dev list.

I enjoy very much all your comments, even if I'm unable to understand all of them, thus unable to help. I hope you come across somebody at your same level.
In all, it seems you are enjoying this little computer called Efika. Kudos to you!

thank you, Juan. i guess i have a slightly non-typical attitude toward "low-power" platforms. whereas most people would ask 'Can I read my email on it?' my first question usually is 'How good is it for doing graphics development?'. in this regard, i believe (and i intend to actaully prove that) that the efika, when paired with a decent older-generation (pre-GL2) GPU, can be a viable graphics development and deployment platform.

btw, last night when i posted my observations and asked questions i was rather tired and did not phrase myself properly. particularly, the way i worded the PCI bus contention question, it implies that i've been trying to constantly send buffers over the bus, which is not the case, at least not on the part of my code.

still, though, further investigations indicate that even though i have not been doing this, the DRI edge may have been doing it on its own. i.e. according to R200_DEBUG=all output, the DRI does invoke the DMA area preparation routine for *each* draw i do, as if those were constantly-updated data, even though the vertex buffers employed are actually static (i.e. GL_STATIC_DRAW), and are indeed updated only once for the lifespan of the test app. so one'd expect the GL server (read: mesa + dri) to show some modesty in moving them around.

i've posted the question on the mesa3d-dev list, as i'm really curious to see what the guys there have to say about it.

well, another bump to this thread.

the TCL underperformance mystery has been unveiled. i've updated the OP with the crux, but for the curious, here's the mesa3d-dev thread on the subject:

[Mesa3d-dev] radeon r200 TCL in xorg-video-ati 6.10

Does radeon-rewrite make it any better?

_________________
Matt Sealey

AFAICT fom the devs' plans, it should entirely fix it. and also introduce another much-needed buffer functionality too (i.e. FBOs). i'm yet to actually give it a try, though, as i need to make some preparations first. if everything goes to plan i should give it a run this weekend.