ossman: agd5f, the way the other code was written, it looked like it was up to the next user to properly set the state up
ossman: what is it that gets messed up?
Nille: to what mailing list do i post an bug about xf86-video-ati ?
dmz0: gn8
bridgman: nille; either post a bug on Bugzilla (which sends mail to the list automatically) or post to the xorg list
bridgman: bugs.freedesktop.org
Nille: ok thanks brdgman
Nille: s/brdgman/bridgman
bridgman: no problem; I'm not wearing my glasses so thought you spelled it right anyways ;)
bridgman: anything past about 2' is a blur ;)
Nille: pass bridgman some glasses
bridgman: tx ;)
airlied: benh: bad permission or wrong libGL?
adamk_: airlied, Anything important in the recent ati driver update in F10? :-)
agd5f: ossman: IIRC, we had to fix the r5xx bicubic code similarly. I'd have to double check how we did it there. probably moved additional 3D state setup to exa preparecomposite()
ossman: agd5f, it seems more efficient to init it at each user
ossman: otherwise you have both an init and a teardown for each video frame
ossman: in a perfect world we would have some kind of on-demand reinit
ossman: agd5f, I don't suppose any such code is in the works?
ossman: it's a bit of a waste having to reinit the pixel shader each frame
glisse: ossman: we will reinit stuff way more often in cs world
glisse: you reinit at each frame
glisse: well each ib
glisse: what would be needed is way to batch things when we can like doing several frame in one ib and storing result in different buffer
agd5f: ossman: if there is enough room we could store several shaders on the card and switch at render time, but we only have so many slots
agd5f: ossman: we could also set a state flag so we only re-init the additional state if another accel call has been called between
ossman: agd5f, I was thinking more along the lines of the latter, yes
ossman: in the case of watching full screen video
ossman: most of the time the state will not have been overwritten.
ossman: at least when you have an htpc without a desktop doing lots of funny business in the background
agd5f: ossman: this almost fixes the fp restore issues: http://www.botchco.com/alex/xorg/restore_us.diff
agd5f: still missing something
agd5f: when using bicubic
ossman: agd5f, you need to resture the texture instructions me thinks
ossman: look at the non-bicubic code path changes
agd5f: ah yes
ossman: those should probably be removed from init3d then?
ossman: so that people don't get a false sense of security :)
agd5f: yeah, moved into exapreparecomposte()
ossman: was that the only problem with the bicubic stuff?
agd5f: I'll fix up the patch now
agd5f: yeah
ossman: so trunk? :)
agd5f: yup
agd5f: :)
ossman: wee
ossman: now it's just the vsync stuff
glisse: ossman: for vsync we really want to shorten the area we wait for
glisse: so we don't stall the cp too long
agd5f: ossman: http://www.botchco.com/alex/xorg/restore_us.diff
agd5f: fixes it. time to merge I think :)
ossman: glisse, do all radeons have just the single command fifo?
agd5f: ossman: yup
ossman: bummer
ossman: merge away
glisse: ossman: it's not only fifo problem, it's mostly context problem
glisse: what we would need is a fast hw context switching
glisse: somethings like context preemption
ossman: changing that value on the fly is a bit problematic though, as it is part of the crtc setup
glisse: ossman: which value ?
glisse: the waiting area ?
ossman: yes
glisse: it's not part of the crtc setup
glisse: it's just happen that the reg is in the same area
ossman: it is one of those regs that it stores and restores on vt switches at least
glisse: you can change it often in the place where you pick the crtc for instance
glisse: ossman: well just don't worry too much about it, just try to write it in cmd buffer before the wait_until
glisse: should work flawlessly
ossman: I'll give it a try
ossman: first I'd like to see it working on all generations though :)
ossman: so there are some r200 issues that need to be taken care of
ossman: agd5f, you didn't happen to test it on r500 as well?
agd5f: ossman: vsync or bicubic?
ossman: vsync
agd5f: not yet
agd5f: well, I've tested the vsunc stuff, just not the clipped triangle stuff
ossman: is this pipeline stalling as good as it gets, or is there a possibility of having something like a buffer flip with some more work?
agd5f: ossman: you can do buffer flips, but then you have deal with double buffering
agd5f: ossman: http://www.botchco.com/alex/xorg/exa_double_buffer.diff
ossman: that would give more performance though, as you could for example start DMA:ing the next frame while it is waiting to render the current one
ossman: and since I have performance problems, my vote is for double buffering :)
clodde: Hello, will the X1650 driver work in 3d on lenny out of the box or will i need to download xorg from experimental? I don't have the card yet so i don't know if it's RV530, 535 or 560
glisse: clodde: you need mesa 7.2 i think
glisse: so if lenny has mesa 7.2 you should be good
ossman: agd5f, I don't suppose you could teach that web server to server patches as text? :)
ossman: -r
agd5f: ossman: can do
clodde: thanks glisse, libgl1-mesa-dri 7.0.3-6 installed here...up to date lenny
ossman: I'm off home. bbiab
clodde: glisse, maybe mesa 7.2 will eventually be included into lenny?
jcristau: clodde: no
jcristau: because 1) it's too late, and 2) i need mesa 7.0 to build xserver 1.4
clodde: oh ok so i'll have to get that from experimental
agd5f: merged
oga: airlied?
ossman: agd5f, I'm not a big fan of keeping dead code around. shouldn't we just remove the exa vsync until it can be completed?
glisse: ossman: don't look at drm then ;)
ossman: heh
agd5f: ossman: we need the rest for Xv
agd5f: both use the same code
ossman: yeah, I meant as opposed to commenting out the calls
agd5f: yeah
agd5f: all though it's just 4 lines and we may want to actually implement it for exa at some point, but not a big deal either way
SimplePPC: agd5: about the 8500 again, i remember that we didnt get overlay working in the beginning on that card because the bios didnt set some things
agd5f: SimplePPC: possible
SimplePPC: and that was just 2d
agd5f: SimplePPC: the overlay code in radeon works, so that's a good reference
agd5f: SimplePPC: generally the bios only sets up modesetting and device specific stuff, everything else is up to the driver
SimplePPC: agd5f: the point is that the overlay code did NOT work on r200 but did work on rv250,rv280 because of the bios not setting up stuff
glisse: SimplePPC: i think you should not rely on bios setting up stuff
glisse: and should assume that bios doesn't do that
SimplePPC: well we fixed that eventually, but its not inconceivable that this is also with 3d fails...
glisse: SimplePPC: this is why i suggested you dump all reg and compare r200 and rv250 values
glisse: it might be somethings the bios initialize on rv250 and doesn't on r200
agd5f: SimplePPC: right. that why I suggested you look at the mesa code
agd5f: SimplePPC: you could have also looked at the radeon code for the overlay since that is working code as well on r200
agd5f: you generally can't rely on the bios for accel stuff
agd5f: since it doesn't really use it
ossman: agd5f, are you sure r300+ supports rectangles?
ossman: the docs say that 8 (rect) is unused as a primitive type
SimplePPC: may i ask something else about the ROM ?
agd5f: SimplePPC: sure
SimplePPC: is there a protection involved that prevents read or copying the rom on the radeon ?
SimplePPC: gf is calling me...
ossman: agd5f, or are you thinking about quad lists?
agd5f: ossman: maybe not
agd5f: ossman: I think r200 should though
ossman: agd5f, could you have a look in the docs? you who actually have them :)
agd5f: ossman: yeah 8 just like r100. IIRC, I tried rect lists previously on r200 and ran into some issue
ossman: comforting :)
ajax: r200 has hardware quads. r100 doesn't.
agd5f: yeah, but it also supports rects
ajax: oh, sure.
ossman: annoyingly, I have no r200 cards...
agd5f: which may end up being rendered as rects rather than 2 triangles
ajax: wow, i fixed that four years ago. i'm getting old.
ossman: agd5f, can you test patches if I prepare something?
agd5f: ossman: sure
ossman: ajax, there there :)
ossman: agd5f, patch or git tree preferred?
agd5f: ossman: your choice :)
ossman: agd5f, should I have a test for IS_R300_3D || IS_R500_3D if ChipFamily > R200 ?
ossman: or is that redundant
agd5f: ossman: depends on what you are doing
ossman: agd5f, well, 3d code
ossman: why is there no IS_R200_3D?
ossman: mixing IS_* and ChipFamily is a bit confusing for a newcomer like myself
ossman: agd5f, git://git.infradead.org/users/drzeus/xf86-video-ati#rect
agd5f: ossman: r3xx-r5xx are very similar
agd5f: so we have the macros to differenciate the places where they are different
agd5f: al the r2xx's follow the same path
ossman: so first you check family >= r200, then it's if (r300) {} else if (r500) {} else { /* r200 */ } ?
arekm: 4
ossman: bless you
agd5f: ossman: yeah
ossman: then ignore that repo :)
ossman: I guess there will be a lot of changes when r600 support is out?
agd5f: ossman: yeah, it's way different from the previous chips
SimplePPC: is there a protection involved that prevents read or copying the rom on the radeon ?
arekm: no
ossman: agd5f, ok, try that repo now
agd5f: ossman: cool I'll take a look
ossman: agd5f, http://homes.drzeus.cx/~drzeus/xvtest-1.0.tar.bz2
ossman: there's a test application if you want to check for a diagonal tear
ossman: then again, playing http://homes.drzeus.cx/~drzeus/apan.mp4 in mplayer is probably easier
agd5f: ok
agd5f: ossman: yeah, I remember now. using rect lists hangs the chip on r200
ossman: ...
agd5f: although your patch is wrong
agd5f: still setting prim type to quad list. let me change that
ossman: oops
ossman: agd5f, but if it hangs the chip, there's not much point continuing down this path
agd5f: ossman: IIRC, it works in mesa
ossman: k
ossman: unfortunately, I think that kind of development would require someone with proper access to an r200 card
ossman: so how do we proceed here? stick in a third code path and let r200 keep on tearing for now?
agd5f: ossman: let me try rect lists a bit more for r200 in the mean time
ossman: k
ossman: I can fiddle with restoring the scissoring
ossman: do you have a convenient test case?
agd5f: regular desktop, video in a window
ossman: is it enough to enable COMPOSITE, or do I need a compositor as well?
agd5f: no composite
ossman: this is a fairly bare machine, I have no normal desktop :)
agd5f: goes myth have a gui of some sort?
ossman: I use freevo. it uses SDL, and that works fine with this patch
agd5f: i see
agd5f: ok, rect list works
ossman: woot
ossman: and you see a horisontal tear?
agd5f: haven't tested tearing yet
agd5f: ossman: what is that video supposed to look like?
agd5f: apan
ossman: blinking black and white
ossman: it's usually fairly easy to spot tearing with that
agd5f: it does tear, but looks like horizontal
agd5f: it's sort of diagonal, but not at any fixed location or angle
oga: displayport hardware working ok?
ossman: agd5f, then it's probably rendering things properly in one pass
ossman: we'll work on that assumption and see if anyone complains :)
agd5f: :)
agd5f: btw, your tree needs this patch: http://www.botchco.com/alex/xorg/ossman.diff
ghepeu: hello
agd5f: I'll go ahead an merge it
ghepeu: a change in the radeon driver between october 18 and now caused a significant performance regression in x11perf
ossman: agd5f, on trunk?
agd5f: ghepeu: can you bisect it?
ghepeu: from 298kchar/s to 117kchar/s
agd5f: ossman: yeah switch to rect list
ghepeu: not in the next few days, sorry
agd5f: ghepeu: what card?
ghepeu: rv370
ossman: agd5f, can you push as well? then I can adjust my vsync patch with that as a base
ghepeu: pci-e
agd5f: yup
ghepeu: for what is worth, render_bench is stable (to the millisecond)
agd5f: ghepeu: any xserver upgrades in teh same period?
ghepeu: also, the drop with metacity (no compositor) is ~60%
ghepeu: with compiz "just" ~55%
ghepeu: non7top, nothing, I did the test just now, updating only the driver
ghepeu: *that was "no, nothing"*
ghepeu: still using xserver 1.4.2, if that's important
chithead: things sped up significantly on my rv410 after switching from xserver 1.4 to 1.5
ghepeu: I know, but at the moment I've got a full-time work, a dissertation to write and no time for upgrading
ghepeu: not to mention that my current setup is stable and I can't risk any kind of problem (lockups, etc.)
ghepeu: I used to regularly check git snapshots, and now I jumped from october 18 to december 4
ghepeu: these are the full results: http://pastebin.com/m52bad83c
airlied: oga: dp is on my/ajax list of things, just not gotten time to do bash it yet.
ghepeu: I ran the test 3-4 times, they gave always those numbers
ajax: and no, it doesn't work yet.
oga: airlied: thanks. I'm back on hardware advice for a friend. can't answer all the questions.
ajax: hoping to have it working by Fedora 11
ossman: agd5f, ok, scissoring problem fixed. care to push out the rect changes, and perhaps bicubic patches? I'll rebase on that
agd5f: ossman: done
ossman: danke schön
ossman: agd5f, any point in keeping scissoring setup in init3d, or should I remove it there like everything else?
agd5f: ossman: just remove it since it's set everywhere else explicitly
ossman: okay
ossman: removing code always brings a smile to my face :)
ossman: if a pixmap is not offscreen, does it have coordinates I can get at?
ossman: agd5f?
agd5f: ossman: it has an address
ossman: so if I know pitch, I should be able to compute the scanline
agd5f: yeah, you should be able to get the pitch and offset
agd5f: exaGetPixmapOffset() and exaGetPixmapPitch() for example
ossman: hm... but...
ossman: the wait function tests for offset == 0, which I guess means that we pass the frontbuffer as an argument there?
agd5f: 0 is the front buffer
agd5f: if we are drawing to the pixmap at offset 0, it;s the front buffer
ossman: so I can't get any info about target coords there...
ossman: I guess I'll have to add arguments
agd5f: you mean the video window coords? nope
ossman: I'm implementing glisse's request of waiting for just the relevant lines :)
agd5f: yeah, if you do that, we may even be able to make it useable for EXA
ossman: what's the normal way of sending a rect?
ossman: four ints, or some struct?
agd5f: shorts IIRC, but int should be fine
ossman: yeah, short should be sufficient. it was more of four args vs one struct :)
agd5f: either four args or a boxrec
ossman: agd5f, is the RADEONInfoRec per crtc?
agd5f: ossman: per driver instance, so per screen
ajax: no, it's per gpu.
ajax: oh, er, yeah, what alex said
agd5f: screen in the X sense, not the physical screen
ossman: hmmm...
ajax: i just pretend X screens are things there are only one of
ossman: but it has a currentMode
ossman: isn't that a per-crtc thing?
agd5f: ossman: yeah, that's legacy stuff
ossman: ok
m03sizlak: any solution for r300 + agp + fc10 + composite == HARD LOCKS yet?
airlied: m03sizlak: you try -61?
m03sizlak: no, i have 59 i think
m03sizlak: lemme try 61
airlied: I'm waiting for my agp r300 to arrive.
m03sizlak: ah, nice
m03sizlak: for what its worth im using a kernel.org kernel, will that matter?
airlied: ah so you aren't using modesettingh then
m03sizlak: no, but i hade same problems w/ the fedora10 kernel
m03sizlak: i just prefer to roll my own kernel
airlied: just with F10 at the moment, you will use a completely different codepath with the Fedora kernel adn the upsteram kernel
airlied: unless you boot with nomodeset
airlied: n the F10 kernl
m03sizlak: i cant boot the fedora kernel WITHOUT nomodeset
m03sizlak: botts to a black screen
m03sizlak: *boots
airlied: ah that might work better now with latest F10 kernel
m03sizlak: well then ill try -61 + newest fc10 kernel, and see what happens
airlied: but I should have an AGP card next week to play with more.
spstarr_work: hullo
m03sizlak: cool, thx
GoliatSkipson: hy ... i switched to the radeon driver some days ago ... but in some opengl applications only specific keys on the keyboard are working ... is this a known behavoir? (and hopefully a fix for it?)
ossman: avivo is the latest display controller stuff, right?
agd5f: ossman: yup
ossman: great. then you can test both the r200 and legacy crtc for me ;)
ajax: #define ATOM_ENCODER_CONFIG_LINKA_B ATOM_TRANSMITTER_CONFIG_LINKA
ajax: delightfully non-obvious
ossman: agd5f, git://git.infradead.org/users/drzeus/xf86-video-ati#vsync
ossman: please test on r200 :)
ossman: the exa vsync is currently disabled, but xv should work properly
agd5f: ossman: ok
ossman: agd5f, the way you've added the waits in the exa code, will they trigger even if the window is completely covered by another window?
agd5f: yeah, but the rendering won't be called if they are completely covered
ossman: ok, good
ossman: otherwise there might be some bad interactions with fullscreen video
ossman: where it waits for both the video, and rendering behind it
ossman: and the current xv code does not like it if you throw frames at it faster than it can get rid of them
nbaum: I gather from Google that GL_SELECT does not work with sofware fallback on r300. Is a workaround/fix known? The bug renders blender virtually unusable.
oga: airlied?
ossman: does anyone have any idea what kind of performance hit integrated graphics has on the rest of the system? The ramdac must be doing a lot of block of the ram
ossman: agd5f, any results?
agd5f: ossman: sorry, haen't had a chance to test yet
ossman: ok
ossman: I'm off to bed now, but irc will be left running if you have any results to shar
agd5f: ossman: will do
agd5f: ossman: helps a lot. we may need to adjust the vline stuff to handle the non-active parts of the display
airlied: oga: ?
oga: airlied: nevermind. spoke to agd5f about it
agd5f: ossman: this patch also it for exa: http://www.botchco.com/alex/xorg/radeon_vsync_exa.diff
agd5f: seems to work pretty well
agd5f: stalls aren't really noticeable
wojtek85: airlied: hello
airlied: wojtek85: hey... is the card AGP or PCIE?
wojtek85: PCIE
airlied: so accelmethod exa might be worth trying.
wojtek85: ok, could you tell me if I should change anything else in my xorg.conf? http://pastebin.com/m7042bfba
airlied: no should be fine with the EXA option in the Device section
wojtek85: airlied: right, I'll restart X and see what happens
wojtek85: airlied: no improvement I'm afraid
wojtek85: just to make sure - I am talking about performance while using compiz
airlied: can you pastebin your xorg log file and the output of LIBGL_DEBUG=verbose glxinfo when compiz isn't running
wojtek85: xorg log http://pastebin.com/m6913b03e
airlied: ah you are using Fedora.
airlied: compiz is slow on F10, we are working on getting the fix in, but it needs DRI2.
airlied: you can boot with nomodeset to see if gets faster.
wojtek85: yup, just installed it this morning after 3 years on gentoo
wojtek85: glxinfo http://pastebin.com/m5830a2a6
airlied: its on my list of things to fix, but I have to do some other tasks first.
wojtek85: airlied: cool, no rush mate :)
wojtek85: airlied: should I then wait for new version of radeon rather than radeonhd?
airlied: try the nomodeset on the commandline
airlied: kernel commandline.
airlied: it'll be a new Mesa that fixes it.
wojtek85: yeah, I know
frojnd: Hello there
airlied: it might have a new -ati as well depends on what I need to change
wojtek85: I am still confused by difference between radeon and radeonhd though - XVideo support for example
frojnd: Where are instructions to install open-source ati drivers ?
airlied: wojtek85: they pretty much support the same things on r500 cards.
frojnd: I have mobility x1400
airlied: frojnd: what distro, it might already have them
frojnd: airlied: opensuse
wojtek85: airlied: will nomodeset disable that fancy loading screen (Plymouth)? :)
airlied: wojtek85: though the kernel modesetting stuff in Fedora is pretty experimental so radeonhd doesn't support it yet.
airlied: wojtek85: yes.
wojtek85: ok will try now
airlied: frojnd: I think it already has the radeon drivers in it.
airlied: and radeonhd
airlied: it probably picks radeonhd by default
frojnd: airlied: radeonhd too :)
frojnd: hm... I use fglrx right now
frojnd: airlied: and it supports 3d ? and also dual-head and not tv out ?
airlied: yes 3D + dual-head, no tv-out yet
frojnd: airlied: is the 3d better than wwith fglrx ?
frojnd: I mean fpss
terracon: fglrx has the fps
frojnd: I mean the speed :)
frojnd: can I get better speed with radeonhd than with ati flrx ?
terracon: no
frojnd: How come ?
terracon: hmm I don't know the open source drivers have always been significantly slower than their proprietary counterparts
wojtek85: airlied: yeah, works much better now
wojtek85: airlied: though one thing confuses me - how come I have compiz and video running with no flickering?
wojtek85: does it mean I am not using TexturedVideo?
frojnd: terracon: that's odd... even now I have problems while compiz + watching movie, hack I can't even have xv output with players while watching movies, instead I have to have X11, which is slow... my graphic card sux (mobility x1400) or does ati fglrx drivers...
terracon: well radeon driver might be good for you 2d wise. 3d on the other hand ...
frojnd: terracon: so 2d is better supported with radeonhd than with ati fglrx ?
terracon: frojnd: I'm not sure. I haven't used fglrx in a long time. But didn't phoronix do some benchmarks recently
frojnd: terracon: haven't looked at phoronix lately
airlied: wojtek85: the flicker might happen with different sized videos, or you might be lucky :)
airlied: radeon will soon be best for playing videos hopefully.
airlied: if the all the work done in here on tearfree is anything to go by.
terracon: points his cursor on top of pr0n0.mpg in anticipation
agd5f: ossman, airlied: updated with options the turn it off and on: http://www.botchco.com/alex/xorg/radeon_vsync_exa_xv.diff
wojtek85: airlied: so I am lucky indeed - even fullscreen works perfect
wojtek85: any rough estimates on when these upgrades would come out?
airlied: wojtek85: depends on much time I can get on it, I've got non-fedora work to get finished first
airlied: and I'm not sure I can hack it without doing DRI2
wojtek85: airlied: okey dokey, will stay tuned to any announcements on phoronix
airlied: if it *needs* DRI2 then it'll be F11 first and backport to F10 hopefully
wojtek85: this is really awesome work - thanks so much for it!
scsiraider: airlied: ping
airlied: scsiraider: pong
scsiraider: im sure you are working on a new driver ;) so reporting this is probably useless, but i can get a pretty reproducable hardlock using your branches
scsiraider: all i have to do is enable desktop effects in kde4
scsiraider: so its probably compositing related
airlied: scsiraider: kde worked around some issues,
airlied: not sure where they got with that.
airlied: but maybe it was only desktop effects disable
airlied: not enable
scsiraider: the bug in the driver or in kde code?
airlied: its a bug in r300 but could be worked around in the kwin code.
airlied: but I think its was only likely on disable
airlied: I know spstarr has played a bit with KDE4 on this stuff but I'm not sure what his last report was
scsiraider: well i dont have any issues with it off
spstarr: looks at koji
pm--: i need help getting my new x16 radeon 3450 256 meg video card to work in freebsd
pm--: so far, the vesa driver works best in xorg.conf
pm--: but mplayer wont mplayer in full screen unless it uses -vo gl driver, which is too slow
pm--: radeon driver hasnt worked yet
pm--: ati driver works but i get like, 8 bit color
airlied: ati == radeon (unless you mean fglrx)
pm--: in 1280/1024 mode with 17" moniter
airlied: VGA or DVI monitor?
pm--: vgs kds crt
pm--: vga
airlied: hmm should work with radeon, can you post Xorg.0.log from radeon maybe?
pm--: kds xflat
airlied: we might not support all the digital bits but the VGA should work.
airlied: what version of radeon you using?
pm--: 3450
pm--: saphire
airlied: no the driver? just whatever BSD ships?
pm--: oh. yeah whatever i get with xorg
pm--: i pkg_add xorg onto freebsd 7
airlied: its probably 6.9.0, which may or may not be new enough, can you pastebin /var/log/Xorg.0.log after starting with radeon?
pm--: yeah ill do that tomorow
pm--: xorg-7.3_2 X.Org complete distribution metaport
pm--: is what im running btw
airlied: does it have a separate -ati driver component?
pm--: well, in the xorgconfig script conffiging util, it has a radeon chaice in addition to the more general ati driver
pm--: er is that not what you were asking about
airlied: they should call the samwe thing.
airlied: but I'm not sure how BSD packages the drivers.
airlied: pm--: rnoland_ might be able to tell better, he does BSD packaging.
rnoland_: heh?
pm--: well its near beed time fo rme, but tommorow ill swap the drivers around and pastebin some about and maybe that will give us some clues
airlied: rnoland_: FreeBSD -ati driver version? when he has xorg-7.3_2 installed
airlied: I don't know the magic incantations
rnoland_: if it's current ports... it's 6.9.0
pm--: in freebsd and xorg when you do a `startx` without an existing conf, it fires x up using the drivers it thinks are best. it doesnt bother writing a conf
pm--: and the verbose console output when i do that, says it uses the generic-ish ati driver, so im worried there is a reason why it doesnt use its radeon driver for an obviously radeon card
rnoland_: pm--: i'll take your word for it... never tried that...
airlied: pm--: -ati is a wrapper around -radeon
rnoland_: ati isn't a driver...
airlied: and -r128 and -mach64
pm--: oh
rnoland_: ^^ yes, its just a wrapper that loads r128 or radeon...
rnoland_: oh yeah, mach64...
rnoland_: pm--: xorg.log should show what is actually being loaded..
rnoland_: heh, finally found an unpatched ports tree... yes it is 6.9.0 for xorg 7.3_2
pm--: rita# pkg_info | grep 6.9
pm--: xf86-video-ati-6.9.0 X.Org ati display driver
pm--: ooh
pm--: im kinda slow, i dont do computers for a living im a carpenter
pm--: .me part timer
rnoland_: airlied: 3450 is an r600 isn't it?
rnoland_: pm--: we have all new xorg ready to go... as soon as 7.1 ships...
rnoland_: pm--: if that is an r500 chip, it should work good with the new xorg...
rnoland_: if it's an r600 it's not fully supported yet...
airlied: yes rv6xx of some sort.
rnoland_: pm--: i have a semi recent patch for the ports tree at http://people.freebsd.org/~rnoland/xorg-7.4-111608.patch
pm--: ok thanks all for yur help. ima idle and attack this tomorow