rainbyte: bridgman, with catalyst between 50~80%
rainbyte: and about 90% in fast moving parts
agd5f: rainbyte: you oculd try disabling the vline line stuff. xvattr -a XV_VSYNC -v 0
rainbyte: I'll try that after installing the driver again
rainbyte: agd5f, do you know if is it possible to have both (catalyst and xf86-video-ati) installed in Arch?
agd5f: rainbyte: no, you have to uninstall fglrx to use the open driver
rainbyte: agd5f, in Gentoo I had a script to enable one or the other at boot, but Gentoo has opengl-select
agd5f: rainbyte: depends what you man by haing them both installed at the same time. You'll need to replace a bunch of libs and reboot between using them
rainbyte: that's what I mean, because is easier to reboot and select the driver in the grubmenu than having to recompile the git stuff and unistall catalyst
agd5f: kdekorte, bridgman: replacing the waitforidle with a usleep does pretty much the same thing, so I think it's the delay that's the "fix"
rainbyte: agd5f, xf86-video-ati-git 20090816-1 would be ok (I have already compiled that version) ?
agd5f: rainbyte: yes
vehemens: i see several types of r600 corruption problems. 1) is the general mesa app corruption (vertex corruption?). 2) gnome menus + compiz have short random horizontal lines when the cursor is over the menu item (also leaves a trail). 3) gnome term + compiz characters don't display correctly when first typed (at cursor location). is this what everyone else is seeing?
chainsawbike: vehemens, yep
bridgman: I think I've seen all three
chainsawbike: there is at least one more
chainsawbike: enable reflection and then move a window
bridgman: I believe there is also 4) which is the white square in the top right quadrant of gears and other apps
bridgman: it might be "corruption of the back to front copy" I guess, ie 1)
bridgman: I was able to get the white square by adding an idle routine to redbook hello which constantly redrew the square
bridgman: tried rotating the square 45 degrees but the white intermittent flickering square didn't change shape
bridgman: if we can make phantom objects appear with a patched hello I wonder if that would be any easier to trap in the driver ?
vehemens: i see the white square and sometimes other shapes as well
bridgman: like triangles radiating up and right from the center of the window ?
vehemens: bridgman: yep
bridgman: "wow man, did you see it too ??" ;)
vehemens: just means were in the same rabbit hole
bridgman: wonder if it's time to start slowing down the driver with print statements again ?
bridgman: gotta use that speed for something ;)
bridgman: time for zzz, gotta be up soon
bridgman: morning dentist appointment 70 miles from home through Toronto rush hour ;(
rainbyte: hi
rainbyte: agd5f, I installed xf86-video-ati again
rainbyte: but now xvinfo gives me "no adaptors present"
rainbyte: and glxinfo says "OpenGL renderer string: Software Rasterizer"
agd5f: rainbyte: you need kernel 2.6.30 or newer
agd5f: and also you need to remove the fglrx drm module
rainbyte: Linux Haruhi 2.6.30-ARCH #1 SMP PREEMPT Fri Jul 31 07:30:28 CEST 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux
rainbyte: fglrx is not installed
agd5f: rainbyte: pastebin your xorg log
rainbyte: http://pastebin.ca/1533421
agd5f: rainbyte: (EE) Failed to load module "dri" (loader failed, 7)
rainbyte: I'm using drm from r6xx-r7xx-3d branch, could that be the problem?
agd5f: rainbyte: no
agd5f: you have a bad /usr/lib/xorg/modules/extensions//libdri.so
agd5f: maybe you still have old fglrx version
agd5f: or the file is missing for some reason
agd5f: dlopen: /usr/lib/xorg/modules/extensions//libdri.so: cannot open shared object file: No such file or directory
rainbyte: the file is there
agd5f: rainbyte: is it a symlink?
rainbyte: no
rainbyte: I'll try to reinstall xorg-server, maybe catalyst change that file
rainbyte: wait a second, I have to restart X
rainbyte: hi again
rainbyte: agd5f, now xvideo is enabled again
agd5f: rainbyte: good
rainbyte: and glxinfo gives OpenGL renderer string: Mesa DRI R600 (RV610 94C3) 20090101 TCL
rainbyte: agd5f, mplayer gives the same msg "your system is too slow"
rainbyte: I'll try the command you said "xvattr -a XV_VSYNC -v 0"
rainbyte: is that for disable vsync?
agd5f: rainbyte: yes
rainbyte: mmm, there is another thing
rainbyte: the screen goes black and returns again
rainbyte: is that normal?
agd5f: rainbyte: what do you mean?
rainbyte: like if it would be blinking
rainbyte: it happens sometimes, not always, but it is annoying
agd5f: rainbyte: shouldn't happen
rainbyte: mmm, agd5f mplayer says the same with vsync disabled
rainbyte: maybe the video is to big for xvideo
rainbyte: *too
rainbyte: and fglrx is a bit more optimized
agd5f: rainbyte: is fglrx using Xv too or GL?
rainbyte: xvideo
rainbyte: now I doesn't see a real difference
rainbyte: it doesn't lag anymore
agd5f: rainbyte: how does mplayer come to that conclusion?
agd5f: It might just make assumptions
rainbyte: I'm not sure, maybe because the last time it was using more cpu
rainbyte: agd5f, oks the video is not a problem anymore
rainbyte: but the screen is blinking
agd5f: rainbyte: pastebin you xorg log
agd5f: does it blink only when 2D/3D/video is active?
rainbyte: I don't have any 3D app running
rainbyte: and it was blinking before I run mplayer
rainbyte: I'm using E17 and I think that is making use of composite
rainbyte: http://pastebin.ca/1533435
agd5f: rainbyte: does it still happen if you disable accel? Option "DRI" "False"
rainbyte: I have to try that
rainbyte: agd5f, if I select some text when using kwrite, it blinks more frequently
agd5f: rainbyte: ok
rainbyte: agd5f, I don't know if it is related, but I tried radeonhd and X starts with a black screen
rainbyte: wait a sec, I'm restarting X
rainbyte: hi
rainbyte: agd5f, with Option "DRI" "False" screen stopped blinking
agd5f: rainbyte: ok, so it's probably watermark related
rainbyte: agd5f, what can I do to improve the situation? installing from git culd help?
rainbyte: *could
agd5f: rainbyte: I thought you were using the version from git
rainbyte: yes, but 090816
agd5f: no watermakr related changes in the last 2 days
rainbyte: ahh, ok, I thought that there could be some last minute change
agd5f: rainbyte: I've got a patch yo could try
rainbyte: mmm, oks, I have time to do it
agd5f: rainbyte: http://www.botchco.com/alex/xorg/avivo_displaypriority_high.diff
rainbyte: let's see...
agd5f: rainbyte: and add: Option "DisplayPriority" "HIGH"
agd5f: to the device section of your config
rainbyte: oks, wait a sec, I'm recompiling ^^
rainbyte: agd5f, is it for last git right?
agd5f: rainbyte: yeah, but it should apply to 090816 just fine
rainbyte: agd5f, it builded ok, I'm going to restart X
agd5f: rainbyte: ok
rainbyte: agd5f, here again
rainbyte: it doesn't blink now
agd5f: rainbyte: cool
rainbyte: agd5f, thanks for your help
agd5f: rainbyte: no problem
rainbyte: agd5f, the patch is going to be applied to master?
agd5f: rainbyte: yes
rainbyte: that's good ^^
rainbyte: agd5f, xf86-video-ati has support for hdmi audio or only radeonhd?
agd5f: rainbyte: only radeonhd at the moment
rainbyte: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=479a6daefe46f985c415b0d000b1b1b820f3924e <-- that was fast
mcgreg: I though radeon does support hdmi since alsa lists it here
mcgreg: +t
rainbyte: it is impressive to see glxgears working with oss drivers
mcgreg: non7top, it is impressive to see google earth working with free drivers :)
mcgreg: wtf
mcgreg: non7top, it is impressive to see google earth working with free drivers :) - it should be
mcgreg: erm
mcgreg: where does that "non7top" comesfrom
rainbyte: xD
rainbyte: neverball is working too
mcgreg: wtf why does chat make from a "no,..." a nickname ... weak.
mcgreg: oh
mcgreg: I did a wrong configuration ... lame ;)
mcgreg: rainbyte, a lot of 3d software works. just with graphical glitches and stuff
rainbyte: mcgreg, mmm, I see
rainbyte: I don't use much 3D, but I'm trying it for the 1st time with oss drivers
mcgreg: yeah. almost same here. it's a matter of principle though :) it is simply totally nice to see it :)
rainbyte: I wonder if the october distros will include it
mcgreg: there is only 1 game I play - which is 3d : WOW. I guess it will strill take a longer time untilm that one will be playble fine
mcgreg: if ever
rainbyte: mcgreg, so wine3d is not working ok with oss drivers?
mcgreg: hmm. not really yet as farv as I tested. not even warcraft3 works - more like wine3d doesnt detect oss rier as DRI capable here. it obviosly started it with software rasterizer
rainbyte: agd5f, do you think that oss drivers could be replace fglrx for workstation hardware at some time?
rainbyte: *-be
rainbyte: or oss drivers are only for consumer use?
mcgreg: rainbyte, I suppose he's not allowee to make such "guesses" :)
rainbyte: ahh, I understand, hehe
MAD|exhaustion: FireGL cards are identical to Radeons when it comes to the 3D engines.
rainbyte: MAD|exhaustion, mmm, the last FireGL is using rv770 core right?
MAD|exhaustion: rainbyte: Dunno.
rainbyte: and what about the driver optimizations?
rainbyte: is more important 2D or 3D for workstation?
mcgreg: it's more a mastter of certification of so. the firegl driver (fglrx) are - for industry
rainbyte: mcgreg, I understand that there are more workstation users than consumer that have AMD/Ati cards
MAD|exhaustion: The per-program optimizations are *not* that important.
MAD|exhaustion: Sure, they're required to reach fglrx levels of performance, but we can come within 98% or so of that, I'd wager, just by not sucking.
mcgreg: hehe
rainbyte: MAD|exhaustion, so oss drivers can be used for workstation too
mcgreg: seriously, I think you could be even better than fglrx:)
MAD|exhaustion: rainbyte: I don't see why not...
mcgreg: maybe notsimply by having a fater engine but by being less buggy :)
mcgreg: sry, diferent keyboard... makes me do even more typos
rainbyte: I ask because if that happens there will be even more interest in the oss drivers
suokko: funny bug: glxgears has red gradient back ground :)
zhasha: suokko: which driver?
suokko: None that you can use ;)
zhasha: r300g on r300 I take it
suokko: in other words r300 that I have modified
zhasha: you modified an actual r300 board?
DanaG: r300g? what's "g"?
zhasha: gallium
zhasha: instead of writing r300-gallium on all commits, we just call it r300g
nanonyme: suokko: Shouldn't it actually be transparent?
suokko: gears background? no. It should be black like always
airlied: osiris_: I've pushed my OQ rework, it passes on rv530 all test with and witohut tcl
airlied: the problem was emitting an end when we hadn't emitted a begin on no-tcl
mikkoc: airlied: it doesn't compile here: radeon_common.c:86:29: error: radeon_queryobj.h: No such file or directory
nanonyme: suokko: Iirc it turns transparent on software rasterizer with xcompmgr on and MostAwesomeDude hinted it might be using the wrong kind of black.
JediMaster: hey guys, ever since upgrading to 9.04 back when it came out my laptop's screen has been "jumping" with black lines whenever anything significant redraws the screen. The laptop is only 18 months old, it's got an ATI RS690M chipset and is using the radeon driver in Xorg.
JediMaster: sorry, ubuntu 9.04
airlied: mikkoc: try now
stikonas: airlied: compilation works now
airlied: hopes radeon/r200 run ;-)
airlied: goes to bed &
stikonas: airlied: radeon/r100 does not compile
stikonas: the same problem
mikkoc: airlied: same error but later
airlied: wierd they all build fine here
mcgreg: radeon_common.c:86:29: error: radeon_queryobj.h: No such file or directory radeon r6xx
stikonas: sorry, it was r600, that failed the build
mikkoc: r300 too
airlied: okay r600 should be fixed
zhasha: how do you rebase on top of something further up the stream than the one you pulled from? (i.e. the origin of your origin)
stikonas: arbocclude exists with drmRadeonCmdBuffer: -22 on rs480
suokko: rebase --onto?
airlied: stikonas: it needs a kms patch if you are using km
airlied: will be upstream tomorrow hopefully
airlied: http://people.freedesktop.org/~airlied/0001-drm-radeon-kms-add-rv530-R300_SU_REG_DEST-reloc-f.patch
airlied: goes to bed this time for reals
stikonas: so r300 now supports OpenGL 1.5
suokko: zhasha: I don't know if you exactly want that but it was first that came to my mind
airlied: well it did when OQ was added a few days ago
airlied: I just re-worked the code
JediMaster: don't suppose anyone can give me a hand with this "jumping" screen?
suokko: hmm. I don't understand what is causing the red gradient to clear :/ There is no state difference that I can find
zhasha: suokko: I have here nha's tree with a ton of patches and I wish to apply them to master
suokko: zhasha: Then you want to do git fetch && git rebase in nha's tree and then pull that to your local master
zhasha: but I need to rebase onto mesa master, don't I?
suokko: pull should merge patches to master which you can then push to fdo git
suokko: zhasha: Is that patch set in some different branch?
zhasha: it's all nha's patches
suokko: I don't understand now. Is nha's patches in git tree that is following some else branch than fdo master?
zhasha: http://cgit.freedesktop.org/~nh/mesa/log/?h=r300-compiler-gallium <- that needs to go to master
suokko: aha. Now I understand :)
suokko: So you have to add fdo pull info to your config (unless it is already there)
suokko: And then do git fetch fdo && git rebase fdo
suokko: Another option is just do a pull from nha's branch to your local master with --rebase option
zhasha: so just git pull git://bleh/~nh/mesa r300-compiler-gallium --rebase ?
suokko: git pull --rebase git://anongit.freedesktop.org/~nh/mesa
suokko: yes
zhasha: I'm terrible at git
suokko: There is just too many option to do similar stuff :)
suokko: zhasha: I think everyday git is useful reading about git. (http://www.kernel.org/pub/software/scm/git/docs/everyday.html)
zhasha: `git pull --rebase git://anongit.freedesktop.org/~nh/mesa r300-compiler-gallium` looks like it's applying all the patches from master on top of nha's tree
suokko: zhasha: Then it was wrong command :/ maybe git pull without rebase works
nanonyme: Oh, goody goody. Seems my motherboard is gracefully nearing the end of its lifespan.
zhasha: nanonyme: get a new one
nanonyme: No shit, Sherlock. ;P
stikonas: zhasha: wasn't r300-compiler-gallium already merged?
zhasha: stikonas: then they changed something? used to have a dir called compiler in there
stikonas: zhasha see commit 30bca7a4e6ad4e5a9fc74aba2eb854bb1341cca7
zhasha: oh.. I was looking for nha's name the whole time
nanonyme: zhasha: The slightly dubious bit is that the motherboard's failsafe mode makes Linux not boot but Windows works fine. :p (at least I have something to shop the new parts with)
zhasha: nanonyme: failsafe mode as in trusted computing failsafe?
nanonyme: Failsafe mode as in BIOS says your system is botched, do you want to proceed or go to BIOS configuration.
Kano: hi agd5f
Kano: (--) Chipset ATI Radeon 9250 5960 (AGP) found
Kano: does not detect edid on vga port
Kano: why not
Kano: compiled even radeon git,no diff
suokko: Kano: Maybe best to post xorg.log if there is anything usefull
Kano: suokko: well it seems some monitors have got edid, just not all...
nanonyme: Most should. Some have broken though.
Kano: it works now with an old tft, but a crt did not work
nanonyme: (as in, some EDID's are against the standard)
kdekorte: agd5f, you around?
kdekorte: got a couple of minor patches in and xmoto and neverputt are working clean on r6xx
rnoland_: agd5f: i would like to do some performance tests using WC SG pages with cache snooping disabled. how do i disable snooping?
agd5f: rnoland_: IIRC set bit 31 of the gart table entry on pre-r600, but let me double check
rnoland_: agd5f: from the header file it looks like maybe bit 0 of that gart entry on r600+
agd5f: rnoland_: on r6xx bit 0 is a valid bit
rnoland_: agd5f: oh, sorry.. bit 3
rnoland_: r600_cp.c:#define R600_PTE_SNOOPED (1 << 2)
agd5f: rnoland_: bit 2
rnoland_: counting from 0, yes
rnoland_: ok, let me see how badly i can break things...
agd5f: rnoland_: setting bit 31 in the old tables is no snoop
agd5f: clearing it is enabling cache snoop
rnoland_: agd5f: ok, thanks... is that <= r500 then
agd5f: rnoland_: yes
agd5f: and rs690/rs740
rnoland_: agd5f: ok, i'll play around with r600 for now...
rnoland_: i have to make sure i've got everything setup WC first.
agd5f: kdekorte: the DRM_RADEON_CP_IDLE ioctl polls in the drm, do it doesn't really matter whether you call it directly or via waitforidle
agd5f: kdekorte: I think this is just covering up the real bug as you should only have to wait for the chip to be idle when you want to access something with the CPU
suokko: agd5f: btw, When my dma bo pool was tested with r600 there was problem that dma regions were leaked
suokko: So something doesn't free dma regions after using them
suokko: Maybe there is something that then gets over written if not waiting for idle
agd5f: suokko: it's the shaders, they don't get released until deleteprogram is called
kdekorte: agd5f, the reason I called it directly was that I wanted to see if once was enough to flush the content and it appears it was, in WaitForIdle it can loop
suokko: agd5f: Maybe they should then have own bo pool then
agd5f: kdekorte: it won't loop unless the GPU has hung realistically
agd5f: suokko: they don't use dma.current
kdekorte: agd5f, just wanted to see what the minimum condition was, since I could not figure out if there was a flag in the radeon structure that could tell us if we needed to call WaitForIlde or not... for example a long command buffer or something else
suokko: agd5f: What they use then? Because something was leaking from dma.current
kdekorte: The fact that without causes screen corruption, shows that either something is incomplete or being overwritten
suokko: I get 0.034 fps when doing profiling with callgrind :)
agd5f: suokko: they allocate their own bos
agd5f: see r600_emit.c
suokko: agd5f: sure. THen they shouldn't be causing the leak warning from dma bo pool. But something was still causing it
agd5f: suokko: ok
agd5f: kdekorte: or an input/output cache flushing problem
kdekorte: agd5f, well just trying to be helpful... not sure I am at this point.. but trying
agd5f: kdekorte: much appreciated :)
kdekorte: the fact that neverputt works is making this stuff start to seem real...
kdekorte: Also without the idle, teapot is a total mess... with it, just some shadow issues... so maybe the vector list start point is not quite updated when the chip goes to draw things
kdekorte: I'm not exactly sure how this stuff works, but I'm guessing there is some kind of display list that put in, and then tell the chip where it is and to draw it
suokko: What would be required to have r300 smooth lines in hw? engine in line mode runs around 1 fps without hw support
agd5f: kdekorte: yes, basically you point vertex resources at buffers of vertex data. then a vertex program fetches it and transforms it and passes it to a the SPI which does interpolation and then feeds data into the pixel shader
agd5f: the pixel shader does the pixel ops, optional tex fetches, and then writes to the color buffer
agd5f: suokko: someone to implement it :) IIRC, there's some support in the GA for doing it, but you need to add some ps instructions IIRC
suokko: I think that smooth lines would be important for 3D modeling programs so maybe they should be implemented
kdekorte: Ok, so based on observation it looks like there might be some issues with loading the vertex array, either an off by one for the start point or the startpoint is getting updated a little late.. take a look at the engine demo and you'll see the first cylindar on the right has some items that are off, everything else is fine (with my idle patch)
marvin24: anyone tried running a qt app with "--graphicssystem opengl" ?
marvin24: gives: [drm:r300_cs_track_check] *ERROR* [drm] Buffer too small for z buffer (need 339264 have 335872) ! and [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! here
marvin24: could this be a qt bug?
agd5f: kdekorte: see r700SetupStreams() in r700_chip.c
agd5f: that sets up the vertex reources
suokko: marvin24: unlikely that it is in qt but it is possible
marvin24: suokko: just wondering if I am the only one
agd5f: kdekorte: rcommon_emit_vector() writes the vertex data to the gart vertex buffer, and r700SetupVTXConstants() sets up the vertex resource registers
suokko: marvin24: Best way to know where the bug is to run application with RADEON_DEBUG=all. Then make a bug report to fdo and attach that output there with instructions how to reproduce. Also good idea to check if qt works without kms (if you run kms now)
marvin24: output of "kcalc --graphicssystem opengl": http://pastebin.com/m5958db
marvin24: and yes, I'm running with KMS
marvin24: will try without
marvin24: restarts X
marvin24: suokko: you were right, works without KMS
suokko: marvin24: Can you make the bug report to fdo?
marvin24: suokko: ok, will do
marvin24: btw. I would not recommend this mode, as it causes a lot of flicker and redraw problems
suokko: marvin24: I would think that KMS will fix flickering
rnoland: agd5f: so, unsnooped on the 4650 with WC...
rnoland: appears to be a tiny bit faster than WB or WC w/snooping
rnoland: agd5f: but it also seems to produce a bit less flicker..
suokko: agd5f: I did sent 2 trivial optimization patches for libdrm_radeon mailing list. Can you review them?
agd5f: suokko: sure give me a sec
agd5f: suokko: btw, what's the status on those dma rework patches?
rnoland: agd5f: which document describes the <=r500 gart entries?
rnoland: i''m getting like 2240fps on 4650 now.
lyhana8: hi, I came here yesterday about a ATI plug on a TV
glisse: rnoland: code describre gart :)
agd5f: rnoland: I don't think it's in any document. see ati_pcigart.c in the drm
rnoland: agd5f: ok... it doesn't mention bit 31...
lyhana8: the vga-0 and LVDS are identified on the same screen
rnoland: but i'll try to compare perf there next...
agd5f: rnoland: we don't set it at the moment in the old drm. maybe on kms side
rnoland: agd5f: right, is bit 31 high enables snooping or disables?
suokko: agd5f: I have to rebase and check them. I jsut noticed that again someone changed dma.current somewhere so it didn't copile for me
agd5f: rnoland: disables
glisse: rnoland: high disable snoopingg
rnoland: thanks guys..
rnoland: bit 2 low disables on r600 right?
suokko: glisse: btw, Have you got bug report from DanaG that if agpgart is laoded after radeon module there is possible null pointer reference?
rnoland: that is what i have now.
lyhana8: agd5f: all VGA-0 LVDS modification change my laptop screen
agd5f: rnoland: high enables snooping on r6xx
rnoland: agd5f: ok, i'm clear now...
agd5f: lyhana8: LVDS is your laptop screen
lyhana8: agd5f: I guess yes
suokko: btw, I think that I have got emit size prediction to work inr r300TryDrawPrims but it required quite large changes :/
lyhana8: agd5f: see : http://imagebin.ca/view/RqlgJW.html
agd5f: lyhana8: they are cloned
lyhana8: so ?
agd5f: both pointing at the same content
agd5f: lyhana8: are you trying to enable dualhead?
lyhana8: i want to be able to put the same content on my laptop screen and on a tv/projector
lyhana8: not sure of the english terms used to talks about this
suokko: lyhana8: So what happens in tv/projector when you try that configuration?
suokko: But I go test nexuiz if I broke anything :)
lyhana8: the TV keep blinking ; I got the same effect last week when I used the wrong resolution for the screen
lyhana8: when I plug my gf laptop (KDE3+ATI radeon mobility X2300+fglrx) the TV is on XGA, when I plug mine (KDE4+ATI radeon mobility X700+radeon) it's on VGA
lyhana8: her config work, mine doesn't
rnoland: agd5f: looking at ati_pcigart.c bit 31 appears to be a valid address bit...
rnoland: let me recheck the linux version...
agd5f: rnoland: top 4 bits are not address bits
rnoland: for GART_PCI, we don't shift the bus address at all...
agd5f: 31 is no_snoop, 29 is write enable, 28 is read enable
rnoland: 30 reserved?
agd5f: rnoland: yeah
rnoland: sigh... ok, need to recheck the linux code then...
lyhana8: suokko: agd5f here is my conf panel : http://imagebin.ca/view/piiNUmMI.html (both screen are on the same area)
agd5f: lyhana8: so what's the problem?
agd5f: rnoland: see gart_insert_page_into_table() in linux-core/ati_pcigart.c
lyhana8: http://imagebin.ca/view/d5vS_c.html here is the multiple monitor config panel
rnoland: agd5f: yeah, i used airlied last changes to that to write mine...
suokko: agd5f: I guess problem is that drier is trying to use wrong resolution or timings for external tv
lyhana8: agd5f: I don't have anything on the TV, it's keep blinking
agd5f: lyhana8: your beamer may not like 1280x800
agd5f: use xrandr to select a different mode: xrandr --output VGA-0 --mode 1024x768
lyhana8: indeed it doesn't but when I change the VGA-0 res, the TV blink anyway
lyhana8: agd5f: my screen went black and then light back, but no change on the TV
agd5f: lyhana8: can you pastebin the output of xrandr --verbose?
lyhana8: http://pastebin.com/m217b4a61
agd5f: lyhana8: what chip is this again?
agd5f: lyhana8: does a VT switch fix it?
kdekorte: agd5f, been looking at r700SetupStreams and it seems like a lot of things are not being emitted because of unBit... can you explain this a little?
agd5f: kdekorte: not all vertexes have all attributes
agd5f: so you might have position and color only, or just position
agd5f: kdekorte: teh vertex attributes are the inputs to the vertex program
agd5f: vpc->mesa_program.Base.InputsRead & unBit
rnoland: agd5f: so page_base = 32bit address & PAGE_MASK
rnoland: on PCI that value is written directly to the gart
kdekorte: but how does unBit = 1 << i factor into that? is it a mask for InputsRead?
agd5f: so the loop walks through all the possible vertex attributes and only emits the ones that are inputs to the vertex program
agd5f: kdekorte: yes
agd5f: rnoland: ptes are different between IGP/PCIE/PCI
rnoland: on pcie, it is shifted, but the top byte is filled in from the higher address..
lyhana8: agd5f: it's a mobility radeon X700
lyhana8: rev 410 I believe
agd5f: lyhana8: try a VT switch
lyhana8: what's that ?
agd5f: lyhana8: Ctrl-Alt-F1
agd5f: then Ctrl-Alt-F7 usually to switch back to X
lyhana8: then what ?
agd5f: lyhana8: see if it helps
kdekorte: agd5f, it appeats that when i=0 the vector is always processed... I wonder if that is correct
lyhana8: agd5f: not at all
agd5f: kdekorte: 0 is position
agd5f: so it's usually there
kdekorte: the "usually" is the part that bugs me... I changed i to start at 1 and that really messed stuff up
agd5f: kdekorte: pretty much always
agd5f: lyhana8: try Option "R4xxATOM" "True" in the device section of your config
agd5f: kdekorte: mesa provides the vertex program and buffers
lyhana8: agd5f: could you check y xorg.conf
lyhana8: I copied it from my gentoo
agd5f: lyhana8: pastebin it
lyhana8: http://pastebin.com/d40f4cbe7
agd5f: lyhana8: looks fine. you don't need to specify the videoram
lyhana8: I've only one screen, is it OK
suokko: agd5f: Is it better that I post updated dma patch to same thread as previous versions or new thread?
lyhana8: agd5f: I try the option on the VGA device section or on the ati_card one ?
peterz: how stable is this r600 stuff?
agd5f: lyhana8: ati_card. you can remove the vga one
agd5f: peterz: pretty stable, just some rendering corruption
agd5f: suokko: doesn't matter
peterz: agd5f: awesome, then I'll try and build it one of these days
suokko: ok. Updated version is coming to old thread soon
lyhana8: ok I try this if fail go on my gf's laptop and come back later. Thanks :)
peterz: agd5f: does airlied have a drm tree with the needed bits against -linus, or should I take your libdrm bits?
agd5f: peterz: you can use my libdrm or the libdrm from drm master. for the actual kernel modules, you'll need my tree. r6xx-r7xx-3d branch
peterz: agd5f: ok, I'll try and patch that into linus
agd5f: suokko: libdrm stuff looks good
peterz: agd5f: btw, what is the largest texture size for r600? 4kx4k?
agd5f: suokko: should get airlied's ack first
agd5f: peterz: 8k
peterz: agd5f: a sweet, so my dual-head 24" should be no problem then
agd5f: peterz: yeah, should be fine. not sure if the limit has been bumped yet in the 3d driver
suokko: agd5f: ok. I will ping airlied. Thanks for review.
peterz: agd5f: will let you know if things fall apart ;-)
glisse: suokko: yup libdrm looks good
gregor2005: hi, i need some help with the ati driver for my graphiccard (laptop) mobility radeon hd 3400
nanonyme: Shoot.
gregor2005: on fedora 11 with kernel 2.6.29.6-1217.2.8 64bit
nanonyme: Yeah, what doesn't work? ;)
gregor2005: sry ^.^
gregor2005: i can't compile the driver
gregor2005: alway get some errors
gregor2005: i have installed kernel-devel kernel-headers gcc g++ ...
gregor2005: i start the installation again that i can post the errormsg
gregor2005: some error in the ati-installer.sh on line 39 :-(
adamk: gregor2005, That's the closed source driver. You should ask on #ati.
gregor2005: ok
adamk: gregor2005, Be warned, however, that AMD does not support Fedora. No fglrx version, up to 9.7, officially supported anything newer than 2.6.28. Not sure if 9.8 changes that.
gregor2005: and the opensource driver?
gregor2005: you know the rpm name?
nanonyme: Sure, Fedora is mostly the test-bed for semi-experimental radeon drivers, it seems...
adamk: gregor2005, The open source driver comes with F11 by default and is undoubtedly installed and (hopefully) in use already.
gregor2005: which drivername should i found in my xorg.conf ^^ ?
nanonyme: It should have EXA/Xv out of the box with F11.
nanonyme: No xorg.conf required.
adamk: Yeah, I doubt very much F11 came with an xorg.conf file.
gregor2005: ok, when i delete the xorg.conf and reboot i have the wrong resolution
gregor2005: and can't change it
nanonyme: Huh?
gregor2005: since f10 there is no default xorg.conf
adamk: gregor2005, Alright, so try that again and then come back here and pastebin your /var/log/Xorg.0.log file.
gregor2005: i test it on my laptop
nanonyme: Sounds like an EDID bug, possible.
nanonyme: Would probably need a xorg log with an increased verbose level to see the modelines.
gregor2005: i deleted the xorg.conf and run startx but i have a black screen now
gregor2005: strg+alt+backspace didn't help
adamk: Did you completely uninstall the ati driver you were in the middle of installing?
gregor2005: no
nanonyme: Hrm, having r600 KMS on could also cause that effect but iirc it's off by default in F11...
gregor2005: try to uninstall the original ati driver
gregor2005: how can i uninstall the original driver?
gregor2005: or should i create a xorg.conf and write the os driver in the driver section?
yangman: xorg-server-1.6 starts to a black screen by default, and ctrl+alt+backspace is also disabled
gregor2005: yes ^.^ me too
yangman: check your log to see if it's actually working
gregor2005: in the log see that it takes the ati driver then the vesa driver
gregor2005: wich is the os driver?
nanonyme: Implies opensource, probably.
nanonyme: Pretty much every other driver than fglrx for your card are opensource.
suokko: gregor2005: soudns like you have fglrx kernel module installed. ati dirver is wrapper for radeon oss driver
yangman: can you upload the log to a pastebin please
gregor2005: ok
kdekorte: agd5f, well mesa git master crashes alot now... even adding the call to CP_IDLE doesn't fix it in FlushCmdBuf...
gregor2005: http://paste2.org/p/385664
agd5f: kdekorte: now we need to fix the dma buffer leaks
yangman: gregor2005: seems to be working fine. try starting a desktop environment
suokko: agd5f: I think that bo handling could be optimized in ddx too. My guess is opening and closing buffer objects might be causing a bit slower window resizing with KMS than without.
yangman: gregor2005: ugh, sorry. you still have fglrx installed
suokko: That is of course only relevant in old slow agp systems
yangman: gregor2005: make sure that's removed completely first, and restart
gregor2005: how can i remove the old driver?
yangman: use your package manager
agd5f: suokko: yes, definitely
gregor2005: rpm -qa | grep fglrx --> gives me no line
yangman: how did you install it?
gregor2005: from the original driver
yangman: ?
gregor2005: i only installed the original drive
gregor2005: +r
gregor2005: because on rpmfusion there is no fglrx driver
nanonyme: Obviously not because it doesn't support F11 kernel.
gregor2005: is it possible to take a xorg.conf and write in the driver section the os drivername?
nanonyme: It's only available for F10 in rpmfusion.
yangman: it's using the correct X driver but bad DRM backend (fglrx)
suokko: gregor2005: problem is that fgrlx overwrites some important files and its kernel module interferes with oss kernel module
gregor2005: when i use the vesa driver i can start the xserver
suokko: gregor2005: so you need to remove fglrx.ko from /lib/modules
gregor2005: lol under system in gnome i see the ati catalyst control center
gregor2005: damn
nanonyme: suokko: It's about impossible for him to have it installed via package management system. :)
suokko: and then you need to reinstall libgl1-mesa-dri (is that correct in fedora?)
gregor2005: is there a script to remove the original driver?
nanonyme: Hmm...
suokko: nanonyme: You can install it without rpms from official installer :(
nanonyme: suokko: Yeah but it doesn't support his kernel.
nanonyme: Actually hmm, some late one did.
suokko: nanonyme: except that 9.8 might have support for it
nanonyme: Yeah.
suokko: gregor2005: There is no script unless the installer has remove option too
gregor2005: lol
mcgreg: gregor2005, yes /usr/share/ati normnally
gregor2005: i found a script
gregor2005: yes
gregor2005: there it is
pepee: hello
gregor2005: now i have no ccc
pepee: i was having troubles with the X server
pepee: it was crashing and restarting
gregor2005: now it work
gregor2005: s
gregor2005: i deleted the xorg.conf
gregor2005: and startx again
gregor2005: and i have the correct resolution
pepee: i solved it adding: Option "AIGLX" "false"
pepee: info: GL_VERSION = 1.4 Mesa 7.6-devel, $ uname -r 2.6.30-10-generic, ubuntu jaunty
suokko: pepee: Can you paste xorg.log from crashed session?
pepee: i'm using the latest version from a ubuntu repo: https://launchpad.net/~xorg-edgers
suokko: pepee: I think you should remove that xorg-edgers kernel. It is very old by now
pepee: hmm i will
pepee: suokko, since i've changed xorg.conf, i didn't have any problems
gregor2005: thx for help
gregor2005: have a nice day
gregor2005: bye
pepee: the only log i have is this: http://pastebin.ca/1530945 , but is the same i give you when i reported this
DanaG: hmm, will the recent drm code be combined with KMS code? or rather, when will it?
suokko: pepee: AIGLX is only required for indirect 3D acceleration. (compiz or remote 3D application over ssh) so if you don't need that feature you sohuld be fine. But bug report would help fixing it :)
adamk_: DanaG: I imagine when they are both ready :-)
nanonyme: Btw, is AIGLX unused in DRI2?
adamk_: nanonyme: AIGLX is not necessary for running compiz in DRI2, but it can still be used.
nanonyme: Any good use cases?
adamk_: Accelerating GLX applications from another machine is very nice.
suokko: nanonyme: remote 3D ;)
DanaG: Now, try running compiz on a remote host. It's a recipe for breakage of some sort.
suokko: you can run opengl application over ssh
nanonyme: Hmm, neato.
nanonyme: Never tried.
adamk_: DanaG: I've done it... No breakage to speak of.
suokko: Too bad ssh X tunneling doesn't automaticaly set LIBGL_ALWAYS_INDIRECT
DanaG: The last time I tried it was several months ago... I don't even remember which computer and driver that was with.
adamk_: Cool... I just tried again and it's still working. The X server is on my laptop, an i915 GPU with FreeBSD. The compiz client is running from another machine running F11.
rnoland: so both vdrift and nexuiz seem quite good on x1650 right now...
rnoland: don't think either have ever been playable for me...
AndrewR: suokko, hm, got this with Quake 1 : http://pastebin.com/m7013d640
rnoland: both seemed to work on r600 as well, but with so much corruption that you couldn't see what you were doing...
rnoland: adamk_: do you have an IGP?
rnoland: i.e. rs485/rs690
mcgreg: suokko, should "radeon: Optimize memory handling for dma operations." speed up anything?
adamk_: rnoland: Sorry, not any more.
suokko: mcgreg: on r200 it makes in some cases even 3x speed difference
suokko: So if rendering is cpu bound it has effect but on newer cards rendering is not cpu bound anyway
mcgreg: wow
rnoland: adamk_: ok... just messing with memory caching... and that is the chip that frightens me...
mcgreg: oh ok
suokko: AndrewR: http://nopaste.com/p/a3SU8QhZq Does this help you?
agd5f: suokko: yeah, that fixes it
suokko: agd5f: Can you commit it? That was mapping leak because of last minute mapping code change :/
agd5f: suokko: yes will do
rnoland: hrm, the 1650 is really working well..
agd5f: suokko: thanks. pushed
rnoland: lemme try kde....
rnoland: i can't make anything bad happen here...
kdekorte: agd5f, ok got latest git and things are a little better... etracer still crashing, and flickering in neverputt.. got this
kdekorte: *********************************WARN_ONCE*********************************
kdekorte: File radeon_dma.c function radeonReleaseDmaRegions line 302
kdekorte: Leaking dma buffer object!
kdekorte: ***************************************************************************
AndrewR: suokko, sorry, crash at exit from Q1 ...
kdekorte: still getting massive texture corruption in all clutter apps and quake3 in the menus..
kdekorte: texture is ok on 1/2 the rectangle (1 triangle) and missing on the other 1/2
suokko: AndrewR: Where did you get Q1? I could test it too if there is download possibility
agd5f: kdekorte: need to track down where we are leaking an bo
AndrewR: suokko, it was shareware zip + Linxux binary ... i think i can find it again ...
AndrewR: suokko, http://mfcn.ilo.de/glxquake/
suokko: agd5f: You have to compile libdrm and mesa with bo tracking and then use go tough list of leaking bos
agd5f: suokko: thanks
suokko: agd5f: There is a patch in mailing list to fix that tracking not to cause segmentation fault
agd5f: suokko: yeah, I remember that. I'll add that along with the other libdrm patches from you
suokko: agd5f: "Update head of linked list not to point freed memory"
suokko: I don't know if tht configure option is realy good but it might help compiling with tracking so won't face same problems as I when libdrm was with tracking and mesa without
suokko: agd5f: in end the tracking info is written to /tmp/somefile. I was a bit surprised when I noticed that
agd5f: suokko: pushed your libdrm patches
suokko: AndrewR: quake 1 is trying to use DGA extension that my xserver doesn't have
AndrewR: suokko, yes, i run it in dri1 mode ...
nanonyme: Eek, ew?
nanonyme: suokko: That's evil. :/ Which extension, actually?
suokko: direct video mode
nanonyme: Ah.
suokko: But quake 1 is ancient
nanonyme: That was one of the things that wasn't implemented due to security concerns?
agd5f: it needs dga for the mouse handling
nanonyme: Ah, that's not as bad...
nanonyme: If it was actually DGA rendering, would've been a headdesk time.
agd5f: suokko: bo tracking output is rather larger :)
suokko: AndrewR: I guess that dri1 mode might have bugs if you use my flush patch. I haven't checked yet that I didn't break anything there
suokko: agd5f: all bos
suokko: I did use gdb to break and look into specific bo
suokko: It is quite easy to see what is stored in that linked list
agd5f: suokko: yeah
suokko: But if you have simple enough demo output shouldn't be too large to analyze if you knew which bos are good
AndrewR: suokko, right now i use dri2 mode, so this bug may wait for some more time ...
suokko: In fact leaked bos should be listed last in the lsit if I remember code right
suokko: AndrewR: i will check dri1 after I have fixed r300. But that might take few days. Thanks for testing the patch :)
masa-: damn it... fglrx always screws everything up... i had to re-merge xorg-server because apparently ati-drivers purged libdri.so when i unmerged it :p
masa-: so i did not get even Xv working with open drivers
suokko: hopes that some day fglrx installatino could be fixed so it could live side by side with oss drivers
chithead: masa-: gentoo? eselect opengl and never use the ati installer
DanaG: fglrx has an uninstaller, actually.
scott_ino2: hello, I'm trying to figure out which chipset i actually have
chithead: scott_ino2: lspci
scott_ino2: yes.... but that only tells me ATI Technologies Inc Mobility Radeon HD 3400 Series
scott_ino2: not the chipset it's based on
scott_ino2: is there a list of this
suokko: btw, I just broke 800 fps mark in dri2 with rv280 :) (2 weeks ago it was 160fps)
suokko: scott_ino2: wikipedia has one
MostAwesomeDude: scott_ino2: RV620 IIRC. You can find out with lspci -vv
scott_ino2: ty suokko, MostAwesomeDude
MostAwesomeDude: checks
MostAwesomeDude: It's RV620.
MostAwesomeDude: Damn, I'm good. :3
scott_ino2: ha thanks...
AndrewR: agd5f, non-24 bpp is broken under KMS/radeon too, but in different ways
chithead: the radeon manpage also has some mapping between those names
nanonyme: MostAwesomeDude: Yeah, you are. :3
scott_ino2: cool, good to know.. i hate the fglrx driver for so many reasons, but of course no 3D as of yet for the open source driver
scott_ino2: so im just doing my research
chithead: latest mesa from git will give you working compiz
agd5f: AndrewR: same xserver issue
DanaG: Still glitchy, though?
scott_ino2: chithead, how stable though :-) this is a production machine
DanaG: Last time I tried, it crashed on cube-rotate. =þ
DanaG: Or rather, it explicitly exited.
nanonyme: scott_ino2: Not for production machines yet. :)
chithead: compiz is reported to work well. other 3d apps often have glitches. but on production systems better avoid prerelease software
scott_ino2: :-)
AndrewR: agd5f, but this time i saw server crash, completely black screen, and fancy splitted scree, depend on given depth .. always something new
AndrewR: agd5f, funny bugs
scott_ino2: nanonyme, well i say production... i dont mind breaking things
scott_ino2: is there a time table somewhere?
scott_ino2: sincei know it's in progress already
nanonyme: scott_ino2: It's done when it's done... Mostly time for hunting big bugs now which is followed by hunting minor bugs. ^^
scott_ino2: not a problem.... was just wondering
nanonyme: As far as I've understood, should be a working OpenGL 1.4 implementation after that.
nanonyme: scott_ino2: Hunting bugs might not be a trivial matter though so better be patient. :)
scott_ino2: I've been dealing with nix long enough to know to be patient ;-)
scott_ino2: i mean.. im one of those rare people that don't need 3D
scott_ino2: and i actually get better performance for video and the programs i use from the open source driver than the fglrx one
scott_ino2: does the radeon driver have powersaving/gpuscaling?
nanonyme: It does have some level of power management, however, apparently the Good Stuff (tm) needs to be built on top of KMS. :)
chithead: scott_ino2: yes, if it is new enough. check the radeon manpage for clockgating and related options
scott_ino2: ty chithead sorry ive been going through lots of docs
masa-: chithead: yep gentoo, and i did eselect opengl set xorg-x11 twice before that
AndrewR: OffTopic: http://www.vizworld.com/2009/08/breaking-sgi-terminates-graphics-division/
ajax: well that took long enough.
osiris_: maybe now they will be more willing to allow for royalty free use of ARB_texture_float
MostAwesomeDude: We can only hope.
agd5f: osiris_: probably switching their business model to full time patent trolls
nanonyme: Still long until their patents start expiring?
MostAwesomeDude: Just long enough, unfortunately.
rnoland: suokko: what were those patches supposed to fix?
rnoland: i think kde4 is better now... but fonts are still screwed and still a bit of aartifacts.
adamk: Anyone know what "xrandr: Configure crtc 0 invalid time" is telling me?
kka: if I want kms I need kernel >=2.6.31?
kka: for r500
agd5f: kka: yes
kka: k
osiris_: glisse: ping
osiris_: airlied: ping
airlied: osiris_: on phone but here
osiris_: airlied: there's a bug in radeon drm cs checker. maxy is should be calculated as ((0x43e4 >> 13) & 0x1fff) - ((0x43e0 >> 13) & 0x1fff) (i.e. y2 - y1)
osiris_: airlied: now maxy is y2 - SCISSOR_OFFSET
jmho___: hi, are there plans to do xf86-video-ati 6.12.3 release?
MostAwesomeDude: osiris_: Ping. A couple questions about your OQ code.
airlied: MostAwesomeDude: ask them I migt be able to answer
MostAwesomeDude: airlied: 'k.
MostAwesomeDude: First, it looks like the high-bit second pipe thing (pipe 1 is bit 0, pipe 2 is bit 3) is all R3xx chipsets?
MostAwesomeDude: Second, is the RV530 reg dest for RV530 only, or for RV530 and up (nearly all R5xx and RS6xx)?
MostAwesomeDude: Third, I've got radeon_bo_wait over here, and it appears to be blocking indefinitely, but it's not locking up; I have a sneaky suspicion that the kernel doesn't know how to bo_wait on OQ BOs?
airlied: MostAwesomeDude: yes and yes, whatever it does now is correct as far we know
MostAwesomeDude: 'k, added those to r300_chipset over here.
airlied: MostAwesomeDude: the OQ BO should be just like anyother
airlied: wiat should return if the fence passes
MostAwesomeDude: Fence... is that a kernel-side fence? I don't have Gallium fences implemented.
airlied: MostAwesomeDude: yup kernel internal
ajavid: hello, good evening, I am using debian and 7.4 and radeon and I'd like to benchmark the 3d performance. I have X1900Xt. which tools can I use to see accurate realworld framerate, something that can prefreblly stress the card in a sense that it adds dynamic lighting, effects, etc, etc, just to see how well it would perform
ajavid: something like this would be nice. Please advise
kk_: uhm maybe phoronix tools
kk_: dunno
ajavid: also, pref. something already packaged :)
ajavid: cool, its in php!
ajavid: hmm.. There is a GTK2 interface written for the Phoronix Test Suite for php-gtk
ajavid: its not packaged for debian, because I'm a lazy maintainer. I had it ITP filed, packaged, uhm.. lost.. version upgraded... now I must package it again.. so lets see
ajavid: kk_, thank you very much!
kk_: np -.-
ajavid: what license is under photonix test suite?
ajavid: nm, http://www.phoronix-test-suite.com/documentation/2.0/index.html == gnu gpl v3
ajavid: so let me test em out and I suppose it could be packaged if not already
airlied: osiris_: btw where is that maxy biting?
airlied: osiris_: since the current code makes sense to me, if someone changes the scissor it doesn't affect what the *max* y value they can use it
DanaG: hmm, I'm anxious to see when we get the text corruption (and cube crash) fixed. =þ