soreau: I am having a horrible time with the driver lately, it's all messed up. On arch, it runs like swrast slow and on gentoo, it just gives a black screen with compiz
soreau: Now I see even without compiz, making a fullscreen hulu window has major problems, black pieces all over the place, unwatchable
soreau: I'm dying without ezoom here
soreau: can't do anything without compiz :P
soreau: This is rv350
soreau: x86 32 bit
soreau: drivers are broke
soreau: but all logs say everything is fine
freedrull: what card do you have soreau
soreau: it's rv350 radeon 9600
freedrull: i still can't get my card to use the accelerated opengl renderer
freedrull: (II) [KMS] drm report modesetting isn't supported.
freedrull: i can't tell if that means KMS isnt supported, or "reporting the modesetting" isnt supported
soreau: freedrull: Can you pastebin your X log?
freedrull: soreau: http://pastebin.com/fKW9i8mu
freedrull: there's lots of drm errors starting around line 346
Nightwulf|work: hi all
soreau: freedrull: You need to build your kernel with drm radeon and re-emerge libdrm, mesa and xf86-video-ati
freedrull: soreau: i have drm_radeon enabled as a module, i'll try re-emerging said packages
Nightwulf|work: is there any way to enable s-video with radeon when using KMS for r6xx/r7xx atm?
agd5f: Nightwulf|work: should work out of the box
Nightwulf|work: agd5f: hmm...I'm sad it doesn't...if I use UMS it works, using KMS switches the TV-Out (s-video) port immediatly after loading the modules during the boot process
Nightwulf|work: +off :)
Nightwulf|work: agd5f: but i need to use KMS since I get artifacts with UMS e.g. while scrolling in kdevelop4 which I don't get with KMS...and the only drawback with KMS i see atm is, that flash on websites slow down and fps in glxgears is nearly a third of the fps i get with UMS
agd5f: Nightwulf|work: try a newer kernel maybe
Nightwulf|work: agd5f: hmm..I use 2.6.33.1...do you think differences are that big in 2.6.33.2?
agd5f: Nightwulf|work: I don't recall what went into 33.2. best bet is 2.6.34rc
Nightwulf|work: agd5f: I'll give it a try tonight...thx!
mcgregor: I am currentlyx testing dynpm on my rv730. works fine so far. but I see it changes often it's settings. is there anyway to make it more solid (yet)? like, I want it to be on low performance all the time?
mcgregor: and besides that, that settings seems to me a bit strange: the information about PM shows: 2 engine/memory: 300000/250000 for example, but dmesg tells it sets to 30000/25000 which is only 10% of it. it that on purpose or more like a "typo"?
diverse_izzue: i have my mouse pointer disappear after resuming from standby. mouse input still works, i just cannot see the pointer. does that issue sound familiar to someone?
mcgregor: diverse_izzue, I had once an invisible mouse pointer, not after standby. are you uptodate with ddx/libdrm?
diverse_izzue: mcgregor, that's on up2date lucid, so fairly recent
mcgregor: alright. so I have no other ideas for you, sorry
freedrull: soreau: i think the issue is /usr/lib/dri/swrast_dri.so is getting loaded, and i want /usr/lib/dri/r300_dri.so to get loaded instead(since i believe xpress200m is the r300 chipset)...not sure how to fix tho
twiztid: Hey, all... if any1 has a moment, im trying to perfect the radeon driver and get KMS situated... my overall hurdle is poor video streaming yet compiz is ok
twiztid: any suggestions; Im NOT using xorg.conf
freedrull: maybe not tho.....ldd /usr/lib/dri/r300_dri.so shows something...so it *is* being used somewhere
freedrull: does this channel have a mailing list, and if so would mailing it with a support related question be appropriate?
twiztid: I attemped to add the radeon.modset=1 to grub but upon reboot i got: (EE) Open /dev/fb0: No such file or directory,
twiztid: anybody out there that can help out? please reply I attemped to add the radeon.modset=1 to grub but upon reboot i got: (EE) Open /dev/fb0: No such file or directory. Im also stumbling with video streaming through any browser... please help
Nightwulf|work: twiztid: sounds like the needed framebuffer modules didn't get loaded
Nightwulf|work: twiztid: at least fbconn has to be loaded
twiztid: ...thatnk u so much... will i have to make a xorg.conf? cause im not currently using one...
Nightwulf|work: if you don't want to have special settings and the automatic configuration of xorg works for you, then you don't need one
mcgregor: twiztid, does kms work for you?
twiztid: not from what i can see, is there a cmd to summon if its enabled/running?
mcgregor: wel, if you boot, you probably would see a change of resolution
Nightwulf|work: besides that, grep "KMS" /var/log/Xorg.0.log should show a line saying, that it is enabled
mcgregor: twiztid, you would be getting in dmesg kernel log something like this: http://pastebin.org/138754
twiztid: ok, (II) [KMS] drm report modesetting isn't supported. *xorg.0.log
Nightwulf|work: twiztid: did you insert the fbconn module and restarted X before looking into the log?
mcgregor: twiztid, look o me like you're not having a xorg problem but a kernel problem.
twiztid: im using lucid for kms but still in karmic
Nightwulf|work: lucid? karmic? wtf?
mcgregor: could you maybe paste your dmesg log?
mcgregor: pastebin.org for example
twiztid: ya sure, on it...
Nightwulf|work: thinks, twiztid simply doesn't load fbconn
twiztid: http://pastebin.org/138758
twiztid: sry, nightwulf: i was looking into that too...
mcgregor: your paste is broken
twiztid: darn, sry 1 sec
Nightwulf|work: cool paste...never seen that many empty lines ^^
mcgregor: hehe
twiztid: lol ok, somehow im not doin gthis right apparently... dmesg log right?
mcgregor: yeah
twiztid: ya, thats wat i got...
mcgregor: have to leave, good luck ;)
Nightwulf|work: twiztid: you definatly didn't get hundrets of empty lines...copy to pastebin must have failed
Nightwulf|work: twiztid: but please ignore that dmesg paste for a moment and check wether you can load fbconn module and if so, please restart your X server
twiztid: k will do
twiztid: please forgive me, how would i go about loading fbconn? -_-
Nightwulf|work: twiztid: open a console as root and enter "modprobe fbconn"
twiztid: module not found
Nightwulf|work: then your kernel is missing support for it...you will need to build/install a kernel which does
twiztid: even though im using the lucid kernal in karmic? this tutorial instructed me to install lucid kernel for kms...
twiztid: https://wiki.ubuntu.com/X/KernelModeSetting
Nightwulf|work: twiztid: i dunno anything about ubuntu...all i can say is, that the driver searches for the framebuffer device and doesn't found it and manually inserting the needed module failed because it's not there
twiztid: makes since... would you happen to know of a kernel that can use fbconn? because from what ive learned is that x1300 r515 radeon cards support kms. Would KMS have anything to do with poor video streaming in web browsers?
Nightwulf|work: r5xx are older cards which have a 2d-engine in hardware...newer cards do 2d operations using the 3d-engine...but i doubt kms will do a major difference there...
Nightwulf|work: but you should ask a developer of the driver code for a 100% answer since I'm a simple user too
Nightwulf|work: well...and as i said, i don't know anything about ubuntu and therefore i know nothing about it's available kernels...I build my kernels on my own for years
twiztid: ok then, im satisfied without kms then, ive tried diffrent browsers, opera better than mozilla but remains slow.
twiztid: I want to learn how to compile so badly because subconciously knowing that my kernel has to go on a diet is frustrating... lol
Nightwulf|work: are you sure, that acceleration works at all, no matter if KMS or UMS?
twiztid: i have direct rendering...
dileX: hi
Nightwulf|work: twiztid: please paste the output of "glxinfo" to the pastebin
twiztid: ...regular video play back is supurb, even in a cube and on a corner... but the browser, like flash maybe? is choppy
twiztid: k on it
twiztid: http://pastebin.org/138772
yoshi314: twiztid: did you try using vlc instead of flash?
yoshi314: flash works ok with kms for me, and i also have rv515, but on pci-e
Nightwulf|work: twiztid: ok, I can second, that hw acceleration in general works on your machine
yoshi314: but playing flash via vlc plugin is much better
twiztid: no actually... ok ill try vlc...
yoshi314: twiztid: there is a greasemonkey script to redirect flash playback to vlc, at least for youtube
twiztid: ya compiz is smooth, except motion blur and alpha blu
yoshi314: twiztid: did you try with gallium driver?
twiztid: ...and ya AGP 2.0 here max 8x but the kernal only allows 4x
twiztid: never heard of...
yoshi314: it's an experimental 3d driver, you can get it by building get mesa snapshot with extra parameter
yoshi314: it advertises opengl 2.1 on my card in glxinfo
yoshi314: darkplaces and ta3d works pretty neat with it, and i like it ;)
yoshi314: *git mesa snapshot
twiztid: hrmm, ok, soaking like a sponge... bare with me are those effects like compiz-fusion? or ..?
yoshi314: it *might* improve compiz behavior
twiztid: nice... how about video streaming in web browsers? any good?
yoshi314: darkplaces is a quake1 engine with modern graphical features (shaders, hi-res textures etc)
twiztid: sick, i grew up on doom
yoshi314: i'm not having issues with it. well, the pcsx2 still doesn't run, but i don't mind ;)
Pallokala: I grew up with Wofenstein 3D
yoshi314: Pallokala: me too
Pallokala: and 3-demo
Pallokala: 3-demon
twiztid: ya i threw psx on windows... im jus tryin to smooth out linux to stomp windows... xD
yoshi314: i remember that 3d game techdemo before quake1 came out (what was it called?). that was awesome
twiztid: thank you all for your help, been taking notes...
twiztid: nightwulf was trying to tshoot kms but as it turns out my kernel (lucid) doesnt allow the fbconn module, is it difficult to compile a kernel that does or is there a flavor that does?
legume: twiztid: it's fbcon not fbconn
twiztid: oh ya thx... that helps lol
twiztid: Legume: would you happen to know of a kms 'able' kernel or a workaround for choppy video streaming in web browsers?
legume: twiztid: Also there are patches for agp + kms that help flash + KMS, they should get into kernel soon. (assuming you see the same problem on r300 as I get with r600)
yoshi314: legume: can you shed some more info on that patches?
twiztid: no, i think this version of the lucid kernel wont allow fbcon
twiztid: ...and yes please do elaborate on that patch cause AGP is me, stuck in 2.0
Pallokala: lucky you, my AGP is stuck in PCI-mode
legume: twiztid: I use git trees on an LFS setup, so I don't know about other things - will find a link to the patch in a minute, but I think something like it will get into kernel soon.
legume: twiztid: AGP 4x is fine, maybe 8x would cause problems for you - it won't affect flash or anythinng really.
twiztid: ya i thought about that, only to find that 8x in the most recent kernel is 'at own risk'
twiztid: Pallokala: Im not sure if agp is fully supported on my setup, though I havent hit any snags
twiztid: if i were to try out Gallium and my performance gets worse, is there a easy way to retort back to the 'radeon' driver?
twiztid: ...wat about radeonhd?
legume: twiztid: radeonhd probably won't help, you should be able to get back to r300 from r300g, but I've never done it as I have r600.
twiztid: is there a way to 'test' the driver in a vm?
legume: twiztid: https://bugs.freedesktop.org/show_bug.cgi?id=26641 has the patch, but it may not apply over your kernel.
twiztid: thx alot, i bookmarked it, but i gotta get kms runnin first... after placing the radeon.modset=1 in grub and reboot i get (EE) open /dev/fb0: No such file or directory
twiztid: nightwulf deemed my kernal 'unsupportive' of kms... how would i go about compiling a kernel that allows kms or at least installing one that does?
legume: twiztid: Oh, I thought your perf problem was with kms - if you get bad flash perf with ums it coul be something that was fixed in xf86-video-ati.
twiztid: well i though that enabling kms would help with flash performance... sry, am i missing out without kms?
legume: twiztid: it's the opposite for me currently, but will be fixed soon.
twiztid: ...im currently looking how to download and install, 2.6.33 rc8, that apparently has agp-kms support
legume: twiztid: If you wan't to build a KMS testing kernel look at the wiki that's linked in the topic of this channel.
Wizzup: KMS 2d support has improved a lot lately. (at least on r600)
legume: twiztid: I would also check with your distro forums etc. they may already have an easy way to test - but I know nothing about distros.
legume: twiztid: Remember to also use the latest ddx (xf86-video-ati)
twiztid: cool bookmarked it... ya ive been up and down many sites... am i already using ddx?
legume: twiztid: yes ddx is the X driver.
legume: twiztid: using the latest may (or may not) help you with flash.
twiztid: ok, noted, im still simple, thx.
twiztid: found update, came out yesterday actually... xD
twiztid: and they speciffically say, 'The new features as of the ATI X.Org 6.13 series include support for kernel mode-setting on all ATI GPUs from the R100 series up through the latest Evergreen "R800" series'
twiztid: they go on to say that even the tricky gupfan (power managment) bug has been handled! whoop whoop!
twiztid: ... is it possible to install the 2.6.33 rc8 kernel in karmic and update the ati driver without conflict to each other?
dileX: why do you insist on 2.6.33-rc8?
twiztid: it supports agp and kms
dileX: and 2.6.33.2 does not?
twiztid: i dunno does it? im runnin karmic with lucid's kernel now
dileX: sorry, dont follow ubuntu development.
dileX: http://wiki.x.org/wiki/radeonBuildHowTo#Distro-specificdevelopmentpackages
dileX: ...could help you.
twiztid: awesome thx ya overall video streaming from a web browser is horrable and locks the browser up so i was hoping kms could help
dileX: IIRC xorg-edgers has daily new (dev) packages
twiztid: so its not kms?
dileX: what is "it"?
twiztid: Kernel Mode Setting
twiztid: I added 'radeon.modeset=1' to the end of the line 'GRUB_CMDLINE_LINUX_DEFAULT=' in grub, updated it, rebooted and i said (EE) Open /dev/fb0: No such file or directory...
Nightwulf|work: twiztid: sorry for the fbconn typo...that one goes on me :-/
twiztid: its all good man thx alot for your help! found out alot
dileX: twiztid: anyway. wild speculating wont help. have a look into the build-howto. it has a lot of infos and hints.
twiztid: ya ive been lookin over it, thank yo all very much, i think im going to go ahead with installing kms enabled kernel and kms enabled radeon driver... one last question tho...
twiztid: do i still have to include 'radeon.modset=1' in grub? or are the driver and kernel updates default KMS?
dileX: that depends
dileX: http://wiki.x.org/wiki/radeonBuildHowTo#TroubleshootingKMSproblems -> "There are several possibilities to enable drm-radeon-kms on startup"
twiztid: cool beans then, ill get hackin... once aain thank you nightwulf, yoshi, legume, and dilex... this my first IRC contact and it sure beats endless forums! ;)
dileX: twiztid: n.p. with this. every IRC channel has a topic - worth reading and saves your and ours time.
twiztid: true dat, and thx to all of yall the world has one more penguin lurkin from the transistors! take care all and happy slidin!
rahman: Hi, I have hd4770. glxinfo reports OpenGL version 1.5 It says driver supports OpenGL 2.0 in X.Org wiki
rahman: Is there a way to get OpenGL 2.0 support?
legume: rahman: You need to be using KMS to get 2.0.
rahman: legume: KMS to get 2.0 ? So it is not related to mesa version? I have mesa 7.7.1, should I upgrade to 7.8?
legume: rahman: Not sure which mesa will do, but if I boot with UMS I don't get 2.0, with KMS I do.
rahman: legume: thanks, I will give it a try.
bridgman: rahman, FYI the reason you need KMS is that KMS brings along the GEM/TTM memory manager, and it's the memory manager that is required for GL 2.x
rahman: bridgman: Thanks for the explanation :) I just wonder how long will it take to all the things like galium etc. to be finished and we have a solid graphics subsystem.
bridgman: what are you expecting to get from gallium ?
Thunderbird: if you look at the past for other drivers like G400, Radeon 7xx/8xxx/9000, 3dfx, it takes a few years to get a solid driver; gallium will make writing drivers easier but a driver for modern GPUs is still more complicated than for the older ones
bridgman: the level of expected functionality is going up a lot as well, used to be "wow, gl 1.3" now it's "eww, only GL 2.0" ;)
Ke: don't forget opencl-1.0
Thunderbird: certain websites who read git logs, make it sound to a lot of people that gallium is a great thing and that drivers using it are nearly usable
Ke: pats Thunderbird
rahman: bridgman: I don't care about galium or an other project as a uer :) All I want is good 3d , hardware accelleration for HD movie playback, proper power management. I already have good 2d. Well, actualy we want our cards to work NORMALY as they work on other OS'es :)
Ke: rahman: so you care about gallium
Thunderbird: good enough 3d for games like ut2004 is doable but good enough 3d to run for instance modern games on Wine well is very, very hard (a good GLSL implementation is needed, good FBO support and much more)
Thunderbird: and I'm also skeptical about HD movie playback
rahman: Ke: if it will make things easier for devs which will effect user experience than yes I care Galium :)
bridgman: depends what you mean by "good 3d" I guess - on 6xx and higher you aren't waiting on gallium3d for GL 2.x and enough support to run modern games
bridgman: the glsl code is common between gallium3d and classic code paths anyways
Thunderbird: I doubt the registers for that purpose will be documented, likely shaders have to be used
bridgman: gallium3d is kind of orthogonal to uvd acceleration as well, but it is the path most folks are thinking about for shader-based acceleration
bridgman: we're not making any commitments on opening up uvd, although we are going to try
Thunderbird: I can imagine that separating macrovision / copy protection is the tricky thing
Ke: does uvd actually have hardware different from the shaders?
Ke: sounds a bit silly
bridgman: yep... they need to be tightly integrated for efficiency & low power, but that's a problem for opening up support
bridgman: Ke; yes, UVD has separate hardware for bitstream decode and motion comp
Ke: well low power for watching movies is typically non-issue
bridgman: the decode part is done in UVD, everything downstream (scaling, color space conversion, filtering etc.) is done on shaders
bridgman: low power for watching movies is the primary reason we added UVD; the classic "watching DVDs on a laptop on an airplane" use case
bridgman: now mostly obsoleted by in-flight movie systems ;)
maligor: big deal about only opengl 2.0 support, would be nice if dynpm worked properly :P
bridgman: the other use case - "watching movies with a wussy CPU" can be helped with shader-based decode accel
bridgman: yeah, everything becomes less important once it's implemented and working ;)
twnqx: which reminds me i wanted to test the patch agd5f gave me yesterday
twnqx: (my gpu clock scaling already works)
rahman: Is it doable? Decoding with shaders? I dont remember where I read it but some say decoding CABAC is not suitable with parallel processing. So its very hard to decode them on shaders if not impossible?
Ke: but really opengl-2/3 is not really just for wine aso. people who develop stuff on linux, would like that too
twnqx: cabac is something you shouldn't do on the gpu, no
bridgman: I don't think trying to do the whole decode task on shaders is worth it (I wouldn't touch entropy decode for example) but there's a lot of work in the decode part where shaders can help
twnqx: like the idct
bridgman: Ke; the point is that the driver is at GL 2 already, but GL 3 needs a lot of work in the framework outside the driver
bridgman: probably more outside the driver than inside
twnqx: which can be parallelized
bridgman: that's what the nice vmware/tg folks are working on
Ke: bridgman: that typically also includes extensions and glsl
bridgman: twnqx; I'm not even sure if IDCT is worth doing on GPU; IIRC the processing for h.264 is less work than for previous standards, it was deliberately designed to be easy to implement on a regular CPU
bridgman: Ke; GLSL is there today, although bugs are still being found & fixed; which extensions are you thinking about ?
Ke: bridgman: no idea, I only care about opencl
Ke: bridgman: and other compilers for the stream processor array
Ke: but that's what they at least used to complain about
bridgman: ok, that was probably before gl 2.0 support was added late last year
gordboy: about fscking time with the 6.13 release guys. see you in 2 years for the 6.14 release
mcgregor: lol
mcgregor: what a nice guy
Ke: =D
Ke: (Though I have to agree that 6.12 was unacceptable)
glisse: we don't release until ready period.
Ke: eg the XAA as default makes baby panda cry
mcgregor: glisse, I think that approach is definitely right. the devs should decide and nobody else. and as airlied already pointed in one thread, this is open source. everybody can fork it and release whatever version he wants
zhasha: mcgregor: and anyone can get commit access at least to the mesa stack. case in point: I have commit access
Ke: someone could have released a version with just the default switched to EXA ;o)
mcgregor: actually, there is no real discussion about that. that guy was just whining all along. I can't say it often eough: just ignore him :)
Ke: and he is no longer here
mcgregor: hmm I would really so much like to know what the minimal power usage is possible with my laptop, with power management. with the current PM from 2.6.34-rc3* it drops about 7W or so. people reported with fglrx a lot higher power drop
glisse: best is you to try fglrx
mcgregor: I'll consider what
mcgregor: *that
gormux: hi all
gormux: i have a few questions about evergreen support
gormux: is it basically usable ?
adamk: There is no acceleration on r8xx hardware.
adamk: Just 2D modesetting.
gormux: i mean, can I play videos and have a GUI ?
adamk: Videos might be problematic, depending on their resolution.
gormux: no fullhd then, even with a very good cpu ?
Ke: tru it out
adamk: gormux, Can't really say as I've never tried HD playback without Xv support.
Ke: IIRC i did that with xf86-video-intel
gormux: ok
gormux: i'll have to test this
Ke: at least they claimed that there was no xv in early KMS versions
jcristau: there was textured xv, just no overlay, afaik
gormux: otherwise i'll just put my 5770 in a box and go buy a cheap 4xxx series
mjg59: agd5f: Am I right in thinking that we don't use any of the Radeon CP semaphores right now?
glisse: mjg59: we don't
mjg59: glisse: Ok. Is there any way to wait on a register value in r500?
glisse: yes
glisse: WAIT_MEM_REG packet3 or similar
mjg59: glisse: Only seems to be in r600
glisse: oh yeah i thought it also existed on r5xx
glisse: it seems it doesn't
mjg59: Maybe I should figure out WAIT_MEM
mjg59: So, assuming that I know nothing about how graphics cards actually work:
mjg59: How do I allocate memory that's visible to the GPU?
glisse: mjg59: you can us the wb stuff
glisse: there is a buffer there which should be in gtt visible memory
mjg59: Ok. And I can allocate chunks of that?
glisse: right now we don't use it
mjg59: Convenient
glisse: so you can do what ever you want with it
mjg59: And what address space does the gpu use? Just physical?
mjg59: Or is it manipulated by the gtt?
glisse: gpu use gpu address space
glisse: see how we program cp to get the gpu addr
mjg59: Ok
mjg59: \o/
mjg59: The stress test didn't lock up the GPU
mjg59: Three hours of clock changes
mjg59: glisse: So it's the offset from dev->agp->base or dev->sg->virtual + gart_vm_start?
glisse: a sec
mjg59: (Looking at how the ring buffer address is generated)
glisse: radeon_bo_gpu_offset(struct radeon_bo*)
mjg59: Oh, heh. Yeah, that makes life easier.
glisse: return a valid gpu offset
mjg59: glisse: And this is all entirely unused right now?
glisse: the wb stuff is unused
glisse: we should use it
glisse: sight my todo list is big
mjg59: Is there any process I should use for borrowing 8 bytes of it?
glisse: no interface yet
glisse: but we should have something like scratch reg interface in the future
glisse: at least that's my plan
mjg59: Ok
mjg59: So for right now, I'm just going to use the bottom of it
mjg59: And we can sort that out later
glisse: yeah
makkalot: kernel 2.6.33.2 ,kms enabled ,when startx black screen with no action ,xorg.log : http://paste.pocoo.org/show/198325/ ,dmesg : http://paste.pocoo.org/show/198323/ any ideas how to fix ?
mjg59: glisse: Wow. Worked first try.
mjg59: I think so, anyway.
mjg59: Let me comment out the unlock and see if it breaks
mjg59: Both. Still worked, which probably means that it's not blocking.
shadowmaster: makkalot: that vaguely looks like a malfunctioning kernel
shadowmaster: (I mean for the oops reported on line 671 of the dmesg paste)
Dice-Man: hello world !
mjg59: glisse: Hrm.
mjg59: glisse: Are the scratch registers perhaps mapped into the wb space?
makkalot: shadowmaster: what do you suggest uding a more recent kernel ?
mjg59: glisse: Because I'm seeing what looks like the fence count ending up there
makkalot: 2.6.33.2 is pretty new actually ?
glisse: mjg59: oh yeah they are napeed
glisse: maped
glisse: mapped
shadowmaster: makkalot: yes, it's the latest stable patch :P
shadowmaster: no idea what is going on there but it doesn't look good
mjg59: glisse: Heh. Ok, that would explain my issues there!
mjg59: glisse: This actually makes things easier
makkalot: shadowmaster: acyually when booting i get some redaon errors the kernel hangs for a while and after 1,2 minutes boots normally have no idea what is going on
glisse: thought they shouldn't be used right now
glisse: due to agp
mjg59: glisse: Oh, ugh. Ok.
mjg59: So I just need to use space past the end of the scratch registers
glisse: yeah at 1024 byte it should be ok
glisse: or even 256
mjg59: Hm. Can I allocate a scratch register and then only use the memory location?
mjg59: If I only go through memory I should be safe even on AGP, right?
glisse: yeah you can do that
glisse: no won't be safe on agp
glisse: writeback on agp is unreliable
glisse: though for what you are doing gpu read, cpu write it should be ok
mjg59: Yeah
mjg59: Ok, I'll see how it goes
mjg59: Why must hardware hurt so?
glisse: sotry of my life
mjg59: glisse: Ok, got it
mjg59: glisse: Thanks!
ajax: is radeon not using msi yet?
glisse: ajax: it should but it's desactivated on some gpu
glisse: like igp
glisse: due to bug in bios
ajax: i really don't want to know how that can be a bios bug.
mjg59: There's some MSI setup that has to be done on the chip first
glisse: no you don't want ...
mjg59: That's behind a write-once lock
glisse: some bios writer can't read doc
ajax: write-lockable registers: all the way retarded.
evil_core: theres nearly no changes in drm-radeon-testing?
mjg59: Arse.
mjg59: Now, why has my in theory entirely identical implementation resulted in nothing working?
glisse: mjg59: it doesn't block ?
glisse: mjg59: btw i thought a little to your issue and i think the following change might be helpfull :
mjg59: glisse: No, it stays blocking :)
glisse: we should buffer the cp wptr and update it only when the ring is getting nearly empty that way anytime we want to stop processing we stop updating wptr
mjg59: glisse: Hm
glisse: such change would alow for the cp to quickly drain
mjg59: Yeah
glisse: so you wouldn't have to timeout for too long
glisse: also it should cope nicely with glxgears or similar app
mjg59: That might work
glisse: and it shouldn't slow down anything
glisse: tricky part is to monitor ring size
glisse: i need to go through the ring stuff again but i think we might use interrupt
mjg59: #define radeon_cp_unlock(rdev, a) (rdev)->asic->cp_lock((rdev), (a))
mjg59: Spot the deliberate error
mjg59: Yeah, that works better
ajax: lulz
agd5f: mcgregor: driver stores clocks in 10 khz units
agd5f: mjg59: right. we don't use semphores yet
mcgregor: agd5f, ahh thx , would have never guess that :)
pechowiec: hi
adamk: Yo.
yoshi314: s'up
pechowiec: i have "01:00.0 VGA compatible cont roller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)" and i use gentoo. I have already installed "x11-drivers/xf86-video-ati" from portage. what i have to do to tun this card correctly
pechowiec: i thing it is is better. but now it have dificulties with programs like xcompmgr
yoshi314: well i guess it should be good enough, mesa should be installed by default
adamk: pechowiec, What difficulties are you having?
adamk: pechowiec, And can you pastebin your /var/log/Xorg.0.log file?
yoshi314: check VIDEO_CARDS variable for mesa
yoshi314: whether you put radeon in there or not
pechowiec: adamk: when I run xcompmgr ant try move windows then avarage usage of cpu is 100%
adamk: has never had a good experience with xcompmgr.
pechowiec: yoshi314: I have compiled mesa with VIDEO_CARDS="radeon"
adamk: But we can at least tell you if your drivers are installed properly if you pastebin that log file.
pechowiec: adamk: it is something like compiz but more lightweight
adamk: And we might as well check the output of 'glxinfo' while we're at it.
adamk: Oh, I know what it is.
pechowiec: http://wklej.org/hash/9d9939b800/
adamk: I've used it. Just never had a good experience with it :-)
pechowiec: :))
adamk: Hmmm... EXA might give you better performance with 2D compositing, but I've never tried EXA on an r200 GPU.
adamk: Instead of AccelMethod XAA, try EXA.
pechowiec: i will try
pechowiec: adamk_: ok i have change this value and restart xorg. paste new log?
adamk_: Sure.
Wizzup: /win 25
Wizzup: :(
KotH: Wizzup: /fail 25 ;-)
pechowiec: http://wklej.org/hash/a5d3f3d259/
pechowiec: card is radeon 9200se but i copy this xorg.conf from my firend, which is using 9700pro
adamk_: OK, well you are now using EXA which is typically faster for compositing.
adamk_: Having said that, I have no real experience with it on your particular GPU family.
adamk_: So see if it performs any better.
pechowiec: I think it is a little faster
adamk_: I'm not sure what kind of performance you can expect from that GPU in general, mind you.
leio: has 9200 pro
adamk_: leio, And do you get significant CPU usage when moving windows with 2D compositing enabled?
leio: I don't use 2D compositing on it, and I have an old xorg-server there (newish driver though). I'll enable compositing and check, one sec
leio: some 25% CPU when frantically moving some non-maximized window on top of a maximized one
pechowiec: s nick means omebody, who haven't got lucky'
pechowiec: **somebody
leio: pechowiec: I'd suggest trying DownloadFromScreen accel
pechowiec: leio: can you paste me your xorg.conf?
leio: pechowiec: no, it has way too much stuff :)
leio: Option "AccelDFS" "on"
leio: Try adding that to your radeon Device section
pechowiec: leio: so, maybe only graphic card section ? :>
leio: if you get any rendering corruptions you didn't before, then that might start causing it. Hasn't been a problem for me yet
leio: the section you have Driver "radeon" or "ati" in, yeah
pechowiec: it is faster :)
pechowiec: log http://wklej.org/hash/0e3bc4ead3/ and my xorg.conf http://wklej.org/hash/39771ae051/
pechowiec: what else should I change?
adamk_: That was the only thing that jumped out at me.
leio: sort of weird options there. Like backingstore. Why would you want that with compositing
leio: lotsa buffering and copying is good? :)
pechowiec: leio: I was desperated... :)
pechowiec: i use too much copy& paste
adamk_: Yeah, you can probably eliminate most/all of those options.
adamk_: The driver uses sane default settings.
leio: well, doesn't enable AccelDFS by default
adamk_: For example, EXA would have been used by default had you not specified XAA I believe.
evil_core: is it normal that xorg is now built w/o hal support?
adamk_: evil_core: As of 1.8.* yes. hal was dropped.
evil_core: so wtf we got now?
evil_core: xorg.conf back?
leio: udev
evil_core: I got so many nice hal rules for touchpad/trackpoint, etc
chithead: xorg.conf.d and udev
chithead: hal fdi can be migrated to udev rules
evil_core: ctrl_alt_backspace doesnt work, with hdaps loaded xorg is unusable
evil_core: and probably with anything else acting as /dev/input/js0
evil_core: so should I make rpm -e hal?
evil_core: or maybe better no, because I got thinkpad buttons mapped trough hal, and laptop-mode-tools depends ond that also
mcgregor: so now after hal support has been removefrom xorg, auto detection for mouse/keyboard/touch pad still exists, just through udev now?
evil_core: I even cannot use webbrowser w/o trackpoint rules now ;)
evil_core: chithead: can you give some links to useful docs, migration script and premade rules?
chithead: I think no comprehensive documentation exists at this point, only blog posts and under-construction wiki pages
yoshi314: mcgregor: i'm still wondering how to rewrite the wacom tablet rules
yoshi314: to new format
yoshi314: but other than that i'm still wondering about that whole new configuration
pechowiec: oh thx for help
yoshi314: i'm not sure whether it will offer the same level of flexibility as hal did
mjg59: Bother. This ought to be equivalent to what I had last night, but instead I'm still seeing occasional hangs.
mjg59: No visual artifacts now, though
evil_core: chithead: I will be happy from anything
mcgregor: yoshi314, well, I havent upgraded to xserver 1.8.x yet and I wont do that soon. at least not as long as I will see other people report it works as good as before
yoshi314: me too, until i figure how to rewrite wacom rules
yoshi314: i've just taken the ready ones from the net
yoshi314: they work on gentoo, but lock up X on arch linux ;)
yoshi314: only when the tablet is plugged
chithead: evil_core: http://dev.gentoo.org/~scarabeus/xorg-server-1.8-upgrade-guide.xml was written by scarabeus and covers the most important aspects
mcgregor: the fact is, with hal support xorg works really good - for me at least. I didnt have to take care about anything, it just worked
yoshi314: i wonder how do i specify two keyboard class devices that are supposed to have different keyboard layouts now
yoshi314: that was really easy with hal
yoshi314: and dynamic, too
evil_core: chithead: thx, it should be enough
yoshi314:
evil_core: are there automatic translators?
evil_core: I got long rules for touchpad/trackpooint :/
evil_core: and I got manyyy rules
evil_core: its not even similaro to hal rules
mcgregor: evil_core, maybe you should downgrade xorg and wait until that problem gets managed somehow. you surely won't bethe only one who's having such a problem
evil_core: no, new xorg works better with d-r-t and mesa master
evil_core: and I believe its less buggy
lukey: Hi there, Using git(2010/04/04) of libdrm, libdrm-radeon1 and git(2010/03/24) of xserver-xorg-video-radeon and git(2010/03/27) of mesa. Kernel 2.6.34-rc3 x86_64. OpenGL renderer string: Mesa DRI R600 (RV620 95C4) 20090101 TCL DRI2. Are there known issues with fullscreen GL apps causing X server crash and hard lock?
lukey: I also use two monitors in case it is important.
Mjules: hi
Mjules: I've got a problem building latest ati DDX
Mjules: http://pastebin.com/redDaAJw
Mjules: how can I troubleshoot the issue ?
yoshi314: Mjules: is that from a tarball or from git?
Mjules: tarball
Mjules: the released tarball
yoshi314: hmm what system is that on?
Mjules: 6.13
Mjules: mandriva 2010.0
Mjules: with some package updated
Mjules: (libdrm 2.19, mesa 7.8 and dependencies of the last)
yoshi314: i'd say X headers might be a bit behind
Mjules: xserver 1.6.5
AstralStorm: hello there
AstralStorm: I'm hitting an assertion in mesa:
AstralStorm: graphika: shader/slang/slang_emit.c:350: storage_to_src_reg: Assertion `index >= 0' failed.
Mjules: yoshi314: I need to find which one
AstralStorm: what can be the cause (except faulty shader program - which it shouldn't be)
yoshi314: Mjules: well, i'd check where does #
yoshi314: /usr/include/X11/extensions/dpms.h
yoshi314: come from
Mjules: yoshi314: this one is already at latest version :/
Mjules: yoshi314: but other components are not
yoshi314: btw how come you have /usr/include/xorg and /usr/include/X11 ?
yoshi314: is that normal in mandriva?
Mjules: I 'thin k so
Mjules: will check
yoshi314: ok, i guess it is
yoshi314: there are libX11 headers in there
Mjules: yeah it seems to be normal
yoshi314: i'd try listing all xorg-related components to check whether something doesn't fall behind
Mjules: yoshi314: you are right, it seems to come from my partly updated install
Mjules: thanks
AstralStorm: hmm
AstralStorm: I managed to corrupt the card somehow
AstralStorm: oh right, forgot to write anything to gl_FrontColor ;p
mjg59: glisse: Ha wow
mjg59: glisse: Under this load, it can take *2* *seconds* for a fence to fire
glisse: mjg59: what is the load ?
mjg59: glisse: x11perf and glxgears
glisse: does it trigger the lockup code ?
mjg59: Nope
mjg59: x11perf seems to be an especialy harsh test
glisse: it gives a pretty good idea that the bottleneck is not the cpu
AstralStorm: so, why does my GLSL 1.1 code fail?
mjg59: Right
AstralStorm: esp. with an assertion failure?
mjg59: glisse: I guess cards aren't optimised for drawing millions of 1x1 rectangles :)
AstralStorm: graphika: shader/slang/slang_emit.c:350: storage_to_src_reg: Assertion `index >= 0' failed. - HELP!
AstralStorm: r600
AstralStorm: a really trivial lambertian diffuse in a vertex shader
glisse: mjg59: well there is a trick for that on r6xx but we don't use it and even if we did i don't think it will solve the issue
mjg59: glisse: Yeah, I'm pretty unconcerned
glisse: i think the root issue here is to have so many 1x1 rectangle in the first place, of course this is a bench but i think even for usual app it's not uncommon
mjg59: glisse: I think this is pretty unrepresentative
mjg59: But it's a good test of stability
AstralStorm: so, maybe I could get some help from you? (a more basic shader works)
AstralStorm: http://wklej.org/id/311094/ - such a shader fails
AstralStorm: main is void main() { lambert_diffuse(); }
AstralStorm: uh, lambert_shader()
AstralStorm: so? again, r600
glisse: AstralStorm: buest is to do a small glut prog and open a bug
glisse: maybe first try if any of the glsl example in mesa trigger the issue
AstralStorm: eh... except I don't do GLUT
AstralStorm: none I could see
AstralStorm: funny though, can't do anything really more basic than this
glisse: shader compiler is hard to do
glisse: right now what's in r600 classic is more a translator than a compiler
glisse: thus it can easily fails
AstralStorm: glisse: seems the shader fails when assigning vec4 to vec3
AstralStorm: directly
AstralStorm: I've missed that case, see normal = normalize(...)
AstralStorm: gl_Normal is vec4 I think
AstralStorm: or something else around is
AstralStorm: found it
AstralStorm: glisse: radeon hates gl_NormalScale
AstralStorm: there must be a bug in handling of that
AstralStorm: or in handling of multiplication by a scalar
AstralStorm: should I file a bug on this?
AstralStorm: (and what to write in it...)
agd5f: AstralStorm: sure
agd5f: include xorg log and dmesg and a sample app that exposes the bug if possible
AstralStorm: nothing special in the log, only a dump
AstralStorm: the sample app is... a bit long
agd5f: plus whatever error message you are getting from mesa
AstralStorm: it should fail in any default teapot displayer ;p
mjg59: I now seem to be at fast and roughly correct, but not stable
mjg59: Vexing
krisfremen: sneezes
krisfremen: ohh snap, wrong channel
mjg59: ARGH.
mjg59: Now it won't crash.
mjg59: I hate hardware.
DanaG: http://netbooked.net/blog/lenovo-ideapad-x100e-dual-core-options-now-available/
DanaG: ooh
mjg59: agd5f: Huh. This is kind of weird.
mjg59: If I drop the WAIT_REG_MEM (on the assumption that I hold the cp lock before the fence, the fence has fired and so there should be nothing left in the ring), I still get some failures to wait for GUI idle
mjg59: I guess I should figure out what's allegedly alive
mjg59: Oh, wait, no - that one makes sense
mjg59: This looks vaguely plausible now
mjg59: Let's see if it stays up
AstralStorm: hello again
AstralStorm: Mesa/r600 GLSL is not even 1.1 compliant
AstralStorm: "Diagnostic messages returned from compiling a shader must identify both the line number within a string
AstralStorm: and which source string the message applies to."
AstralStorm: except they don't here
AstralStorm: there are messages in infologs, but no line numbers
DanaG: Ah, is that why I always had so much trouble identifying problems?
DanaG: =รพ
DanaG: No wonder.
MostAwesomeDude: AstralStorm: Patches welcome.
AstralStorm: MostAwesomeDude: well, if I mention it, it means I get to write some more shaders, duh
mjg59: glisse: So, the thing I'm crashing on seems to reliably be 500x500 tiled rectangle
mjg59: airlied: ^
mjg59: A minute or so of that with glxgears bouncing up and down seems to be enough to trigger a crash
airlied: mjg59: okay without pm?
mjg59: airlied: Yeah
mjg59: Any idae whether that's likely to be accelerated or hitting fallbacks?
mjg59: airlied: http://www.codon.org.uk/~mjg59/tmp/radeon_reclock_pm.diff is what I'm doing to try to stop sw fallbacks from touching vram
mjg59: radeon_unmap_vram_bos
airlied: hmm tiled might cause sw fallback, you'd have to build the ddx with the fallback debug on
airlied: none of the vram/vga/shader obj have a virtual anyay
mjg59: It seems to be the 500x500 one pretty reliably
airlied: mjg59: does it take out the machine? or just lockup the gpu?
mjg59: airlied: Machine
airlied: no chance you are ending up outside the vbl again
mjg59: Oh, absolute chance
mjg59: But I'm disabling crtc scanout while I do that
mjg59: Which I'd have thought would mean visual badness rather than machine hang
mjg59: But yeah, I'm missing vblank occasionally
mjg59: I should probably strengthen that check
airlied: wierd though it seems like should be fine, I'll look at bit more when I hit the office
airlied: does putting a small settling delay before letting faults run help?
mjg59: airlied: Hm.
mjg59: airlied: That's an idea.
airlied: oh bo destruction might cause the gart table in VRAM to get hit
mjg59: http://www.codon.org.uk/~mjg59/tmp/reclock_test.sh - that's what I'm running
airlied: also bo creation of course
airlied: &
mjg59: airlied:
mjg59: Oops
mjg59: airlied: It doesn't trigger upclocking, so I'm going to go with it being unaccelerated
mjg59: airlied: Ok, a 1msec settle after reclocking doesn't help
airlied: mjg59: try seeing if you get inside the pcie gart bind/unbind functions
airlied: as they have to read/write vram from the kernel to update the GART table
mjg59: airlied: Will do first thing
evil_core: airlied: KMS with xorg 1.8 with d-r-t and master mesa sucks same as with previous xorg
evil_core: and more than gallium
evil_core: maybe not sow low fps-conditions, but it looks smooth frame flow
evil_core: it looks like they are rendered for half of time, later lag, frams waterfall,lag, etc
evil_core: not sure, but probably you told me that new xorg will help with that and tearing
evil_core: tearing stopped, but this thing makes KMS unusable IMHO
evil_core: anyway, what kernel branch should I use? I dont see too much changes in d-r-t lately
airlied: evil_core: what app are you using?
evil_core: quake3
evil_core: I like quake, because in case of swfallback or black screen, I write ~ and quit ;)
evil_core: not sure if its quake related
airlied: forgets is q3 does stupid things with dri2
evil_core: so its q3 problem?
evil_core: it runs nice in UMS
evil_core: but tc-elite is unplayable on most maps :/
evil_core: anyway there were nice progress with wine compatibility in last 2 weeks
evil_core: especially with Dethkarz/Ignition, which are the only games I really sometimes play
evil_core: can I bring back vga console, after unbinding, and reloading radeon module in UMS?
evil_core: then I would test KMS without reboots then
mjg59: If vbetool post works, yes
evil_core: mjg59: I need full command, its not easy to play with it blind ;)
evil_core: vbetool vgamode?
mjg59: No
mjg59: vbetool post
mjg59: After unbinding
RiotingPacifist: I've compiled my own kernel, what needs to be enabled to get me ttys working on an evergreen chipset?
RiotingPacifist: ignore that found the relevant secion in the build howto, will ook for fbcon and radeondrmfb
DanaG: hmm, I still have the weirdness of having two battery states.
evil_core: thanx, got script working
amarsh04: still have the X server dying when drawing an ellipse in gnu paint: xserver-xorg-video-radeon 1:6.12.192-2, libdrm-radeon1 2.4.18-3 and mesa 7.7.1-1
adamk: amarsh04, Have you grabbed a backtrace from the X crash?
amarsh04: not sure how to set it up, adamk
amarsh04: debian unstable here
adamk: login remotely via ssh, run Xorg via gdb. login remotely again, set DISPLAY=:0, start up a window manager on the X server, and then start gnu paint.
amarsh04: I'll have to look at that when I'm more awake - been up too long, and haven't ever used X forwarding
evil_core: ouch, I forgot
RiotingPacifist: if the xorg crash isn't preventing him from ctrl+alt+f1ing to a tty can he do that locally?
adamk: amarsh04, You won't actually be using ssh forwarding.
evil_core: I got xorg crash in KMS with ignition and glide wrapper
evil_core: and in dmesg
evil_core: and xorg is corrupted adter restsarting and dri doesnt work
adamk: RiotingPacifist, Not always, no. X doesn't completely exit when it crashes in gdb, but isn't in a usable state. Switching back to the tty may not work.
RiotingPacifist: amarsh04: you don't need xforwarding xorg will run localling on the pc your sshd is running, you just have to ssh in so you can get backtraces
evil_core: and reloading radeon made screen totally black
evil_core: [http://pld.pastebin.com/LdgwmReW
amarsh04: that's good adamk, so I just need to log in remotely as a terminal session?
adamk: Yep. setting DISPLAY=:0 will get gnu paint to run on the X server you started via gdb.
amarsh04: ok, will give it a try later
evil_core: mtpaint rulez!
amarsh04: I've observed the same problem on i386 and amd64
evil_core: and this error is [robably from gallium or something
evil_core: forgotten now ;)
RiotingPacifist: how do i make sure "fbcon" is compiled into the kernel, "evice Drivers->Graphics Support->Support for framebuffer devices->Framebuffer Console Support" is not selectable its "---" but it says "Symbol: FB [=y] ", i've got that and radeon_kms enabled (but not radeonrmfb any more), yet i still get blank ttys
RiotingPacifist: ok i think i've found the problem, i'm not compiling radeondrmfb i was compiling the old radeon_fb, i can't find radeondrmfb in 2.6.33 though
airlied: RiotingPacifist: its not a seaprate option
airlied: its part of the kms driver
airlied: the wiki page has all the info you need
RiotingPacifist: http://wiki.x.org/wiki/radeonBuildHowTo ?
FIReun: build your own radeon!
airlied: RiotingPacifist: yes it gives the preferred config options
RiotingPacifist: i have those config options, yet i don't get any text on the ttys, should there be a config option underneath DRM_RADEON to enable the fb?
airlied: no
airlied: you definitely have CONFIG_FRAMEBUFFER_CONSOLE?
airlied: and CONFIG_RADEONFB off
RiotingPacifist: CONFIG_FRAMEBUFFER_CONSOLE=y // CONFIG_DRM_RADEON=y // CONFIG_DRM_RADEON_KMS=y // # CONFIG_FB_RADEON is not set
airlied: okay then you might have a bug, does X start?
RiotingPacifist: X starts and runs fine (no acceleration, as im on r800)
airlied: RiotingPacifist: okay so can you pastebin the dmesg?
bisby: is there a package and/or source that has working functions for cypress out there?
BioTube: bisby: are you talking about an evergreen card?
BioTube: if so, the latest kernel has modesetting support, but nothing more's been release yet
bisby: i got a 5870
BioTube: there's no accelleration available for 5xxx cards yet
bisby: Is there any way of getting anything to work? The only thing that works is the recovery mode shell
BioTube: you might need a newer ddx
soreau: on rv350, classic mesa, compiz-0.9, gentoo, x86, 32bit; shift switcher plugin hard locks the machine after a few seconds of use
soreau: 2.6.34-rc2 and latest user space
soreau: also tested on Arch 2.6.33. didn't hard lock but was extremely slow (IIRC)