mcgreg: good morning
mcgreg: is ashonished ..
mcgreg: you finally made Warcraft3 work with wine :) torally correct, no gfx glitches/bugs and wth decent speedd - full gfx quality on 1280x1024
mcgreg: hmm? me?
spreeuw: sry read WoW
mcgreg: ohh .. so I am a wow-addict if I play wow?
spreeuw: you just dont know it yet
gimzo: mcgreg: what gpu is that on ?
mcgreg: rv730xt (radeon 4670)
gimzo: so that means r700 is ready for end users ?
EruditeHermit: gimzo, not really
spreeuw: try this out http://springrts.com/
EruditeHermit: gimzo, its still in the staging area of the kernel
EruditeHermit: its usable now probably
EruditeHermit: but there may be bugs
taiu: good :)
mcgreg: wow is still totally broken
taiu: there was some page in wiki about working state, matbe should start updating things in it
gimzo: why doest that wiki page say texturedVideo is "faster" than overlay? is there a reason for me (x700, no dri2, no compositing) to use texturedVideo over overlay?
EruditeHermit: in that case, it doesn't matter much
EruditeHermit: textured video benefits are mostly for dri2 and compositing
EruditeHermit: overlay may be slightly faster
gimzo: ok, thanks
EruditeHermit: but not really in practice
gimzo: I'm just happy that finally both work without tearing :)
EruditeHermit: the speed difference is negligible
gimzo: another question, how come that there is no tearing when I watch 25fps video on 60 hz monitor refresh? in opengl (xvmc) there is tearing and if vsync is on then framerate is 20fps ?
EruditeHermit: you'll have to ask a dev that
mcgreg: from what I have only warcraft3 is wokring - which is opengl anyway
gimzo: I guess opengl apps shouldn't have graphics problems with wine
mcgreg: well - wow does. mupenplus is very fine (linux native) too :) funny too see it working so nicely
mcgreg: just about everything is broken with wow. the whole screen structure, text...
mcgreg: but I guess, it's not really an easy game... so I dont expect anything anyway
mcgreg: the overall progress is simply totally unbelievable cool :)
mcgreg: hmm wth is xorg using 2GB ram here ... meh
stikonas: is occlusion_query the only missing extension for OpenGL 1.5 on r600 driver?
airlied: possibly, not sure
rah: seeing as crtc indicies were mentioned, I feel the need to point to this:
rah: which is relevant but possibly a more general problem
nanonyme: Assuming it has hardware VBO's, maybe...
nanonyme: gimzo: You're assuming there people are incapable of writing bad OpenGL code.
nanonyme: It's not that good a language. ;)
mcgreg: I wonder when the fiurst .32-rc will appear
rah: whatever was committed to drm-next since about 11pm last night has killed KMS
rah: I just get a black screen
rah: since adea4796cfb9b74d340f9e32ba523fb61305d0b7
EruditeHermit: airlied, have you switched to working on gallium now?
gimzo: nanonyme: where am I assuming that ?
nanonyme: 11:01 < gimzo> I guess opengl apps shouldn't have graphics problems with wine
gimzo: oh, I meant to say I guess wine just forwards opengl to mesa, it doesn't do anything with it like it does with d3d :)
nanonyme: Rightcha. ^^
nanonyme: I just reminded that just as Linux OpenGL programs can be written so that they don't work properly on all drivers, same can be done for Windows programs.
nanonyme: And if this happens with closed source programs, the only thing mostly you can do is cry. ;)
nanonyme: It's not like eg Blizzard would change their OpenGL backend just because opensource camp tells them that it's not standards-compliant.
nanonyme: So either we accept all OpenGL programs aren't gonna work or we write per-program standards-incompatible hacks. ;)
nanonyme: (I think all official drivers choose the latter approach)
nanonyme: s/we/they\/whoever is developing the driver/
dileX: ring ring
dileX: I wanted to test gallium3d today
dileX: playtime :-)
dileX: I found diverse advices for building, pls see (#radeon backlog) at
dileX: ./autogen.sh --prefix=$PREFIX --with-dri-drivers="r200,r300,r600,swrast" --enable-gallium-radeon --disable-gallium-intel --enable-debug --with-state-trackers="dri,g3dvl,xorg,glx"
dileX: (will have all of them)
MrCooper: dileX: FYI r300g doesn't support the Xorg (and I think g3dvl) state tracker yet
dileX: MrCooper: thanks for info
MrCooper: doesn't hurt to build them, but there won't be any additional usable binaries
MrCooper: also you may want to wait for airlied's ongoing flurry of r300g fixes to settle down :)
dileX: MrCooper: I will try - I am in experience mood
dileX: OK, I see three r300g patches from dave im mesa master
dileX: MostAwesomeDude: what about a gallium build-wiki?
nanonyme: wonders if MAD is still busy with shatter
dileX: MrCooper: thanks for giving me the day off (will enjoy sunshine in cafe, try later with new commits) :-)
nanonyme: dileX: If you just want to test Gallium, might want to save time by installing under a prefix to avoid breaking your Mesa installation (as in, avoid core changes causing incompatibility) and compile --with-drivers-dri=""
nanonyme: Erm, with-dri-drivers?
gimzo: according to gallium wiki page, I can use softpipe backend and run quake wars or something (if I don't mind slideshow framerate) ?
nanonyme: Probably, I guess.
gimzo: I think I'm going to try that :)
gimzo: as soon as I find howto on installing gallium :)
gimzo: is there any ?
nanonyme: You probably realize it's mostly like running software rasterizer, right?
gimzo: I like to play with stuff :)
airlied: stops r300g fixin, though gears still locked up my box but I tihnk it did that before i did anything
laska: hello i've got the following kernel messages with kms enabled in linux-2.6.31-git16
laska: [ 68.976785] ------------[ cut here ]------------
laska: [ 68.979815] WARNING: at drivers/gpu/drm/drm_crtc_helper.c:953 drm_helper_initial_config+0x31/0x4a [drm_kms_helper]()
laska: [ 68.983080] Hardware name: System Product Name
laska: [ 68.986417] Connected connector with 0 modes
laska: [ 68.989804] Modules linked in: radeon(+) xt_mac xt_tcpudp ipt_ULOG xt_owner ipt_LOG xt_limit xt_state iptable_filter nf_nat_ftp nf_conntrack_irc nf_conntrack_ftp iptable_nat nf_nat ip_tables x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 nls_utf8 nls_cp866 vfat fat ttm drm_kms_helper drm i2c_algo_bit fuse sbp2 loop dm_crypt dm_mod snd_hda_codec_atihdmi snd_hda_codec_realtek snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_hda_int
laska: el snd_emu10k1 usblp snd_ac97_codec ac97_bus snd_util_mem snd_hda_codec snd_seq_midi snd_rawmidi snd_hwdep snd_pcm_oss snd_seq_midi_event snd_mixer_oss snd_seq snd_pcm amd64_edac_mod snd_seq_device snd_timer i2c_piix4 k8temp edac_core shpchp pcspkr evdev i2c_core emu10k1_gp pci_hotplug gameport asus_atk0110 snd processor snd_page_alloc soundcore wmi reiserfs raid10 raid456 async_raid6_recov async_pq async_xor xor async_memcpy async_tx raid6_pq raid1 raid0 multip
laska: ath linear md_mod ide_cd_mod cdrom sd_mod crc_t10dif usbhid ata_generic hid ide_pci_generic usb_storage firewire_ohci firewire_core crc_itu_t ahci ohci_hcd libata ohci1394 ieee1394 e100 mii sky2 atiixp ehci_hcd ide_core floppy scsi_mod thermal fan thermal_sys [last unloaded: radeon]
laska: [ 69.027085] Pid: 3457, comm: modprobe Not tainted 2.6.31-git16 #3
laska: [ 69.032435] Call Trace:
laska: [ 69.037813] [
laska: [ 69.043419] [
adamk_: laska: Seriously, that's what http://pastebin.com/ is for.
laska: [ 69.049009] [
laska: [ 69.054670] [
laska: [ 69.060368] [
laska: [ 69.066231] [
laska: oh, sorry
nanonyme: adamk_: (keyword dropping + pastebin)++
nanonyme: Makes the problem findable with Google. :)
MrCooper: airlied: yeah r300g gears locking up is a semi-recent regression, I think nha tried to bisect but probably stumbled over the stable branch merges
MrCooper: gimzo: who knows, llvmpipe on a beefy CPU might be usable at 320x240 or so ;)
nanonyme: Some people seem to be getting ideas of softpipe and Larrabee. *shrug*
laska: airlied: i have the following problem with radeon kms enabled in linux-2.6.31-git16 http://pastebin.com/m67b0c621
MostAwesomeDude: MrCooper: I'd guess the elts changes might be responsible, not sure.
MrCooper: elts changes?
gimzo: MrCooper: does athlon 3700+ qualify ? :D
MrCooper: gimzo: you're in the best position to find out
MostAwesomeDude: MrCooper: cooper changed the elt setup and emit in r300_render.
MostAwesomeDude: That'd be my guess. Dunno though; haven't touched it in a bit.
MrCooper: I think that fixed gears :) it's broken since
MrCooper: I mean after that
gimzo: What with larrabee? Will it be multicore x86 as was once said ?
suokko: gimzo: yes. Instruction set is published already sometime ago. It will be somewhat different in how core works to what CPUs now are doing.
nanonyme: wonders if Larrabee can do blitting
suokko: wonders if cpu can do blitting
kdekorte: airlied are you still around?
nanonyme: suokko: Well, if Larrabee couldn't do that, I doubt it would be that useful for fast graphics.
edt: laska I I were you I would try pull airlied's drm-next branch on top of that kernel. Here 31-1+drm-next has been stable on r600 with kms for 12 hours (which is a first) using kwin instead of xrender (kde 4.2)
kdekorte: edt, that is good news
edt: it susprised me too. I have a 790gx base board rs780. There a lot of churn, I expect it will break a few more times as more stuff is added/fixed
nanonyme: Wonder at what point you start bumping into bad enough memory fragmentation that it starts to show in normal desktop usage... Never? :)
edt: laska or use .31-1 and follow the instruction in the link in the topic
kdekorte: I just got the latest rawhide kernel from koji, not sure how many of the r6xx patches are in there
kdekorte: but solving the lockups would be a huge thing
edt: nononyme I have 8G here. Its going to be a while fragmentation causes problems...
edt: kdekorte I used the the suggested builds in the topics ati link
kdekorte: I've been thinking about upgrading from 4GB to 8GB but haven't been able to justify it yet
edt: From experiences at work I decided that >4G was going to be ECC memory here
edt: here tuxkarts works but is jerky. googleearth, etracer (gets 30fps), glxgears, kwin are all ok. The jerkiness in tuxkarts is new.
edt: git trees are from about 21-21:30 EDT yesterday (just after airlied signed off)
rah: edt: I get a blank screen with an rv770
suokko: nanonyme: Fragmentation does show with crashing GL in my system because of cs parser problems
nanonyme: suokko: Yeah, maybe I wasn't clear in what I said: I didn't include 3D in normal desktop usage, it rather goes into poweruser and entertainment in my categories. ;)
suokko: Unless compiz crashes
nanonyme: Compiz is not normal desktop usage? :o
AndrewR: latest X server doesn't start for me on rv280, in KMS mode. It works in non-KMS case .... http://pastebin.com/m726a5897 (simple backtrace from x log)
suokko: AndrewR: Can you get a better backtrace with gdb and report a but? (maybe against exa judging from that backtrace)
AndrewR: suokko, yes, one moment ...
spreeuw: kdekorte_: mplayer -xv has the same issue?
spreeuw: -vo xv sry
AndrewR: suokko, bug 24167
kdekorte_: spreeuw, what was the question?
dileX: any idea whats going wrong with gallium-radeon? Xorg.log
nanonyme: suokko: Hmm, although... EXA/Xv should suffer of the same memory fragmentation issue in KMS, right?
BeerSerc: Hi. I still cannot get the radeon driver working at all when kms is enabled. I upgraded xorg server and all dependencies to live versions now, but still when trying to start X with radeon, I get a standing cursor and nothing more. system is still alive, I just cannot see anything. xorg.0.log: http://nopaste.info/9f7bae4f6a.html
BeerSerc: still not more in the logs than before, no errors or anything
nanonyme: How new is the kernel?
fallenwizard: BeerSerc: Is HAL running correctly?
BeerSerc: nanonyme: 2.6.31
edt: BerrSerc did you follow the instruction in the topic completely? I also had problems until I went over it with a fine tooth comb
BeerSerc: fallenwizard: I think so, everything else including kde4 is working
edt: BerrSerc did you pull drm-next on top of .31 ?
BeerSerc: edt: yes
fallenwizard: BeerSerc: kk
BeerSerc: only thing which is not from the repos ydt is dri2proto, that was 2.1
BeerSerc: I am compiling it
dileX: BeerSerc: and afterwards xorg-server :-)
BeerSerc: yes, compiling ... ;)
edt: Here I use the latest git X 1.6 stuff - you lock to be using the 1.7 pre stuff. Might be the problem
BeerSerc: edt: I tried different versions before
BeerSerc: exactly the same result
edt: I have a rv780 (r600) you?
BeerSerc: mobility x1400
dileX: edt: server-1.7-branch works fine)
BeerSerc: dileX: except for theres no synaptics compiling against 1.7 ...
edt: the 1.7 stuff did not work for me... (It might for you - I tried a few days back)
BeerSerc: which annoys me a bit ...
BeerSerc: but a working radeon driver would be worth waiting for synaptics
edt: is kms working when you boot or are you loading modules?
dileX: BeerSerc: just as a hint videoabi and inpuabi has changed - compile all xorg input and video driver against new xorg-server
BeerSerc: now I have it in the cernel
BeerSerc: dileX: I have. but no synaptics version compiles
edt: if the later try putting all the stuff kms needs into the kernel - doing so helped here.
BeerSerc: not even from git
dileX: BeerSerc: are you sure?
BeerSerc: dileX: aye
dileX: $ dpkg -l | grep synaptics
dileX: ii xserver-xorg-input-synaptics 220.127.116.11+git20090912.2b27e79-1~dileX+1 Synaptics TouchPad driver for X.Org server
dileX: BeerSerc: this one works
dileX: xorg-server 1.7+
BeerSerc: I tried again, I cannot compile latest git here
BeerSerc: X11/extensions/record.h is not found while compiling
dileX: BeerSerc: did you have a looked into confgure.ac of xorg/xserver to have all required pkg-versions?
BeerSerc: what do you mean by pkg-versions?
dileX: REQUIRED_MODULES="[randrproto >= 18.104.22.168] [renderproto >= 0.11] [fixesproto >= 4.1] [damageproto >= 1.1] [xcmiscproto >= 1.2.0] [xextproto >= 22.214.171.124] [xproto >= 7.0.13] [xtrans >= 1.2.2] [bigreqsproto >= 1.1.0] fontsproto [inputproto >= 126.96.36.1992] [kbproto >= 1.0.3]"
dileX: REQUIRED_LIBS="xfont xau [pixman-1 >= 0.15.20]"
nanonyme: Probably part of xproto.
BeerSerc: as I am using a gentoo overlay, this all _should_ be taken care of, but I'll check
nanonyme: Assuming they know what they're doing...
nanonyme: I've lost quite a bit of my belief in distro devs' capability to know what they're doing unless they're also working upstream with the code during the past decade or so. :3
suokko: IF that logrealy ends after setup tectured video then it looks like some hang in ddx init path
BeerSerc: suokko: it does!
suokko: So it is hang between initial video setup and reading the display modes from kernel
dileX: suokko: any experience with gallium-radeon?
suokko: BeerSerc: Can you login wit hssh and get a backtrace from Xserver with gdb?
suokko: with ssh*
suokko: dileX: no
dileX: suokko: OK, thx.
BeerSerc: suokko: right now no, as my desktop is broken, but on monday I'll have a new machine --> then I can do that. but I havent used gdb before, how would I backtrace that?
suokko: BeerSerc: First you have to install debug symbols for xserver and xf86-video-ati (That means in gentoo compiling FEATURE=dsplitdebug or something like that)
suokko: Then next step is to start the X normaly and login with ssh. In ssh connection you have to find pid of running X. Then start gdb with command "gdb Xorg"
suokko: Then in gdb prompt you need to attach with command "attach
suokko: Next you can get backtrace with "bt full"
BeerSerc: suokko: I'll try as soon as I have the time
agd5f: BeerSerc: if you are trying kms, check dmesg too
BeerSerc: agd5f: nothing there except kms initialized somewher in the early lines ...
dileX: now, I have an error-n
dileX: now, I have an error-message
dileX: (switched to upstream xorg-server)
thematt: OpenGL 2.1 with RV535 [Radeon X1650 Series], it's really?
nanonyme: With what?
nanonyme: Software rendering?
thematt: hm.. with DRI
nanonyme: With software rendering?
nanonyme: The extra information value of your comment was zero, pretty much.
thematt: libdrm+mesa+xf86-video-ati == 1.5 Mesa 7.7-devel, but in http://www.x.org/wiki/RadeonFeature says that R500 support OpenGL 2.1
thematt: with direct rendering
nanonyme: I think that just means what the hardware supports.
thematt: libdrm+mesa+xf86-video-ati from git, of course
suokko: thematt: (Driver/Hardware) 1.5/2.1
nanonyme: Oh, so it nowadays has the supported too.
nanonyme: That is, by drivers.
nanonyme: I'd interpret that as hardware support 2.1, driver support 1.5.
nanonyme: (which is actually tons more sensible a version format than the one that page used to have)
nanonyme: As in, means that you will *never* get hardware support for above 2.1. ;)
nanonyme: The r600 is probably actually 3.1 but who cares, we're not even close to it yet. ^^
bobbens: it does 1.5 already? nice
bobbens: I have an old one that does 1.4 :P
nanonyme: Yeah, with hardware-accelerated VBO's and OQ it got 1.5.
bobbens: GLSL wasn't required for 1.5 right?
nanonyme: Only for 2.0.
nanonyme: thinks the matrix is pretty damn green for classic Mesa for the old cards already though.
nanonyme: I'm not sure how much sense it makes though that KMS is a row instead of a column.
nanonyme: Or rather a set of columns.
nanonyme: (considering there were features that had to be reimplemented and might not be DONE in KMS even though they are in ddx modesetting)
laska: edt: sertanly, this does not help
thematt: for radeon x1650 need to use xf86-video-ati or xf86-video-radeonhd?
DanaG: that's weird... RS690 doesn't do hardware TCL? Even though things as old as R100 do?
yangman: thematt: either will work
DanaG: oh, somebody might wanna' update the bit about hdmi audio on r600.
thematt: yangman: what is better? :)
agd5f: DanaG: until the r6xx based IGPs, none of the older igps did tcl
agd5f: DanaG: the matrix just doesn't break out the older chips as thoroughly
nanonyme: Aren't we glad that at least changed then...
agd5f: what is r200 missing for 1.4?
gimzo: r400 is missing just shaders for 2.0 ?
soreau: When will r300 optimizations begin?
soreau: so many questions
agd5f: gimzo: all shaderful hw already supports shaders (older arb shader extenstions). GLSL is what's missing
suokko: agd5f: ARB_shadow and depth textures
agd5f: suokko: ah, right
gimzo: agd5f: ok, thanks
gimzo: I just remember that a game in wine that worked ok a year ago with catalyst doesn't work now, so I guess the driver is missing something
thematt: radeonhd don't work with radeon x1650?
thematt: in Xorg logs:
thematt: (EE) RADEONHD(0): Power Management: Cannot get known good chip configurations
adamk_: thematt: You should probably ask radeonhd questions in #radeonhd :-)
thematt: oh, ok
adamk_: But, yes, the GPU should be supported by radeonhd. Not sure about power management.
mzz: weirdness! Can you spot the oddity in this dmesg output taken after a resume: http://paste.pocoo.org/show/141624/ ?
mzz: I wonder if the same applies to some of the random lockups I've been seeing.
mzz: obvious followup question: what has a 5 minute timeout?
nanonyme: agd5f: If you find out, feel free to tell us too. ;)
yangman: has this been reported to bugs.fdo?: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/347618
yangman: oh, bah, I can't read. there it is
nanonyme: yangman: Probably tried out to see if it's related to that other bug, aight? :)
yangman: other bug?
nanonyme: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/347618 -> https://bugs.freedesktop.org/show_bug.cgi?id=21855 -> https://bugs.freedesktop.org/show_bug.cgi?id=21561
yangman: that's how I tracked it down. :p I'm assuming they're related. just trying to find reports right now
nanonyme: yangman: What I meant to ask, did those instructions work for you?
yangman: nanonyme: oh, I haven't tried yet
yangman: didn't read the comments in the bug until now, so didn't notice the workaround. I might spend this afternoon poking at it
nanonyme: agd5f seems to just have been trying to pinpoint the faulty primitive there, just wondered if you might want to check if your results lead into the same direction.
dileX: anyone with gallium experience? might have a look at
kcodyjr: airlied, trying to decide whether the edge failure case of the buddy algorithm is a problem or not. nanonyme identified the worst case, and we're currently batting around ideas to solve it but nothing good yet. thing is, i'm not sure if it's better to fix it or ignore it
kcodyjr: that case is, for a total range of M, if you alloc (M/2)+1, then try to alloc (M/2)-1, the second one will fail
kcodyjr: that's because the classic buddy algorithm would have allocated all of M on the first call, and the fairweather extension I'm using would represent the remainder as a list of blocks all 2^n sized, rather than a single remainder
kcodyjr: so the question is: does anybody think that case would ever come up in reality
kcodyjr: kudos to nanonyme for some seriously rigorous C.S. analysis, by the way.
kcodyjr: airlied must be unplugged. anyone else have an opinion about this?
twnqx: i finally got displayport output with the git driver :)
twnqx: just umm... how do i get my audio activated there?
kcodyjr: welcome back, split victims
zhasha: wry hero thar
airlied: laska: yeah I need to drop that backtrace, its just to say someoen had a gpu with nothing plugged in
airlied: suokko: the kmalloc getting 64k fail should be fixed now
laska: airlied: ok
laska: airlied: once more question, i have multiseat X11 configuration. Today i try to setup it with 2 radeon cards. Everything is ok, but there are two issues
laska: 1) it looks like second radeon card does not fully properly initialised if DRI is enabled on primary radeon (the screen looks like 2 slightly shifted between each other images, display in sertan videomodes says about invalid frequences)
laska: 2) during normal work on secondary videocards the display may becomes blank for several seconds, after that sometimes we get again a message from display about invalid videomodes
airlied: we might just not be booting the secondary cards completely properly
airlied: if you are using kms, DRI on the primary shouldn't be optional
laska: it also looks like the first X-server affect the second X-server
laska: i use kms
airlied: can you post logs from the X servers?
laska: starting logs?
airlied: from either server
laska: ok, just 5 min. I need to reconfigure my system back to use two radeon cards ;-)
laska: airlied: Xorg.0.log -- http://pastebin.com/d4c99a0e3
airlied: laska: looks okay, you've set the onboard to be primary and post the second card?
laska: airlied: Xorg.1.log -- http://pastebin.com/d6ec9479e
airlied: laska: wierd I can't see how the could be affecting each other
airlied: does just running the server on the second card show problems (with two cards in the system?
laska: hm... maybe with two radeons, because radeon + nvidia or two nvidia works fine
airlied: I think its probablt the posting of the second card that might be missing something
laska: it maybe. Can it explain the unxepected screen blanking on secondary radeon ?
laska: and periodic unexpected switching to incorrect videomodes just during surfing web?
rnoland: airlied: ever seen a case where sg pages that were zeroed in kernel have crap in them after being mmaped?
MostAwesomeDude: airlied: I'm about to put an r300 AGP in beside my r200 PCI. Is this dangerous?
rnoland: i've now eliminated all of xorg and the card....
rnoland: i can't reproduce it... but i do periodically get reports of this problem...
virtuald: I accidentally 93 MB of rar files. Is this dangerous?
airlied: rnoland: sounds like a VM screw up
airlied: MostAwesomeDude: only if you aren't using kms + latest everything
rnoland: airlied: yeah, that is where i'm looking...
rnoland: but i can't repro on any of my boxes... i386 or amd64
airlied: bad RAM?
rnoland: airlied: if it is... it's consistently bad...
rnoland: the folks that report the problem it is always present...
airlied: make them run memtest
rnoland: it is the radeon ring that it show up in.
MostAwesomeDude: airlied: I am, but I only want to use the r300. I'm just wondering if the r200 should be removed.
rnoland: and dereferencing the pointer from kva it is correctly zero...
airlied: rnoland: what gpu?
rnoland: after mmap dereferencing from user it has crap in it..
rnoland: airlied: this is an 4550, but iirc i've had reports on 9200 or something as well
airlied: its unlikely the gpu is writing to it, multiple gpus or anything strange?
rnoland: airlied: i haven't even told the gpu about it at this point...
rnoland: i even wrote a test prog to interface with libdrm directly to make the calls.
airlied: rnoland: definitely sounds like a VM screwup
rnoland: all it does is open, sg alloc, add map, mmap
rnoland: airlied: what i can't figure out is what triggers the issue...
rnoland: current report is a core i7 running i386 mode on an intel board...
rnoland: so i'm looking for a CPU or BIOS quirk maybe...
rnoland: it's freakin weird...
rnoland: even had him disable SMP...
kcodyjr: i thought i remember reading in the ldd, once you sg_add_map, you're not supposed to access that memory from the cpu anymore
kcodyjr: suggests you might be looking at a hardware caching issue
rnoland: kcodyjr: i thought about that...
rnoland: was trying to figure if i could trigger a cache flush (wbinvd) from userspace...
rnoland: but i'll have to hack around in the kernel for that...
kcodyjr: i think there's an interface to get control of it back to the cpu momentarily, short of removing the map
rnoland: and it all just works for 99.9 percent of users...
kcodyjr: probably the .1% misbehaving chipsets getting in your way
airlied: rnoland: some IOMMU stuff?
airlied: check they have VTD or virt stuff off
airlied: in the bios
rnoland: airlied: possibly...
laska: airlied: is there any chance that the issue will be fixed?
nox-: anyone seen the new googleearth kill the xserver w/o even leaving an error in the xorg log?
soreau: nox-: Which version of google earth would that be?
MrCooper: nox-: check the X server stderr output, e.g. in the gdm/kdm log file
nox-: hmm i used startx...
nox-: ok i think ill run that in script(1) next time
nox-: but not now :)
soreau: nox-: And which card?
nox-: RV730 PRO
soreau: well I don't have that version of GE nor anything near that card model so I can't test :)
nox-: well the version is the one they distribute now...
nox-: since of a week or so
danij3l: is it possible to enable EXA on mobility radeon X1600 without xorg.conf (everything else form xserver built-in conf is ok for me, so i don't use xorg.conf)
danij3l: Xorg.0.log - http://pastebin.com/f5d52c708
mzz: in a new enough radeon driver it'll use exa instead of xaa by default
mzz: until then I'm pretty sure you need either xorg.conf or to patch the driver
danij3l: xf86-video-ati 6.12.2
mzz: however xorg.conf can be quite short (probably shorter than you think)
danij3l: new enough?
mzz: I forgot if that had exa default yet
danij3l: xorg.conf wit only
danij3l: Option "AccelMethod" "exa"
danij3l: that is what i need :F
danij3l: is thar any way to edit this defaults?
MostAwesomeDude: Sure. xorg.conf.
MostAwesomeDude: Alternatively, change the default in the source and recompile.
soreau: or just grab the latest source and compile
mzz: danij3l: iirc it's just Section "Device", Identifier "whatever", Driver "radeon", Option "AccelMethod" "exa", EndSection
danij3l: soreau, when (what ver) EXA became default?
mzz: not much more than that, but perhaps not quite exactly that
soreau: danij3l: I think only in git so far
soreau: Not sure if there is a release with the default exa code yet
spstarr: should I build drm-next today?
soreau: spstarr: Shake your eight ball
soreau: Signs point to yes
danij3l: soreau, if it defaults to EXA some time soon that will be just fine
danij3l: XAA is not that bad
danij3l: found it :D
danij3l: 2009-05-04 radeon: switch to EXA by default
berniyh: [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
berniyh: hmmm ^^
adamk_: berniyh: Trying KMS?
berniyh: sort of
adamk_: OK. I thought that was a yes or no question.. Apparently not :-)
adamk_: In any case, you probably need to update your DDX>
berniyh: I am trying kms, but not really trying hard
berniyh: better? ;)
berniyh: I just got confused by that statement, since I think that 2.0.0 is >=1.17.0 ;)
adamk_: Yeah, it is odd. But I had that problem before when I tried KMS, and was told to update the DDX.
adamk_: I think I had to update libdrm, too, and build it with the experimental radeon api option.
mzz: sounds about right.
mzz: the error message is a little backwards here, but basically the kernel side is too new for the userspace side
MrCooper: different major version means incompatible
adamk_: As I recall, I had to update libdrm *before* I updated the DDX, so that the DDX would see the updated libdrm.
mzz: (but at least gentoo builds libdrm with the experimental api by default for some reason, so you may not have to)
berniyh: adamk_: libdrm is 2.4.14, which has the experimental api, afaik
soreau: mzz: I thought it only enabled experimental api in the x11 overlay build
mzz: CONFIGURE_OPTIONS="--enable-udev --enable-nouveau-experimental-api --enable-radeon-experimental-api"
mzz: that's libdrm-2.4.14 in the main tree
berniyh: updating ddx means updating xorg-server, right?
mzz: not necessarily
berniyh: or do you mean the ati driver?
berniyh: btw, dmesg says [drm] radeon: kernel modesetting successfully initialized.
soreau: That doesnt necessarily mean 3D was though
mzz: "ddx" here is xf86-video-ati, or whatever your distro calls it.
soreau: berniyh: If using a binary distro, you might want to review the link in the topic
berniyh: mzz: right
berniyh: that's on HEAD
berniyh: but I think I know what's missing
berniyh: didn't update mesa
mzz: that'd hurt 3d
berniyh: and the message above was about dri ;)
berniyh: after that it did disable dri
berniyh: strange though that dri seems to work fine
nox-: hey adamk_ if your still around :) is there a writeup yet on r7xx gl on freebsd, esp the userland parts?
airlied: laska: possibly, should file a bug describing it, probably something to do with clock setup when we post
adamk_: nox-: Not that I know of... I'm not sure if you need -CURRENT or simple the 8.0 RCs. You do need mesa from git. The guide in the topic should tell you the commands to pull Mesa from git. Instead of checking out a specific version, you'd stick with the latest from master.
adamk_: rnoland: Is -CURRENT necessary for r600/r700 ?
nox-: i think it is, but he said earlier the drm bits should be easy to merge back
izu_: I am totally drunk
AndrewR: MostAwesomeDude, ping
DanaG: ugh, so annoyingly hot.
MostAwesomeDude: AndrewR: Pong?
rnoland: adamk: only for 3d
adamk_: rnoland: Thanks. I can never remember where all the bits are located these days :-)
rnoland: 2d and Xv are in all stable branches...
rnoland: 3d is only current right now...
rnoland: er, 7-stable+ rather...
_moep_: lol but radeon doesnt work at my card :D
rnoland: adamk: 6 is dead to me....
adamk_: _moep_: 2D should work on all available radeon cards with the 'radeon' driver.
adamk_: rnoland: Yeah, I can't blame you for that :-)
_moep_: not on my card :)
_moep_: i got a black screen :)
rnoland: _moep_: what card
_moep_: bugreport is open since ~2months
_moep_: Radeon HD 4350
AndrewR: MostAwesomeDude, there was talkm on xorg-devel, among other things there was omapfb driver .. looking in google i found you has plans for something like beagleboard (proper graphics driver)
rnoland: 4350 should work, at least if you aren't using kms...
AndrewR: MostAwesomeDude, talk ...
AndrewR: MostAwesomeDude, http://lists.x.org/archives/xorg-devel/2009-September/002227.html
_moep_: rnoland: it doesnt work witout kms
MostAwesomeDude: AndrewR: Yes and no.
rnoland: _moep_: what version of ddx?
Batou: Wow, today's git pull means I can run Quake Live with KMS finally.
rnoland: _moep_: i assume you are on linux?
Batou: Wonder if it will still lock up Xorg like the super-buggy one did yesterday.
_moep_: oh alex post something
MostAwesomeDude: There's been a change of plans; OSU won't be pursuing omapfb improvements at this time.
_moep_: lets check and reply later...
AndrewR: MostAwesomeDude, if ound some git trees and only realized there was nearly no acceleration code after sending links to michael .. ops. Right now i think some accel code was in kdrive-based xserver for omap ... may be i wrong again (sorry for OT)
MostAwesomeDude: AndrewR: There's only accel for Xv.
MostAwesomeDude: AndrewR: To have acceleration for most OMAPs, you're going to need to drive the SGX chipset.
MostAwesomeDude: And you're not going to get that easily.
AndrewR: MostAwesomeDude, hm. (thanks).. because my search end nearly without results - i think my best move will be ... off to bed. Have nice time, and thanks for support!
MostAwesomeDude: AndrewR: Sure. Sorry for the lame situation; maybe it'll improve soon.
dileX: OK, latest pushes fixes to xorg-server let radeon-driver come up. gallium-radeon (modesetting_drv.so) still borked
MostAwesomeDude: dileX: That's radeon, not modesetting.
dileX: MostAwesomeDude: whats the name of the driver?
dileX: MostAwesomeDude: xorg.conf
MostAwesomeDude: dileX: You need to use "modesetting" instead of "radeon".
dileX: MostAwesomeDude: yoh
dileX: radeon is working know (so think its modesetting)
dileX: grr, the Xorg.log is the wrong one
dileX: MostAwesomeDude: sry for wrong log, here the right one
dileX: MostAwesomeDude: any idea?
dileX: is the backtrace helpful?
MostAwesomeDude: A bit.
MostAwesomeDude: I'll be experimenting with it a bit more later.
joosu: hei MostAwesomeDude i red bit more of that i965 complicated GLSL code, and it seems to me that hw structs from there can be used, those regs to match mesa regs, they end up as static inlines, thinking how to force them to core mesa, theyd have to be static
soreau: modesetting uses rXxxg?
dileX: MostAwesomeDude: if you guide me I could do a ssh-gdb-session
dileX: soreau: yupp
MostAwesomeDude: dileX: It looks like I should be able to reproduce it over here.
MostAwesomeDude: soreau: It will.
soreau: cool :)
dileX: MostAwesomeDude: culprit was xorg-server from master GIT, I could not start even radeon-driver. MrCooper fixed that in "EXA: Fix mixed pixmaps crash with missing / failing UploadToScreen hook."
MostAwesomeDude: joosu: Already done for Gallium. Chill a bit.
MostAwesomeDude: dileX: Ah.
dileX: MostAwesomeDude: but gallium-radeon is still b0rked with latest xorg-server, latest mesa from GIT master
dileX: MostAwesomeDude: could activated vgaarb ind kernel be a problem? (wild speculation)
dileX: (pushed libpciaccess to 0.10.9)
MostAwesomeDude: dileX: Doubt it. It looks like some problem in exa st.
dileX: MostAwesomeDude: can I help, anyway?
MostAwesomeDude: dileX: If you can track down how the segv is happening and write a patch, that'd be great.
MostAwesomeDude: Otherwise, one of us will encounter it at some point.
joosu: MostAwesomeDude: hmm, haven't tried gallium, i see x600/700 gaining 3d, done for them as well?
MostAwesomeDude: joosu: Not yet. Soon. i915 on Gallium is doing well though.
dileX: MostAwesomeDude: maybe the first part (but I look into the wiki Debugging xserver IIRC)
dileX: ah, I have it (good bookmark management)
joosu: MostAwesomeDude: i saw two ways, libsh and mesa , seems like intel acquired libsh, but pbuffer code is there needs to be ported, now to intercept glsl in glx and fource libsh would be also possible
joosu: MostAwesomeDude: i only new nouveau is doing well on gallium, but none tested i915
dileX: MostAwesomeDude: never tried - thats why I am asking: "...Edit your xorg.conf file and find the ServerFlags section.Uncomment the
dileX: Option "NoTrapSignals"
dileX: shall I try this first?
MostAwesomeDude: joosu: fgsfds
MostAwesomeDude: dileX: Won't help.
dileX: MostAwesomeDude: thats my build-script
MostAwesomeDude: dileX: Honestly, I don't have a fully working stack for this stuff ATM, but I should be able to start investigating soon.
dileX: MostAwesomeDude: n.p.
joosu: fgsfds? that prolly means something ironic/sarcastic right?
dileX: for me these are first steps with Gallium3d
soreau: joosu: google it
joosu: like makes no sence?
MostAwesomeDude: joosu: libsh is higher-level than what we're doing. So is GLSL.
joosu: should make, as long as context rolls in hardware, either over brw_context.h that leads to batchbuffer, or over fbo's which also do that
MostAwesomeDude: Whether GLSL works depends on whether the driver supports the opcodes.
MostAwesomeDude: Nothing to do with batchbuffers. Nothing to do with FBOs.
MostAwesomeDude: Just a couple shader opcodes.
joosu: MostAwesomeDude: library that would be linked to libgl would manage lowlevel over it's fbo plus arb backends
joosu: MostAwesomeDude: that's not true, and you know it, it requires hw context
MostAwesomeDude: joosu: i965 doesn't do things intelligently all the time.
MostAwesomeDude: r300/r500 only needs a bit more shader work.
joosu: MostAwesomeDude: very hacky, but works, long pot, still that management leads to intel dir/ intel_reg and batchbuffer and some other files, so structs edventually are in hw and operators shifts as well
joosu: radeons memory management is different, i only abstractly understands intel one, it's difficult brainwash:)
joosu: MostAwesomeDude: njah never seen r300/r500 in action, but mesa code is shorter for r300, frags etc. handled completely differently, like core mesa way _load_mesa mattrices , i'm afraid TG hackers only understand how long pots can be made/calculated:)
joosu: MostAwesomeDude: yeah libsh is high level language, but radeons do fbo, to sanitize/parse that into driver, then brook 0.4 0.5 changes need to be inspected, what was changed to get fbo's and all chips would get one new file prolly
MostAwesomeDude: FBOs are orthogonal to advanced shaders.
joosu: i belive they store context in them, but not sure, anyways shaders with lish would come from another thread and painted to correct location
spstarr: builds drm-next
joosu: MostAwesomeDude: aight i leav you alone now, it's only my understanding, both c++ and c isn't perfect for me either, but triggering such a hw flow to each driver differently like i965 seems lot of pro work
MostAwesomeDude: joosu: That's the entire point of drivers.
MostAwesomeDude: Abstract out HW into an interface.
joosu: MostAwesomeDude: yup currently i know three that could abstract flow to arb, one i965 files, two libsh to arb and three seems like core mesa has also files but needs speedups probably, i may be terribly wrong
joosu: but i965 boils like to 10000 lines all pass0-4 frags ang glsl code to acheive that, wonder how many mistakes a dude like me could do porting such a code over:)
spstarr: tries today's drm-next + mesa git
spstarr: File radeon_dma.c function radeonReleaseDmaRegions line 348
spstarr: Leaking dma buffer object!
spstarr: bo(0x7fe68a0, 98304) is mapped (1) can't valide it.
spstarr: validated 0x7fe68a0 [0xF0432000, 0xF0442000]
spstarr: then it just gives up running