airlied: agd5f: you might want to review the few tv commits I just pushed
airlied: to the DDX that is
Nightwulf|work: hi all
JohnDoe: morning
mikkoc: with kms enabled scrolling in QtCreator is slow and jerky and X takes up a lot of cpu
mikkoc: no problems with non kms
mikkoc: using exa
simplexe: hmm...queston: kms module only in < 2.6.31 kernel?
mikkoc: u probably mean >= 2.6.31
simplexe: mikkoc: ahh, yes, my mistake
fpoibaf: I am unable to compile current r300 driver:
fpoibaf: r300_queryobj.c:98:111: error: macro "radeon_bo_open" requires 7 arguments, but only 6 given
fpoibaf: r300_queryobj.c: In function ‘r300BeginQuery’:
fpoibaf: r300_queryobj.c:98: error: ‘radeon_bo_open’ undeclared (first use in this function)
fpoibaf: r300_queryobj.c:98: error: (Each undeclared identifier is reported only once
fpoibaf: r300_queryobj.c:98: error: for each function it appears in.)
fpoibaf: When I apply the patch at http://people.freedesktop.org/~airlied/0001-r300-OQ-reimagining.patch I get:
fpoibaf: In file included from r300_context.c:70:
fpoibaf: radeon_queryobj.h:1: error: expected identifier or ‘(’ before ‘.’ token
fpoibaf: r300_context.c: In function ‘r300_emit_query_finish’:
fpoibaf: r300_context.c:270: error: ‘RADEON_QUERY_PAGE_SIZE’ undeclared (first use in this function)
fpoibaf: r300_context.c:270: error: (Each undeclared identifier is reported only once
fpoibaf: r300_context.c:270: error: for each function it appears in.)
fpoibaf: r300_context.c: In function ‘rv530_emit_query_finish’:
fpoibaf: r300_context.c:291: error: ‘RADEON_QUERY_PAGE_SIZE’ undeclared (first use in this function)
fpoibaf: r300_context.c: In function ‘r300CreateContext’:
fpoibaf: r300_context.c:462: warning: implicit declaration of function ‘radeonInitQueryObjFunctions’
mikkoc: pastebin
airlied: fpoibaf: if you just used patch to apply it you need to remake the symblinks
airlied: symlinks even
fpoibaf: is an autogen sufficient?
airlied: no you need to rm src/mesa/drivers/dri/r300/radeon_queryobj.[hc]
airlied: and ln them from radeon
nanonyme: Ah.
airlied: osiris_: the pgilit test fails for me on my rv530 laptop because I get back twice the samples
airlied: something to do with the multi-pipes
tsamolotoff: Hi guys, it's been a long time )
fpoibaf: ok, the problem with the patch is fixed, but I am still getting the same compile error I get with unpatched r300 master:
fpoibaf: radeon_queryobj.c:127:106: error: macro "radeon_bo_open" requires 7 arguments, but only 6 given
fpoibaf: radeon_queryobj.c: In function ‘radeonBeginQuery’:
fpoibaf: radeon_queryobj.c:127: error: ‘radeon_bo_open’ undeclared (first use in this function)
fpoibaf: radeon_queryobj.c:127: error: (Each undeclared identifier is reported only once
fpoibaf: radeon_queryobj.c:127: error: for each function it appears in.)
tsa: So, what's about VBO's?
airlied: sounds like some debug enabled
airlied: fpoibaf: you enabled BO debugging somewhere?
fpoibaf: airlied: I just compiled with:
fpoibaf: ./autogen.sh --disable-gallium --with-dri-drivers="swrast,r300" && make
fpoibaf: after a clen git clone
airlied: uggh I hate this RADEON_DEBUG_BO
airlied: agd5f: I'm getting tempted to rip it out
tsa_: http://people.freedesktop.org/~airlied/0001-r300-OQ-reimagining.patch - what's that, can anyone explain please?
airlied: its OQ support reimagined
tsa_: Is it worth applyin'?
airlied: not unless you are doing OQ and developing it
tsa_: Thanks... I've seen the news post on phoronix on VBO, built the latest git(mesa/drm/radeon(, and nothing's changed in nexuiz ...
airlied: fpoibaf: pushed the fix
fpoibaf: airlied: I am still getting the same problem even after the latest fix:
fpoibaf: r300_queryobj.c:98:111: error: macro "radeon_bo_open" requires 7 arguments, but only 6 given
fpoibaf: r300_queryobj.c: In function ‘r300BeginQuery’:
fpoibaf: r300_queryobj.c:98: error: ‘radeon_bo_open’ undeclared (first use in this function)
fpoibaf: r300_queryobj.c:98: error: (Each undeclared identifier is reported only once
fpoibaf: r300_queryobj.c:98: error: for each function it appears in.)
mosgreg: hi
mosgreg: with current mesa I get:
mosgreg: libGL error: drmOpenOnce failed (Operation not permitted)
mosgreg: libGL error: reverting to software direct rendering
simplexe: mosgreg: your user in group video?
mosgreg: of course
simplexe: mosgreg: ls -la /dev/dri/card0
mosgreg: crw-rw---- 1 root root 226, 0 2009-08-17 11:28 /dev/dri/card0
simplexe: chown root:video /dev/dri/card0
simplexe: and try now
g-zu: osiris_: you around somehow?
mosgreg: better. but .. WTF did it suddenly change?
mosgreg: same with /etc/group ... it suddenly became root readable only
mosgreg: thank you simplexe
simplexe: mosgreg: no problem
rom1dep: hi there ! I'm a "serial-compiler" of xf86-video-ati but since about a week it's like the driver is going in a wrong shape for my r420-based chip... Are you aware of this ?
glisse: rom1dep: what's wrong ?
rom1dep: since yesterday I cannot run certain apps like amarok :
rom1dep: [rom1dep@Targa atidrv]$ amarok
rom1dep: amarok: symbol lookup error: /local/xorg/lib/libGL.so.1: undefined symbol: gl_dispatch_stub_776
glisse: this is not ddx fault this is an issue in libgl or xserver
rom1dep: I'll update my tree and see if it's better today, but I encountered issues with other apps (stepmania) with other error msgs before but one week ago was everything fine...
suokko: airlied: Maybe that bo debug stuff should be made transparent to code so that it is implemented in headers using macros
airlied: suokko: yup thats what should happen, I'm starting to think maybe I should just requrie libdrm for mesa
airlied: libdrm_radeon
airlied: then just do it there.
airlied: really we can sort of handle some crashes now
airlied: with kms
airlied: we just need more time to make it better at its job
airlied: oops
rom1dep: went make a "service dm restart"
rom1dep: same...
glisse: rom1dep: double check that you got same libgl as the one against which your xserver was built
glisse: airlied: why don't we split rendering in the non index draw case in mesa ?
glisse: trying to get through my mail :)
airlied: glisse: osiris was hitting some bugs with it, though not sure if we resolved those
airlied: glisse: you happy with the bo busy patch?
glisse: airlied: i think so
glisse: well i cna't think of anythings wrong with it and api is simple enough :)
glisse: airlied: splitting non index rendering seems to works for me
glisse: i will push the patch
airlied: glisse: I think I had issues with ut2004 but I think it was the index case
glisse: yeah i think too it was in the index case
glisse: but index case seems to work now
JohnDoe: strange. Can freez the black screen at logout
JohnDoe: ATI Technologies Inc RS482 [Radeon Xpress 200M]
rom1dep: I didn't build the whole xserver by my own, I folowed instructions from www.x.org/wiki/radeon to only compile the radeon driver...
JohnDoe: X.Org version: 1.6.3
JohnDoe: direct rendering: Yes
JohnDoe: server glx vendor string: SGI
JohnDoe: server glx version string: 1.2
JohnDoe: --
JohnDoe: OpenGL vendor string: DRI R300 Project
JohnDoe: OpenGL renderer string: Mesa DRI R300 (RS400 5975) 20090101 NO-TCL
JohnDoe: OpenGL version string: 1.4 Mesa 7.6-devel
JohnDoe: Linux 2.6.30-02063004-generic
rom1dep: glisse: the error msg speaks about libGL.so.1 located in /local/xorg/lib : that's the one I compiled and non the one from packages which was in /usr/lib64/
glisse: rom1dep: so it's a missmatch btw the one your xserver use and the one you are trying to use
rom1dep: glisse: I don't think so, because the one which was in /usr/lib64 doesn't exists anymore... I removed it from packages
glisse: rom1dep: you restarded the X server ?
rom1dep: glisse: yep..
glisse: rom1dep: and ls /usr/lib64 | grep GL shows nothings ?
rom1dep: glisse: libGLEW and libQtOpenGL
glisse: rom1dep: i am not sure but maybe xserver needs to be compiled against the libgl you now use
airlied: xser ver shouldn't care about libGL
airlied: it sounds like libGL is just made wrong
rom1dep: glisse: that won't be easy... I'm not a C programmer but symbol lookup error doesn't means that's there is an instruction missing in the referring lib ?
glisse: rom1dep: no, it's likely a build issue like airlied said
airlied: make clean mesa maybe
glisse: make distclean, autogen.sh in mesa you built
glisse: to do a full clean rebuild
airlied: wonders how multi-Z pipe works, seem to be getting double the occl query
rom1dep: glisse: I'll distclean dri2proto/drm/macros/mesa/pthread-stubs and xf86-video-ati then
airlied: I'd guess jus tmesa
glisse: mesa is enough
rom1dep: ok
glisse: airlied: emitquerybegin/end looks weird
glisse: begin doesn't emit reloc
glisse: which should be illegal
airlied: glisse: its only end that relocs
airlied: begin just starts the internal counts running
airlied: writingto the ADDR just transfers the writes to the bo
glisse: yup i just checked the reg
JohnDoe: At switching x server - tty and back can freezes too :(
suokko: nice supend+resume can resume ssh connection :)
glisse: airlied: you are on rv530 ?
airlied: glisse: yup this laptop is one
suokko: Why r300 driver is aligning everything to 32 bytes even in function that claims to only need dword alignment? Just a over safety from old code?
glisse: airlied: looking at the code and everythings looks fine :)
suokko: Or some cache optimization?
airlied: suokko: where abouts?
suokko: r300_draw.c
suokko: AllocDma calls all do 32 alignment
airlied: not sure it might be a mistak, dword alignment should be fine
suokko: It might have something to do with cache so that different data won't end to same cache page
airlied: not likely
airlied: ah I think it assume bo_map waits
airlied: okay all glean tests pass if I fix the bo wait
airlied: and I only take half the rv530 samplers
airlied: okay libdrm fixed pushed for map/wait issue
airlied: will think about rv530 issue a bit more
airlied: zzz for now &
rom1dep: re
rom1dep: everything cleaned and rebuilt, X restarted but always the same message...
suokko: rom1dep: Can you ind working version from mesa history?
suokko: If you can you could use bisect to locate which commit broke it for you. http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
rom1dep: suokko: thanks to be here :) the running version of mesa is the last commited over the git repo... I'm reading your url ...
nanonyme: airlied: Btw, is that /dev/dri/cardX security concern still a valid thing in DRI2? (as in, why some distros limit write privileges on the device node)
nanonyme: Oh, wait. It was just a legacy node, wasn't it?
nanonyme: I guess the real question then is, is there an equivalent concern?
suokko: nanonyme: drm is still too complex to be 100% secure for shared access
rom1dep: I'm not really at ease with git.. can someone help me to retrieve the tree as it was one week ago ?
rom1dep: finds svn easier with it's commit #rs
suokko: rom1dep: try gitk
nanonyme: suokko: Blah. :)
tsamolotoff: airlied: Are you on M56-featured laptop?
nanonyme: suokko: A shame, that's another thing I'd rather see gone sooner or later. ^^
nanonyme: Errm, does this show normal to you? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=efef7c01ad38e078de2fa3f9e528e4ef7d05d00a
nanonyme: I'm pretty much seeing nothing there. :)
suokko: nanonyme: All new commits from airlied are borked
nanonyme: Wonder why.
suokko: Does same apply to others repositories with new commits?
nanonyme: Nope.
nanonyme: tries out something
suokko: rom1dep: Did you already found the working versions?
nanonyme: Yeah, it's just fine in my local repo of ati too.
nanonyme: Just borked in cgit.
nanonyme: I guess I should just give up on cgit and start using just local repos. :)
rom1dep: suokko: no, I'm travelling in the past...I just found a non compiling revision of mesa... but I'm asking me if the problem is from mesa or xf86-video-radeon...
suokko: rom1dep: It is good idea to use ccache when doing bisect. It speeds up compilation nicely. CC="ccache gcc" ./configure ... to enable it. Then you can do make clean && make -jX
suokko: X as 2 times cores you have :)
mosgreg: suokko: why that? why 2 times cores you have?
rom1dep: ok... :)
nanonyme: suokko: Oh, I thought it was cores + 1. Never heard good reasoning on what to use though. ^^
mosgreg: as far as I know it is X=number of cores
suokko: Idea is that you can run another compilation process while another is doing disk acess so maybe core + a few is better
nanonyme: Well, all sources I've heard so far have been consistent that you should put a bigger value than the amount of your cores.
suokko: Specially when doing distcc it is 2x number of cores if you have enough bandwidth :)
nanonyme: Ah, right.
suokko: But I don't know what is optimal for local only but it is more than numbers of cores. Even in single core machine compile time can be reduced with -j2 if there is enough memory
rom1dep: could use rpm --eval %make to know which option is the best...
nanonyme: No point, probably.
nanonyme: suokko: Any idea what the default is?
suokko: To build in nonparallel mode?
nanonyme: Ah. :)
suokko: I think there is some make files that can't build correctly in parallel mode so default is "better safe than sorry"
nanonyme: Right.
marvin24: OT: I would find it usefull, if some git commit version (+ -dirty) could be added to the "OpenGL renderer string"
marvin24: same for libdrm
marvin24: radeonhd has it already
suokko: maybe version mesa-`git describe` would work
suokko: to version string
nanonyme: marvin24: Imo that date in the renderer string could also be replaced by version in releases and git hash in non-releases. *shrug*
suokko: nanonyme: now he cgit works
nanonyme: suokko: Doesn't matter, I already tweaked gitk so that I can actually use it. ;)
nanonyme: The default fonts and font sizes were pretty much horrible.
marvin24: suokko: there is a git_version.sh script which does the right thing
suokko: marvin24: probably doesn't work in a platform that is supported by mesa
marvin24: suokko: works only where git is working ;-)
marvin24: and bash
suokko: runs from bash
suokko: but that kind of script should work even with packaged source code
rom1dep: suokko: I made
suokko: rom1dep: git reset ORIGIN_HEAD
suokko: or is it ORIG_HEAD?
suokko: rom1dep: Did oyu do hard reset? git reset --hard ORIGIN_HEAD should work
rom1dep: I made a "mixed"
rom1dep: git reset or git reset ORIG_HEAD says that files have been reverted but gitk seems stuck at 2009-08-10
suokko: rom1dep: git reflog and then git checkout
suokko: or git reset --hard
suokko: anyway. with mixed reset you don't change your source code to old version
rom1dep: suokko: You're saying that only a hard restet could help me to find which commit broke libGL here ?
suokko: yes
nesciens: git bisect?
suokko: or checkout
suokko: nesciens: You need to know good revision from history
suokko: Of course you could give some quite old commit that did work for sure
rom1dep: you know what ? I'll rm -Rf ./mesa/ and reclone the repo because all of this is strting to turn me crazy... Oo
rom1dep: starting*
hifi: you can always reset it
nanonyme: rom1dep: Don't do that.
nanonyme: Do rm -rf * inside the repo if you want to wipe the checked out files.
nanonyme: You still retain the cache that way.
nanonyme: (and don't have to clone again)
hifi: git clean -d -f -x is better
nanonyme: Possibly.
rom1dep: nanonyme: i'm unable to reset to a valid date because i understand nothing at git and it's HEAD@{x} ...
suokko: "git reset --hard && git branch -D master && git check -b master origin/master" is the last help if you mess up too badly ;)
suokko: hmm. that probably doesn't work
suokko: git reset --hard && git check -b master2 origin/master && git branch -D master is the last help if you mess up too badly ;)
suokko: that order is better ;)
suokko: /check/checkout/
nanonyme: suokko: Actually the thing hifi said looks good to me.
nanonyme: Apparently pretty much restores everything.
nanonyme: And I doubt you even can mess up so bad you have to delete master.
rom1dep: suokko: thanks, I'll keep this on mind
nanonyme: Just backtracking master far enough into the past that you wipe all your local commits, wiping all local changes and doing git pull should probably suffice...
suokko: nanonyme: You can't but sometimes it is hard to know what has gone wrong so starting from clean situation is easier
rom1dep: nanonyme: git pull says that certain files cannot be updated
nanonyme: rom1dep: Try the command hifi gave.
suokko: git reflog is powerful enough to solve all problems if user is familiar with git
hifi: I always git --reset hard origin/master && git -d -f -x if I mess something up
hifi: err, git reset --hard
nanonyme: Yeah.
rom1dep: too late, I'm re clonigs repos right now
nanonyme: :p
hifi: or restore state after testing some patches
nanonyme: hifi: Neato. That's "reset all tracked files" && "reset all untracked files" in layman's terms?
hifi: yeah
hifi: though if I pull after that I need to reset again to get the latest master
nanonyme: Myeah.
nanonyme: I've often just done rm -rf * && git checkout -f
nanonyme: But your way might be better since it might not necessarily end up replacing unchanged files.
hifi: faster probably
rnoland: anyone tried running kde4 and confirm artifacts and corruption with gl compositing?
adamk: X kept crashing here when I tried it last week.
rom1dep: rnoland: kde4 doesnt's start anymore ;)
adamk: Which I found odd, since X didn't crash for compiz.
rnoland: adamk: ok, i am seeing some lockups in kde... but i don't normally run it...
rnoland: i've only seen the lockups in kde
rnoland: rom1dep: it was as of yesterday...
rom1dep: rnoland: same, but I'm encountering some strangeness since about 1 week
rom1dep: rnoland: what's your chip ?
rnoland: rom1dep: ok... it is the hd4650 i have in right now... so rv730
rom1dep: hum, r420 here
rom1dep: must be mesa instead of xf86-driver-radeon I think
rnoland: the artifacts seem to be a misalignment issue... the right and bottom pixels of windows aren't destroyed when windows (menus and popups at least) are cleared
rnoland: rom1dep: i'm primarily only concerned with r6++ specific failings...
nanonyme: rnoland: The r600 geometric corruption or somethind different?
nanonyme: s/hind/hing/
rnoland: nanonyme: haven't checked < r600
nanonyme: rnoland: Unless you means > r600, that just made no sense. :p
nanonyme: s/means/meant/
rnoland: nanonyme: i've only tried kde with rv730
nanonyme: Yeah, I'm talking of an issue that should apply with that too. ;)
rnoland: which is where i was seeing the corruption/artifacts
nanonyme: The geometric corruption on r6xx/r7xx.
rnoland: nanonyme: ok, i can't confirm on r500 or anything as i haven't tried that.
nanonyme: Where'd you pull an r500?
adamk: rnoland, KDE4 does work on my x1900, with Mesa from Friday and your patches.
rnoland: nanonyme: i have lots of radeons now... but i would have to swap cards to test r500
rnoland: adamk: hrm...
nanonyme: rnoland: No, I meant how the heck is an r500 related with what I just said? :p
rnoland: nanonyme: rom1dep was saying he had some issue on r420
nanonyme: Right...
nanonyme: Well, I didn't notice his posts, just your two last ones. Seems we had a misunderstanding then.
rnoland: nanonyme: so the question is... is the corruption that i'm seeing in kde specific to the r600 driver or radeon in general
nanonyme: Probably specific to r600.
rnoland: nanonyme: that was my thought, but was looking for someone to confirm the issue on linux
nanonyme: There's a big corruption issue specific to r600, before that fixed, hard to say what is and what isn't specific for it.
nanonyme: s/that/that's/
rnoland: nanonyme: no worries... we have made tremendous progress in the last few weeks.
suokko: rnoland: Does you bug look like rasterizzation ould have off-by-one error?
nanonyme: rnoland: Well, yeah. If it's actually the last big thing that's missing, it shows that there's been an awesome progress. ;)
rnoland: suokko: when context menus pop up in kde4, they look fine, when they go away, the right and bottom edges of the window aren't removed
rnoland: suokko: opening the window somewhere else clears the artifact from the previous location
suokko: rnoland: opening new window probably forces redraw. If that artifacts is one pixel width I would suspect it is off-by-one error somewher but if it is whole border (multiple pixels) then I don't know what it could be
rom1dep: suokko: I'm trying your magic command to reset the repo, git check --> "Did you mean this ? checkout"
rnoland: suokko: i'm not sure that 1 pixel would really be all that visible, so it looks like more than that, but i could be just 1
suokko: rom1dep: yes it was typo. checkout should be there
rom1dep: suokko: thanks
rnoland: suokko: i could grab a screen capture if it helps to find the issue...
adamk: brb
suokko: rnoland: Screen captures are good for zooming and see what is happening in pixel level
rnoland: suokko: ok, i'll switch off to kde in a bit and grab a couple...
rxt0: Hey there
rxt0: just a question, which GPU's may actually benefit from VBO and OQ?
MostAwesomeDude: Yes.
MostAwesomeDude: Oh, wait.
MostAwesomeDude: All of them.
MostAwesomeDude: OQ benefits apps that support it.
MostAwesomeDude: VBOs benefit apps that support them, more or less.
rxt0: Is there any hardware restriction? I mean, all generations support that?
MostAwesomeDude: Well, in the r300-r500 families, yeah, they all support it.
MostAwesomeDude: VBOs have been supported since r100 IIUC.
rxt0: now I get it, thanks!
kk_: uhm which apps support vbo at the moment?
MostAwesomeDude: Depends. Most games use them.
kk_: k
rom1dep_: :( It's like no other version of mesa as the last wants to compile
rom1dep_: http://pastebin.mandriva.com/14009
rom1dep_: look at this : do you think I have to try to compile an older version again ?
glisse: rom1dep_: make distclean and then run ./autogen.sh --disable-gallium --with-dri-drivers=r300
glisse: should build properly
agd5f: airlied: feel free to rip out RADEON_DEBUG_BO, it was left over from the r600 bring up
agd5f: benh: I'll ask
rnoland: suokko: the black screen issue with 32bit visual is already fixed in master
agd5f: rnoland: the gemotry corruption is r6xx/r7xx specific
rnoland: agd5f: ok, cool
suokko: rnoland: no. There is only workaround
rnoland: but it is present on linux
rnoland: suokko: ok.
suokko: I mean that double buffered doesn't us Direct Color visual any more but single buffered does use. Only direct color visual has the problem.
rom1dep: glisse: always the same error...
rom1dep: glisse: I don't understand that : why the latest mesa builds succesfully bu no one before
suokko: rom1dep, You might have something messing the build in /xorg/local
rom1dep: suokko: before reverting changes I made a full build of everything (listed in x.org/wiki/radeon) I don't see what could me missing then...
suokko: rom1dep more like there is some header installed from mesa that doesn't like to work with older code
rom1dep: suokko: that means that when I revert changes in the mesa dir, I must revert in other dirs too ? Oo
suokko: rom1dep, no
suokko: I mean that when you do make install with mesa it install header files to /xorg/local/include and then next mesa build accidentally uses headers from there instead of one in source tree
nanonyme: suokko: Shouldn't that be a bug? :o
suokko: nanonyme: of course if it is that
rom1dep: yahh ok, i must make uninstall before making make with an older version...
suokko: rom1dep, No that is just my guess of bug in mesa build which you might be hitting
rom1dep: then I'll remove /local/xorg/lib/libGL.so and ./autogen && && && again
adamk:
adamk: D'oh... Stupid fingers.
rom1dep: wtf
rom1dep: it works
rom1dep: Oo
rom1dep: amazing... kde4 reworks...
rom1dep: then the worriying (is that EN ?) commit is more recent than...
rom1dep: m.cencora -> 2009-08-15 00:52:44
rom1dep: git bisect good
rnoland: does OQ, require libdrm_radeon? or is it just not going to work for me right now?
frojnd: Hello there. I have radeon mobility x1400 128mb/ram
frojnd: Is thisR500 series?
frojnd: where can I find out what series is this card'
suokko: rnoland: Do you have problem with bo parameter count?
rnoland: yep
suokko: frojnd: glxinfo |grep nGL
frojnd: I have installed: xf86-video-ati verseion: 6.12.2-2 but It seems something is wrong with video while watching em. no matter what I watch, xvid, divx, dvd, I get artifacts
rnoland: suokko: also some debug type issues...
frojnd: I mean picture sux, as I would watch low rate videos..
frojnd: OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL
suokko: rnoland: You need libdrm_Radeon or you have to change the code to match others places with RADEON_BO_DEBUG ifdef
frojnd: ok so I installed the "right" one, ati radeon, and not the radeonhd
suokko: frojnd: Can you paste your xorg.log?
frojnd: suokko: ok just a sec
rnoland: suokko: so, i don't have kms... is that going to be a problem? libdrm_radeon has not been needed to build mesa before...
suokko: rnoland: You shouldn't need it now either. It is code bug
rnoland: suokko: ok, will try with updated libdrm
frojnd: suokko: http://pastebin.ca/1532626
frojnd: suokko: note, that video sux only if I full screen it
nanonyme: frojnd: Mesa sounds old.
nanonyme: Are you using Xvideo or GL backend for video playback?
frojnd: nanonyme: Xv
nanonyme: Hmm, odd then.
suokko: frojnd: AccelMethod EXA to xorg.conf might help a bit
frojnd: nanonyme: I tried Xv and Xv (0 - Radeon Texutred Video)
nanonyme: But yeah, what suokko said.
frojnd: in Section "Screen" ?
suokko: frojnd: Do you get video problems if you try to scale video in window?
suokko: frojnd: no. Device
frojnd: I don't even have a Device section
rnoland: suokko: that is with current libdrm
nanonyme: seriously hopes EXA gets the default soon in release drivers :p
rnoland: but no libdrm_radeon
frojnd: suokko: I had windows 2years ago and, no I didn't had those problems, instead I was even able to watch movies in HD 720p...
yangman: frojnd: what kind of corruption?
frojnd: http://pastebin.ca/1532640
frojnd: this is my Xorg.conf after adding EXA
suokko: frojnd: I mean what happens if you scale the player window in linux
frojnd: yangman: cpu loads to 100% and above :P
frojnd: this is the biggest ccorruption also I see flickering all tech way..
frojnd: suokko: well... quality goes down.. like it would be bluered..
frojnd: blured
frojnd: it's not "high" quality as in scaled mode
frojnd: but when I fullscreend then I get "low" quality..
suokko: Which player are you using?
frojnd: suokko: mplayer, smplayer, dragon, vlc,..
beekeeper: howdy
beekeeper: i'm using kernel 2.6.31-rc5 git ~2 days ago, on radeon x1300 mobile (rv515). with KMS suspend/resume leaves the screen covered in crazy garbage
frojnd: I am not able to go back to X
frojnd: Did anyone check my Xorg.conf pastebin?
frojnd: http://pastebin.ca/1532640 after adding EXA option
agd5f: frojnd: add Driver "radeon" to the device section
frojnd: agd5f: didn't helped
glisse: beekeeper: used to work ? do you have pm stuff ?
beekeeper: nah it never worked for me
glisse: beekeeper: which distrib ?
beekeeper: debian sid
glisse: hhhmmm i think you need to disable pm
yangman: frojnd: beyond a certain scale factor video will just look like the quality has gone down, so that's not really an issue. extremely high CPU usage is unusual, though
beekeeper: kernel i build, ddx driver build from org git
beekeeper: i'm very happy with the new VBO support in mesa for r300 :)
beekeeper: what PM stuff should I have?
beekeeper: it is basically debian 5 plus xorg from debian unstable, and custom built kernel, drm, radeon ddx, mesa
glisse: beekeeper: look at /usr/lib/pm-utils/default and set HIBERNATE_RESUME_POST_VIDEO="no"
glisse: in /etc/pm/config.d/
glisse: debian is likely activating some quirks
glisse: look into files you have in /etc/pm/config.d
beekeeper: /etc/pm/config.d, power.d and sleep.d are empty
beekeeper: i've changed the HIBERNATE_RESUME_POST_VIDEO line though
glisse: /usr/lib/pm-utils/default is an example of a file to put in /etc/pm/config.d
glisse: changing /usr/lib/pm-utils/default doesn't do anythings :)
suokko: frojnd: http://pastebin.ca/1532662
beekeeper: ah :,
rom1dep: I'm making tests on the mesa I finally reached ton compile... compositing seems to be already broken in it
beekeeper: never mind. my pm-utils is ancient. i'll see if it works with debian unstable's version :J
rom1dep: and if I run the game stepmania, I finally have a "Couldn't find matching GLX visual" that's part of the strangeness I was speaking about...
glisse: beekeeper: pm utils version doesn;t matter
frojnd: suokko: I was able to restart X, but I didn't get lost of artifacts when In full screen
glisse: just make sure you disable videopost
glisse: or whatever name it has
frojnd: suokko: I wasn't able to get lost of it
suokko: agd5f: I guess that X hang bug is about that with any agp or pci mode italways hangs but pci mode is more resilient and survives 5 minutes
suokko: frojnd: Problem might be that you are scaling past the limits of your card so that might cause artifacts
yangman: beekeeper: http://bugs.freedesktop.org/show_bug.cgi?id=23290 and http://bugs.freedesktop.org/show_bug.cgi?id=23273
beekeeper: so /usr/lib/pm-utils/sleep.d/98smart-kernel-video should be moved to /etc/pm/sleep.d ? it mentions kms
rom1dep: if I find the last revision that fully works, what will be done ?
yangman: should get one of those marked as duplicate...
glisse: beekeeper: yeah sounds good
spstarr: glisse: how goes your GPU reset work?
suokko: frojnd: There has been some improvements to Xvideo after 6.12.2 was tagged so you could try them if you re ready to build your own driver
glisse: spstarr: which gpu ?
beekeeper: yangman: ah that's what i get :D
spstarr: glisse: hmm, r3,4,5,6? :)
glisse: spstarr: having issues ?
spstarr: glisse: no, just curious
spstarr: i cant use my r6xx yet im in Intel GPU mode still
glisse: what's wrong with your r6xx ?
frojnd: suokko: "scaling past the limits of your card so that might cause artifacts" what does that mean
spstarr: glisse: 3D :)
agd5f: suokko: yeah, I got that, but the reporter's update was unclear
suokko: glisse: I have problems with reset not working with M52 after I mess up 3D state with mesa
spstarr: glisse: 2D was working, i didnt have a crash yet
suokko: frojnd: There is some limits how large area can be rendered with single 3D primitive in GPU so if you go past that then there might be tearing. Alsoaonther problem might be that card is too slow and can't keep up with data aount rendering fullscreen video requires
suokko: One last problem maybe that cpu is limiting the speed od decode which would cause artifacts too
frojnd: suokko: with fglrx I was able to watch just normally
frojnd: graphic card is meant to eat HD...
agd5f: frojnd: artifacts could be display fifo related
frojnd: also I have xf86-video-ati 6.12.2-2
agd5f: might want to try git master
agd5f: since that has proper watermark setup
agd5f: frojnd: might also try Option "DisplayPriority" "HIGH"
frojnd: agd5f: in "Device" section?
agd5f: yes
agd5f: also Xv does handle video decode, only rendering, so hd content will have high cpu usuage due to the decode
frojnd: agd5f: model name : Genuine Intel(R) CPU T2250 @ 1.73GHz Core duo...
frojnd: two cores can't handle this?
agd5f: frojnd: sure it can, but the decode will still be done on the CPUs rather than the GPUs
agd5f: that's my point
frojnd: ok.. so there is something wrong with decoding of hd content that cpu goes to 100% and above
agd5f: frojnd: no
frojnd: Option "DisplayPriority" "HIGH" sadly didn't fixed dvix problem
agd5f: frojnd: can you try the driver from git master?
nanonyme: frojnd: The decoding library might also be doing singlethreding which would not properly benefit from you having a dual-core CPU.
nanonyme: Just a note. :3 Probably wouldn't reduce overall CPU usage but rather balance the load.
glisse: agd5f: is this normal that there is a lot of case for which r6xx accel prepare return false ?
suokko: I think glext.h is broken :/ it check that GL_VERSION_X_Y is not set to define some values but then gl. should define them to show that this GL version is available . This problem seems like causing piglit/glean not to compile
MostAwesomeDude: suokko: Better mail the list.
agd5f: glisse: shouldn't be
suokko: I just don't understand what is logic there and is it really broken or what
agd5f: glisse: some planemask limitations, but that's it
suokko: Maybe best is to just send mail and ask in mailing list
glisse: agd5f: i mean for instance for solid, you need pitch to be a multiple of 8 really ?
MostAwesomeDude: suokko: I strongly doubt it's broken, but you could ask the ML.
agd5f: glisse: that's the minimum render target size
glisse: agd5f: so shouldn't the test be < 8 rather than & 7
agd5f: glisse: has to be a multiple of 8 pixels
agd5f: pitch is in pixels rather than bytes
rnoland: agd5f: so i'm sure i've asked this before... but do the scatter gather pages need to be uncached?
agd5f: rnoland: can be either. there's a bit in the gart table to specify what kind they are
glisse: agd5f: so shouldn't we do accel_state->dst_pitch = (exaGetPixmapPitch(pPix).
glisse: right now pitch is computed in bytes
rnoland: agd5f: hrm, so can they be WC or WB?
glisse: rnoland: yes
agd5f: glisse: no. exaGetPixmapPitch is bytes. we need pixels
rnoland: agd5f: what i had before, was that i set them UC in the kernel, but when they got mmaped to userland, they were mapped WB
rnoland: We have fixes for that now, so it is all UC, but i've lost like 300fps
glisse: rnoland: wb is fine
rom1dep: I might have found why kde4 doesn't start... it's looking for swrast_dri.so and not finding it
rnoland: glisse: hrm, ok...
glisse: agd5f: isn't there a way to ask exa to have pitch aligned to 8pixel
agd5f: gotta run, brb
glisse: i thought i saw change in exa alloc stuff
suokko: rom1dep: That means r300_dri.so failed to load
suokko: LIBGL_DEBUG=verbose glxinfo > /dev/null
lyhana8: hi, does open source driver support projector/TV ?
lyhana8: I've a ATI radeon mobility X700 on a toshiba TV
lyhana8: last week I used a kubuntu 8.04 (KD3) + ATI driver, now I'm on a kubuntu 9.04 (KDE4) + open sourcre driver (my card is no longer supported by propietary drivers)
lyhana8: xrandr give me this : http://pastebin.com/med9c53a
suokko: short answer: yes
suokko: long answer is that there were bugs and just 12 hours ago there were some commits fix some of tv out problems
EruditeHermit: lyhana8: do you have Option "TVDACLoadDetect" "true"
EruditeHermit: is X700 r300 or r400?
EruditeHermit: RV 410
EruditeHermit: maybe it needs that option
adamk: lyhana8: Is it plugged into the VGA port? If so, xrandr is detecting it.
lyhana8: Erektium: my xorg is totally empty... which confuse me a bit
nanonyme: You mean the conf?
nanonyme: That's not unusualy, X runs without a conf file nowadays.
nanonyme: s/aly/al/
lyhana8: yep, my xorg.conf. I guess it's the new hal-based organisation
suokko: lyhana8: sudo dpkg-reconfigure -phigh xserver-xorg will make you default bone structure
nanonyme: Hal does some of the work but not all.
nanonyme: Afaik.
adamk: lyhana8: Again, is this projector plugged into the VGA port? If so, just try running 'xrandr --output VGA-0 --auto' to activate it.
nanonyme: Sane defaults help a lot. :)
lyhana8: adamk: yep it's on the VGA port (it's a TV)
lyhana8: does nothing :S
lyhana8: still blinking aka wrong resolution for the TV
beekeeper: /var/log/pm-suspend.log indicates that the S99video quirks thing is disabled
adamk: lyhana8: Try using a specific mode: 'xrandr --output VGA-0 --mode 1024x768' for example.k
beekeeper: has a thinkpad T60 like those other people with resume issues
lyhana8: adamk: same...
lyhana8: xrandr doesn't give any feedback
suokko: lyhana8: Can you paste your xorg.log?
rom1dep_: hi again, I'm back with mesa 7.5 (stable...) but when i run glxgears, I only get Xlib: extension "GLX" missing on display ":0.0".
rom1dep_: and Error: couldn't get an RGB, Double-buffered visual
rom1dep_: with 'Load "glx"'in the module section of my xorg.conf
adamk: rom1dep_: Your Xorg.0.log file should tell you why it's not loading.
lyhana8: adamk: Xorg.0.log : http://pastebin.com/m41ad396d
adamk: lyhana8: Sorry, I don't know what it wouldn't be working. You'll have to talk with one of the experts.
rnoland: up to 2200fps messing with caching so far..
rom1dep_: http://pastebin.mandriva.com/14012
rnoland: still got an error though, fixing that now...
rnoland: i'm still curious which will perform better, WB or WC
lyhana8: adamk: ok thanks anyway, my gf laptop work fine :)
rom1dep_: adamk: do you have an idea ?
suokko: lyhana8: Do you know the resolution that your TV supports?
adamk: rom1dep_: I'm guessing that it's because Direct Rendering isn't getting enabled, and AIGLX is broken since swrast_dri.so doesn't exist.
nanonyme: rom1dep_: Got a xorg log?
adamk: rom1dep_: (WW) "dri" will not be loaded unless you've specified it to be loaded elsewhere.
adamk: rom1dep_: I'd guess that's a big source of the problem.
nanonyme: Wait, what?
rom1dep_: ole
nanonyme: Which drivers are these?
rom1dep_: maybe should i paste my xorg.conf too ?
adamk: nanonyme: He's trying to use the r300 driverse on an x800. GL apps are giving an error about a missing "GLX" extension.
rom1dep_: nanonyme: mesa 7.5, xf86-video-radeon
adamk: nanonyme: His log file: http://pastebin.mandriva.com/14012 GLX is getting loaded, but DRI is not, and AIGLX is broken, too.
nanonyme: adamk: #
nanonyme: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed (libdri too old)
adamk: Oooh, good catch.
simplexe: rom1dep_: your version libdrm?
nanonyme: simplexe: Isn't libdri.so part of the X server?
adamk: It is.
nanonyme: Or anyhow X.org stack.
adamk: Sounds like his Mesa and Xorg are not in sync.
rom1dep_: last, from git
rom1dep_: [rom1dep@Targa drm]$ git describe
rom1dep_: libdrm-2.4.12-12-g1978f6d
nanonyme: rom1dep_: Yeah, it's libdri, not libdrm.
rom1dep_: maybe you wanted to say it's libdrm but non libdri ?
nanonyme: No.
nanonyme: I meant to say what I said.
adamk: rom1dep_: The library it's complaining about comes with Xorg.
simplexe: nanonyme: right it's xorg-server
rom1dep_: nanonyme: how couldn't it be libdri with what given by git describe ?
nanonyme: simplexe: Which is strange since his X server is relatively new.
nanonyme: rom1dep_: Your libdrm git repo has nothing to do with this.
simplexe: may be xorg-server, not consist library libdri.so?
simplexe: rom1dep your distro mandriva?
rom1dep_: simplexe: yep
simplexe: hmm sec
nanonyme: simplexe: Well, it does have libdri2.so.
rom1dep: [19:06:37]
rom1dep: [19:06:41]
nanonyme: Might be an ABI issue.
rom1dep: libdri.so is provided by both packages outputed by Sophie
nanonyme: rom1dep_: Try reinstalling x11-server-common?
nanonyme: That's probably where you should be getting it.
agd5f: glisse: not with classic exa
agd5f: you have a fixed pitch alignment in bytes
simplexe: rom1dep delete x11-driver-video-fglrx
nanonyme: simplexe: That's some IRC bot, it doesn't imply he has it installed.
simplexe: rom1dep and version x11-server-common
rom1dep_: nanonyme: that won't be easy without uninstalling half of the distro and if I force uninstall of this package alone, I fear it won't work...
simplexe: nanonyme: ok ))
rom1dep_: nothing related with fglrx in my rpmdb :)
simplexe: ok
nanonyme: rom1dep_: Hmm, which package manager does this use?
simplexe: may ber reinstall latest x11-common
rom1dep_: ok, I'll rpm -e x11-server-common --nodeps
rom1dep_: nanonyme: urpmi
nanonyme: Don't remove it. ;)
rom1dep_: nanonyme: I'll be able to retrieve it -normally- ..
nanonyme: Errr, URPMI seriously doesn't support reinstalling packages? o.O
nanonyme: Well, I guess you have to remove it then, yeah.
rom1dep_: hummm, maybe if I copy /usr/lib64/xorg/modules/extensions/libdri.so in /local/xorg/lib/ ?
nanonyme: Err, do you have two X.org trees?
nanonyme: Shouldn't affect anything unless you have different versions of libdri.so in the two.
rom1dep_: no, I just folowed instructions on the wiki page to not conflict with distro's headers & co
rom1dep_: ok
nanonyme: Hmm, right.
suokko: rom1dep, wiki might be outdated
rom1dep_: I'have x11-server-{xorg/devel/common}-1.6.1 do I reinstall both of them ?
rom1dep_: suokko: the exact page is http://www.x.org/wiki/radeon, it looks reliable because I'm on kde4 using my ati right now :)
rom1dep_: ok, x11-server-{xorg/devel/common}-1.6.1 reinstalled
rom1dep_: I restart X
rom1dep: have a display...
rom1dep: same error with glxgears
adamk: Well check for the same problems in your Xorg.0.log file.
rom1dep: humhum... I'm just making a diff...
agd5f: airlied: tv changes look good. tested and pushed to 6.12-branch
rom1dep: l77 disappears the one saying "dri" will not be loaded
nanonyme: Can you show a new log?
suokko: agd5f: Can you look at lyhana8's xorg.log if you can see why TV resolution is not detected correctly?
rom1dep: nanonyme: are you interested by a diff ? That's very interesting I think...
agd5f: suokko: got a link?
suokko: http://pastebin.com/m41ad396d
simplexe: rom1dep: may be build xorg packages manually?
nanonyme: rom1dep: Yeah, diff is fine too.
suokko: agd5f: TV is connected with vga
lyhana8: suokko: thanks
agd5f: suokko, lyhana8: what sort of TV? how it it connected?
lyhana8: agd5f: it's a toshiba flat TV using a VGA connection
agd5f: lyhana8: doesn't seem to provide an edid, so you'll have to manually specify a mode
rom1dep_: http://pastebin.mandriva.com/14015
agd5f: not sure what modes it supports over VGA
lyhana8: i tried : 'xrandr --output VGA-0 --auto' and with a specific resolution
lyhana8: I've a ATI radeon mobility X700 on a toshiba TV
agd5f: lyhana8: auto just selected the preferred mode if an edid is available
lyhana8: last week I used a kubuntu 8.04 (KD3) + ATI driver, now I'm on a kubuntu 9.04 (KDE4) + open sourcre driver (my card is no longer supported by propietary drivers)
simplexe: rom1dep this ok, dri works fine
lyhana8: xrandr give me this : http://pastebin.com/med9c53a
nanonyme: rom1dep: I can see definite improvements.
agd5f: lyhana8: you are using 6.12.1, you should try a newer driver from git master or 6.12-branch
simplexe: rom1dep reinstall r300_dri
nanonyme: As in, Mesa.
agd5f: lyhana8: 6.12.1 is pretty old
lyhana8: agd5f: an unstable version ? I'm running under kubuntu 9.04, any idea when it'll be upgraded ?
agd5f: lyhana8: 6.12-branch is stable
rom1dep: simplexe: you mean something like make install in the compiled-sources dir ?
lyhana8: whihch package are you talking about ?
agd5f: I think ubuntu has newer packages
lyhana8: xrandr or xorg-video-radeo ? agd5f
kdekorte: agd5f, have you tried neverball on r6xx yet?
rom1dep: I just was asking me if it's normal that dri and dri2 are activated at the same time...
nanonyme: rom1dep: You're missing the Mesa driver for your card according to that diff.
kdekorte: I just gave it a spin and got Invalid source texcoord for TEX instruction
nanonyme: And you have neither dri nor dri2, really...
agd5f: lyhana8: I'm not sure what the packages are called. the driver is xf86-video-ati, but ubuntu may call it xorg-video-radeon
agd5f: kdekorte: not yet
nanonyme: rom1dep: (EE) AIGLX error: dlopen of /usr/lib64/dri/r300_dri.so failed (/usr/lib64/dri/r300_dri.so: cannot open shared object file: No such file or directory)
lyhana8: agd5f: xserver-xorg-video-radeon
suokko: lyhana8: you can try user made build from https://launchpad.net/~tormodvolden/+archive/ppa
adamk: kdekorte: I tried it last week. It ran, but had huge glitches.
simplexe: rom1dep: reinstall mesa from master branch
nanonyme: rom1dep: Fix that and you're probably done.
kdekorte: adamk, well you got further than I did with todays git
rom1dep: ok thanks to you !
suokko: lyhana8: xserver-xorg-video-ati - 1:6.12.99....
adamk: kdekorte: Yeah, I haven't tried it since probably last Wednesday, so I'm sure lots has changed since then.
rom1dep: went one more time
nanonyme: The last change was already encouraging, you got EXA instead of XAA. ;)
rom1dep: If you're saying it's good :P
lyhana8: suokko: agd5f just install the last version from the ppa, check at the end of this Big Bang Theory episode :)
nanonyme: rom1dep: It is, XAA is the old mostly deprecated 2D acceleration API.
rom1dep: ok I just understood, install has moved everything in /local/xorg/lib/dri instead of /usr/lib64/dri :)
kdekorte: rpm1dep, perhaps you need to pass --libpath=/usr/lib64 to your configure command
kdekorte: rpm1dep ^
kdekorte: geesh... can't type... rom1dep ^
kdekorte: or --libdir
simplexe: libdir
simplexe: or show your spec file
rom1dep: Yepp, I must have missed it when I was with my libGL issues :)
kdekorte: rom1dep, I use this line for mesa: ./autogen.sh --prefix=/usr --libdir=/usr/lib64 --with-dri-drivers=r600,swrast --disable-
kdekorte: gallium
nanonyme: kdekorte: Nope.
nanonyme: --with-dri-drivers=r300
rom1dep: nope
rom1dep: :)
kdekorte: well... alter to your needs
rom1dep: --prefix=/local/xorg
nanonyme: If you wish.
kkk: agd5f, same problem after airlied fixes on tv-out
kkk: -.-
agd5f: kkk: what was the problem you were seeing?
kkk: agd5f, the screen move from right to left very quickly
kkk: doesn't stay stable
soreau: kkk: Are you running any kind of system monitoring software?
kkk: kkk, system monitoring software?
kkk: like?
soreau: Like monitoring fan speed or cpu % etc
kkk: don't think
soreau: ok, nm then
kkk: well,
kkk: soreau, I'm running the cpu frequency controller
rom1dep: humm :) everything works perfectly dri is back and running and glxgears makes my screen flash, as usual, :)
rom1dep: thank you very much !
kkk: and ssh, vnc,
simplexe: rom1dep: )
soreau: kkk: Does the cpu freq controller have a kernel module you can unload?
soreau: The reason I ask is because I knew someone that had the screen shift issue and it turned out to be lm-sensors or something related
rom1dep: I must leave (brunch...) bye !
kkk: soreau, yes
kkk: I will try to unload it
AndrewR: suokko, i have non-3d related question .. can you try to set your DefaultDepth to some non-24 value? (8, 15, 16). For me all != 24 caused strange effect - 8 is black and white, and 16 bpp just too dark ...
agd5f: AndrewR: non-depth 24 is broken in the xserver
AndrewR: agd5f, for how long?
agd5f: AndrewR: a while now
nanonyme: AndrewR: Is there any specific reason for you to want those depths?
AndrewR: agd5f, hm. Only in git master, or in 1.6.x too?
AndrewR: nanonyme, yes, just want to see my desktop in 8bpp :)
agd5f: AndrewR: 1.6.x as well I think. I think it broke somewhere in the 1.5 timeframe
nanonyme: AndrewR: So no. ;)
suokko: nanonyme: There is some old games that only work with 16 or 8 bit mode ;)
nanonyme: suokko: Over Wine?
suokko: nanonyme: There is some native ;)
nanonyme: Whoa, that's a shocker.
nanonyme: I think I completely missed that era of Linux games.
AndrewR: agd5f, https://bugs.freedesktop.org/show_bug.cgi?id=21489 ?
agd5f: AndrewR: yup
suokko: nanonyme: some mini sdl games if I remember correctly. I wanted to try out but then I wasn't that much in trying when I would have to change to 8 bit.
nanonyme: Hmm, right.
nanonyme: Shucks. :/
agd5f: AndrewR: my guess is something palette related in the xserver
agd5f: gamma
suokko: agd5f: Maybe that direct color visual causing black screen is also related to that 8-bit mode causing black screen.
agd5f: suokko: could be
suokko: AndrewR: If you have time and energy you could do git bisect between 1.5 and 1.6 to find what broke it
AndrewR: suokko, or look into changelogs first ....
nanonyme: suokko: Sounds like a damn long commit difference.
kkk: soreau, tried to disable all unnecessary modules, it doesn't solve
soreau: kkk: Well that was my one and only idea ;)
kkk: np -.-
soreau: Maybe someone else knows why you get screen shift
suokko: nanonyme: binary search is efficiency in long history :) probably less than 15 recompilations if not hitting too many compilation or run problems
agd5f: kkk: likely bad timing or pll for pal in your case
kkk: k
soreau: kkk: Oh, tv-out?
kkk: yep
soreau: Definitely bad timing then
soreau: kkk: How are you connecting the card to the tv?
soreau: And dare I ask what resolution are you running on the tv :)
kkk: soreau, tried component and s-video connectors
nanonyme: suokko: Hmm, doesn't sound too bad.
kkk: 640x480 I think
soreau: 800x600
kkk: but xrandr now says that s-video supports only 800x600, so maybe 800x600
soreau: I wonder if there's a way to force use of ntsc instead of pal
AndrewR: agd5f, first find ... xf86SetDepthBpp needs to respect the driver's depth24flags (just guessing)
kkk: soreau, ntsc is ok, but in black-white only
nanonyme: suokko: And yeah, I didn't think of doing binary search. Good point, pretty efficient there.
kkk: in ntsc the image is stable
agd5f: kkk: what card are you using?
kkk: agd5f, rs690
agd5f: kkk: ah
agd5f: kkk: does this patch help? http://www.botchco.com/alex/xorg/adjust_tv_scaler_rs6xx.diff
agd5f: kkk: try both NTSC and PAL
kkk: k
uzytkownik: Hello. I have problem compiling mesa from git. Problem is in R300: http://paste2.org/p/383690 . Do I have something out of date or is it problem with mesa source?
adamk_: I'd start by updating libdrm.
adamk_: That seems like the most likely culprit.
suokko: uzytkownik: http://nopaste.com/p/aHL0DL7egb
adamk_: Or not :-)
AndrewR: agd5f, off for some experimentation ....
kkk: agd5f, same as before
kkk: unstable with pal, stable with ntsc
agd5f: kkk: colors work with ntsc?
kkk: no
kkk: black white
agd5f: kkk: do you see "forcing TV scaler" in your xorg log?
uzytkownik: suokko: Thanks.I'm trying it. adamk_: libdrm from git so probably not...
suokko: uzytkownik: you don't have libdrm_radeon so you are beaten by bug in mesa code
soreau: uzytkownik: /usr/include/drm/radeon_bo.h seems to define radeon_bo_open here
soreau: suokko: What's supposed to provide libdrm_radeon?
suokko: soreau: libdrm if youconfigure it with --enable-radeon-experimental-api
soreau: Ah
uzytkownik: suokko: Should I use libdrm_radeon or patch mesa
kkk: agd5f,
kkk: Using TV scaler 3 3
kkk: forcing TV scaler
kkk: scaler 0 setup success
suokko: uzytkownik: patching should work. That will get fixed tomorrow in mesa
agd5f: kkk: ok
uzytkownik: suokko: Ok. Restarting X to check if it is working.
suokko: unless agd5f wants to apply it now
g-zu: hi, I tried the new vbo mesa master and the vbo don't work quite well in nexuiz - here's a screenshot http://g-zu.no-ip.org/nexuiz000002.jpg
g-zu: sometimes the player is rendered correctly other time it's not
agd5f: suokko: what patch?
suokko: http://nopaste.com/p/aHL0DL7egb
g-zu: :(
AndrewR: agd5f, grabbed few xdpyinfo logs .. this one from 8bpp: http://pastebin.com/m19001a4c
AndrewR: strange (?) 15bpp log has only two visuals ....
AndrewR: http://pastebin.com/m5c538e1f (15bpp xdpyinfo log)
AndrewR: http://pastebin.com/m27ba1a09 (16bpp xdpyinfo log)
sgcb: im getting a lot of errors compiling drm/linux-core, i think it might be a typo but im not sure how to fix it...
sgcb: here is the first many similar errors: /drm/linux-core/drm_pciids.h:733: error: expected identifier or ‘(’ before ‘{’ token
adamk: Where did you get the this drm code from?
sgcb: agd5f r6xx-r7xx-3d branch
nanonyme: sgcb: Could you pastebin whole output?
kdekorte: agd5f, looks like "rain" is regressing now... what is odd is that only half the window is wrong.. left is weird but right is correct
agd5f: kdekorte: same thing as before. if you flush the command buffer at the end of r700RunRender it "fixes" it, but breaks other apps
kdekorte: ugh...
sgcb: here you go: http://pastebay.com/40660
soreau: Compiz water still causing black screen. Any idea what the cause / fix is?
soreau: rv350
agd5f: sgcb: run make clean
nanonyme: doesn't entirely understand what's the cause
osiris_: g-zu: what's up?
g-zu: hi osiris
osiris_: glisse: there's a typo in your last commid. s/num_verts > 65500/num_verts > 65535/
g-zu: well, after a kernel update your vbo_clean branch, and now mesa master...
sgcb: agd5f: hmm, i've tried that multiple times with no dice. This time i removed -j 3 from make and now it compiles!
g-zu: I tried them both and there are some issues I wanted to report
kdekorte: agd5f, what was the flush command again?
glisse: osiris_: good catch, i think i cut & pasted so the typo is likely in 2 places
g-zu: osiris_: take a look at the player in this image http://g-zu.no-ip.org/nexuiz000002.jpg
agd5f: sgcb: the build relies on files that are generated, so multiple makes probably won't work
osiris_: g-zu: this is a bug in the game. http://bugs.freedesktop.org/show_bug.cgi?id=22743
g-zu: osiris_: sometimes it looks ok, sometimes it's completely gray and sometimes completely black
g-zu: osiris_: aah, I didn't think to look there
agd5f: kdekorte: rcommonFlushCmdBuf( &context->radeon, __FUNCTION__ );
g-zu: osiris_: then I'll try other games
osiris_: airlied: I can confirm that after your bo_map fix, all OQ tests are passing under KMS now
airlied: osiris_: so the rv530 seems to only want one pip read
airlied: at leas there
airlied: if I only read one z-pipe number it all passes on this laptop
osiris_: airlied: did you try nonKMS? it worked for me. (now I have tested OQ on rv380)
airlied: osiris_: I don't normally try non-kms it doesn't interest me much
kkk: airlied, I tried the driver after your commits on tv-out, but my screen continues to shift from right to left quickly...do you know how to solve?
kkk: I have a rs690
osiris_: airlied: and I usually test on non-kms because of KMS perf regression
airlied: kkk: hmm my rs690 is dead so its a pain to work out, I wonder if the pll calcs are correct for the igp
airlied: kkk: what are you plugging into btw? is it a PAL or NTSC or both?
kkk: airlied, ntsc is correnct (stable) but in black&white, pal has this problem
kkk: airlied, also r500 has this problem:
kkk: http://bugs.freedesktop.org/show_bug.cgi?id=13995
airlied: kkk: my r500s don't
airlied: is your monitor though NTSC compatible
airlied: it would be nice to know why its black & white
kkk: uhm well, I don't know if it's related, but every NTSC video games for playstation, ps2 ecc are in black&white so it mght be the monior..
kkk: airlied, I have a r500 too, I will try with it
kkk: and will try with another monitor too
airlied: I've only got a dell monitor to test ntsc/pal on
airlied: I wonder if the scaler setup is different on the rs690
airlied: so far I've just dumped the scaler setups from fglrx on rv515 and r580
glisse: airlied: might be different because rs690 have a different ref clock
glisse: iirc
airlied: needs to get a replacement rs690
mjg59: airlied: "needs"
mjg59: Your devotion to duty is noted
airlied: well my other option is to solder a new rom chip to the one I have ;-
airlied: I think ebay might be more successful
rxt0: hey there, I'm actually compiling mesa git on 2.6.28, do I need latest kernel?
mjg59: airlied: Well, the other other option is refusing to touch rs690
kkk: :X
mjg59: A policy you probably should have adopted for rs480
airlied: mjg59: I got a desktop rs480 now, just need to make it boot again
linmax: hello, anyone has an idea why 2d acceleration is not working for me?
linmax: https://bugs.freedesktop.org/show_bug.cgi?id=23334
kk_irssi: lol
kkk: now I can't enable tv-out on my r500 :D
agd5f: kkk: you need Option "ATOMTVOut" "True" in your config
kk_irssi: yeah enable it
kk_irssi: now the primary screen (vga) appears strange, and secondary with tv-out has a black screen :D
kkk: 1024x768 seems correct
kkk: but in tv-out black screen
agd5f: kkk: tv won't work if you are using vga on the same dac as vga
agd5f: as tv
kkk: mmm ok
kkk: how can I disable vga?
nanonyme: linmax: Nothing obvious in your logs.
kkk: simply unplug he cable?
nanonyme: linmax: Tried with a newer X.org stack?
nanonyme: X server 1.4.2 sounds pretty much ancient. :)
linmax: nanonyme, not yet, I tried to avoid mixing testing and sid packages on my debian
linmax: is there some preferred boot CD I can try?
nanonyme: No idea.
linmax: nanonyme, I'll try with an ubuntu boot CD
linmax: brb
nanonyme: linmax: Same probs?
linmax: don't know yet, just switched my IRC client to the laptop
linmax: CD is burning at the moment
linmax: nanonyme: yes, same problem :\
nanonyme: Hmm, odd then.
nanonyme: Well, you have a bug files. *shrug*
nanonyme: Since there's nothing obvious, probably needs debugging. (or someone with enough experience to do very good intellectual guesses)
nanonyme: s/files/filed/
linmax: hm
linmax: but thanks for your help
airlied: kkk: xrandr --output VGA-0 --off might do it
kkk: yeah, I managed to do that
kkk: but still black screen on tv
kkk: s-video is enabled
airlied: got the xorg log?
kkk: mm waity
kdekorte: agd5f, I was able to fix the flickering in glxgears and make etracer/rain work.. but it slows everything way down
agd5f: kdekorte: pretty harsh
kdekorte: yeah....
kdekorte: trying to find a better option
airlied: hmm kms dac detect on the tv-out doesn't like me :-(
agd5f: airlied: it doesn't like most people. that's why it's disabled on the ddx
airlied: agd5f: this is with atom
agd5f: airlied: ah
airlied: I suspect scratch regs of fouling me up
kkk: airlied, http://pastebin.com/fd0b6f9f
kkk: oh shi
airlied: kkk: thats not git master
kkk: oh no ok
airlied: are you testing with that or 6.12?
kkk: mmm yeah I'm using ubuntu 9.04 now
airlied: okay you need to be using git master
kkk: ok
nanonyme: airlied: Btw, is the r600 KMS stuff in Rawhide still of the older batch for F11 or is it already the new stuff glisse's working on?
nanonyme: Just wondering.
airlied: nanonyme: new stuff
kdekorte: agd5f, I found that I don't even need to put the Flush in, just even putting in WaitForIdle or WaitForFrameCompletion does it...
nanonyme: Right.
kdekorte: agd5f, is there something similar to that that does not kill performance?
agd5f: kdekorte: r700WaitForIdleClean() is supposed to do that. it queues a cache flush and stall for engine idle
agd5f: kdekorte: radeonWaitForIdle() polls the engine status reg and waits for it to be idle
kdekorte: r700WaitForIdleClean is just as slow as radeonWaitForIdle
kdekorte: I tried radeonWaitIrq as well... any of those drop glxgears from 1200 to 300
agd5f: kdekorte: no, r700WaitForIdleClean the CP polls, radeonWaitForIdle polls in the driver
suokko: What if you just emit some gpu flush to cs?
suokko: That should take only hundreds of cycles
agd5f: suokko: we already do that's what r700WaitForIdleClean does
suokko: ok
suokko: But I don't understand why it would need flushing so often? Does it reuse something for every rendering operation? Is that configurable? I haven't read programming guide yet ;)
agd5f: kdekorte: this works too: http://www.botchco.com/alex/xorg/r600_idle_on_flush.diff
agd5f: suokko: it doesn't. that's the problem.
kdekorte: agd5f, what I am trying to do is not call rcommonFlishCmdBuf, but call something else that doesn't kill the perf... I've found that you don't need the flush but just calling radeonWaitIrq will fix the rendering issues...
kdekorte: but it happens to kill performance
agd5f: kdekorte: rcommonFlushCmdBuf doesn't kill performance
agd5f: it just submits a command buffer to the hw
kdekorte: true, but it causes artifacts in glxgears
agd5f: kdekorte: http://www.botchco.com/alex/xorg/r600_idle_on_flush.diff
kdekorte: yeah that patch does better...
kdekorte: 800fps vs 300fps...
nanonyme: What are you doing, actually? ;)
kdekorte: I think if you use the above patch and add in rcommonFlushCmdBuf( &context->radeon, __FUNCTION__ ); back to RunRender it makes etracer work and glxgears doesn't flicker
kdekorte: gotta go... be back later
nanonyme: Hmm, interesting...
nanonyme: Ah, so not a big change per se.
kkk: airlied, ok
kkk: airlied, with r500 is fine with both pal and ntsc
kkk: so it's a rs690 related problem
airlied: kkk: okay sounds like it might be clocks then
kkk: OT: also, with r500 and ubuntu's uplash the screen flickers badly
mjg59: kkk: Using KMS?
kkk: mjg59, nope
mjg59: kkk: Nothing to do with X, then
mjg59: usplash uses vesa
kkk: yep, maybe the ati framebuffer is better
mjg59: KMS certainly should be
kkk: k
airlied: once I add tv-out to it it will be
airlied: is doing that now ;)
kkk: :P
Sinuvoid: Was osiris on earlier today?
nanonyme: Probably, there's some stuff by him in my backlog still.
Sinuvoid: I want that VBO thing to work :\
Sinuvoid: Any progress on it?
airlied: it was merged to master
airlied: agd5f: crtc_dtd_timing on r4xx doesn't get filled out for tvout by the looks of it
airlied: agd5f: atombios_crtc_mode_set in the DDX
Sinuvoid: airlied, so it works?
airlied: Sinuvoid: well it must if it was merged ;-)
Sinuvoid: :P I'm still pretty new to the git/svn thing.
Sinuvoid: So i just have to checkout and compile it, right?
Sinuvoid: As a new mesa?
nanonyme: kdekorte: I think not, the geometry corruption seems to affect etracer too. :)
airlied: Sinuvoid: pretty much
Sinuvoid: Okay, thanks
nanonyme: (very interesting to slide down a mountain when you you can't tell whether you're going to hit a wall or not ^^)
nanonyme: (but yeah, does work for the menu corruption though)
nanonyme: Oh, it's intentional that the gears aren't symmetrical in geartrain. Good to know. :p
MostAwesomeDude: XD
nanonyme: (only now got to try it with software rasterizer; I before just assumed it was a rendering error with r600)
nanonyme: Well, how was I supposed to know? ;)
nanonyme: And appears the r600 lockup is just an X lockup and not in kernel, thank goodness. :) Should probably fix my laptop so I can run SSH on it...
agd5f: airlied: never got r4xx tv-out working with atom, maybe the missing dtd stuff is to blame
bridgman: agd5f; ping
bridgman: anyways, new patch came in just after I left the office, will try tomorrow am
bridgman: unping
kdekorte: agd5f, ping
airlied: agd5f: in ddx we have scaler setup in output, in kms in crtc, I'm thinking output makes more sense
airlied: but only because I have to figure out tv std
vehemens: do today's r600 fixes, eliminate the corruption problems?
bridgman: vehemens; not yet
bridgman: but agd5f seems to be making some progress herding it into a corner
DanaG: bridgman: somebody in #ati seems to be having issues with MTRRs (beyond my ability to help, for now) -- conflicting memory types. Would you be able to help with that?
bridgman: probably not, usually I just tell people to stop messing with them and everything starts to work ;)
bridgman: it usually means there are two different drivers fighting over the hardware
vehemens: bridgman: further down the rabbit hole goes agd5f then. hope he finds the bottom soon.
bridgman: yeah... we don't have actual proof there's a bottom, but we're hoping
agd5f: airlied: glisse changed a bunch of that stuff from output to crtc
agd5f: kdekorte, bridgman: pong
bridgman: I already turned the light off and unpinged ;)
airlied: agd5f: well I've rewritten a big chunk of kms solving the shared encoder ;-)
airlied: I'm giving VGA priority over TV
agd5f: airlied: sweet
agd5f: kdekorte: same thing I did :) http://www.botchco.com/alex/xorg/r600_idle_on_flush.diff
agd5f: kdekorte: not really a fix though, more of a workaround
rainbyte: hi
rainbyte: I have installed xf86-video-ati yesterday, all seems to be ok but when I tried to see some mkv bluray rips I got a msg saying "your system is too slow for playing this" on mplayer
rainbyte: after that I tried with catalyst and xvideo works well without that msg
agd5f: rainbyte: make sure the dri is enabled
rainbyte: is that normal? (I thought xvideo was better with xf86-video-ati that with catalyst)
agd5f: rainbyte: make sure you have Xv with the open driver. if you have r6xx/r7xx hardware, you need at least kernel 2.6.30
rainbyte: agd5f, xvinfo says that xv is enabled
agd5f: rainbyte: does it play ok?
rainbyte: now I'm with catalyst, I have to install xf86-video-ati again
bridgman: agd5f is saying to make sure xvinfo says xv is enabled when running the -ati driver
rainbyte: but yesterday I read the Xorg.0.log and xvinfo and all was ok
rainbyte: bridgman, hi
agd5f: rainbyte: it could be that mplayer just assumes fglxrx is faster or something like that. if it works ok it should be fine
rainbyte: bridgman, yes, with xf86-video-ati I have xv enabled, that's what I'm saying
rainbyte: agd5f, the video is a bit slow
rainbyte: in the fast moving parts the video lags behind the audio
agd5f: rainbyte: what chip?
agd5f: also, are you using Xv or GL with mplayer?
rainbyte: RV610 (Radeon HD2400 Pro), I have this problem only with bluray rips (@1920x1080) using xvideo
bridgman: you might just be maxing out the CPU... agd5f, doesn't the tear-free code use some CPU ?
rainbyte: sometimes with 1270x720 at higher bitrates the problem shows again
agd5f: bridgman: no, the CP polls for vline
bridgman: rainbyte, what is cpu utilization with each driver when you're playing bluray rips ?
rainbyte: bridgman, with xf86-video-ati the cpu is at 80% or more if I remember well (I'm installing the driver againg to give you the real numbers)