dottedmag: I've got a crash while trying to disable output in RandR with current ati driver. Nothing suspicious in logs, except missing r600_dri.so (hope it's not related) and segfault :)
dottedmag: http://dottedmag.net/~mag/Xorg.0.log and (if needed) http://dottedmag.net/~mag/Xorg.0.log
MAD|dead-router: Hey, guys. Router isn't picking up the phone, and I lack an IRC client here, so yay for Mibbit.
MAD|dead-router: is MostAwesomeDude
MAD|dead-router: glisse: Are the newttm ioctls reliable enough to use in r300-gallium yet, or are you still debating them?
MAD|dead-router: stikonas: Were you the person bugging me earlier about newttm and r300-gallium?
stikonas: yes: but ossiris explained that r300-gallium doesn't have ioctls yes
airlied: MAD|dead-router: which ioctls? only the info one is probably needed.
airlied: or missing
MAD|dead-router: Right. Which ioctl died? PCI ID, MM info, or GB pipes?
airlied: getparam which does pipes and pciid
MAD|dead-router: airlied: My guess too, but I wanna make sure. Also I don't know if the API's been decided for sure yet.
airlied: there is a new info ioctl
MAD|dead-router: Is there any code I can examine for examples?
airlied: MAD|dead-router: some in ddx or radeon rewrite I would guess
MAD|dead-router: Hm, 'k.
MAD|dead-router: So are we gonna just put RADEON_GEM to bed, then?
MAD|dead-router: (Please say "yes!")
airlied: whats that? a getparam if so yes
MAD|dead-router: No, the whole "lol radeon uses gem for mm" deal.
MAD|dead-router: And all the RADEON_GEM_* defines.
dottedmag: Is SWCursor supposed to work with current radeon driver? I'm getting xrandr-related crashed when it's enabled.
dottedmag: (see the logs above, reproduces only with SWCursor on
glisse: MostAwesomeDude: i might switch back to non allocated memory for get info this would makes things easier
AndrewR: glisse, hello! when using xf86-video-ati (radeon-gem-cs3 branch) - should i add some option to xorg.conf for dri2? i'm sure i have KMS enabled (with Dave's kernel) but dri init failed
glisse: no need for option
AndrewR: i mean nothing about dri2 in xorg log from radeon driver itself
glisse: AndrewR: but on my kernel you need my ddx
glisse: if ddx try to initialize dri1 somethings is wrong and it won't work
AndrewR: glisse, yes, i tried your kernel + your ddx , but it fails :(
glisse: i will patch my ddx to quit if dri2 fails
AndrewR: glisse, http://pastebin.com/m1dbb999a
chithead: hello, I am using the kms from drm-next-radeon and xf86-video-ati from radeon-gem-cs3, which mostly works. but my lvds needs an edid quirk from bug 10304 which is apparently missing. how can I make sure it is applied?
glisse: AndrewR: you should see:
glisse: (II) RADEON(0): Depth moves disabled by default
glisse: (II) RADEON(0): [DRI2] Setup complete
AndrewR: glisse, no such string
nanonyme: Hmm, so it fallbacks to software rasterizer.
nanonyme: "(EE) AIGLX error: drmMap of framebuffer failed (Invalid argument)" Hmmhmm.
glisse: AndrewR: i will add more verbosing into the ddx to know why kms isn't detected
nanonyme: glisse: Any idea what that error in AndrewR's log means? ^^
nanonyme: Sounds odd.
glisse: chithead: we don't have quirk for modes yet in kms
glisse: nanonyme: kms initialization failed long time before that
nanonyme: Oh, right.
chithead: glisse: only if I run xrandr after X has started, it will give a message about the edid quirk in Xorg.0.log
glisse: chithead: so you got somethings on the screen but it's just not good res ?
dileX_: AndrewR: did you try to activate kms on kernel-command-line (e.g. grub)? I prefer run into init-3 and load radeon-driver with "modeset=1" option and start manually X via startx.
chithead: glisse: the fonts are totally huge, I have to run "xrandr --dpi 96" before login
AndrewR: dileX_, same for me. manual modprobe fbcon , modprobe radeon modeset=1 from VGA console
chithead: glisse: apart from that, I did not observe any graphical glitches
dileX_: AndrewR: here it is OK with latest drm-next-radeon and ddx (both from glisse's GIT-repos)
AndrewR: dileX_, i have AGP rv280 (r200-class) card ... it may have more problem
dileX_: AndrewR: might be, here is x1300 (r500)
AndrewR: dileX_, and your libdrm was from mesa/drm modesetting-gem, not from glisse tree?
dileX_: AndrewR: no, seems to be a pitfall
dileX_: AndrewR: you are right
AndrewR: dileX_, yes, i have them installed (libdrm, radeon-rewrite, xserver, ddx - in this order. recompiled few times ...)
AndrewR: i will rebou into "gl" kernel, and post exactly error
AndrewR: glisse, http://pastebin.com/m1d7199b6 (xorg.log)
AndrewR: glisse, http://pastebin.com/m5b45807 (/var/log/messages)
glisse: AndrewR: i need more verbosing in ddx as there is no message from where it fails
glisse: Xorg log is pretty useless right now
AndrewR: glisse, yes, sorry (i was mostly playing with Dave work) ... can you wait for hour or so? i need to go out ...
glisse: AndrewR: there is nothings you can do until i add more code :)
AndrewR: glisse, i'm back. there also /var/log/syslog, with one line from drm (in non-debug-mode): May 3 14:30:03 (none) kernel: [drm:radeon_cp_init_kms] *ERROR* invalid ioctl with kms radeon_cp_init_kms
glisse: AndrewR: yeah it's due to ddx trying to init dri1
AndrewR: glisse, thanks .. (so this line just indicator, not source of the problem)
glisse: osiris__: i think your issue is due to mutex contention
glisse: i should not play with the fbdev mutex
moveax: hi all
moveax: I have a small question
LukaszJ: moveax: Go ahead :)
moveax: I'm usng the ATI driver but it does not work perfectly. I've some glitches (white stripes) sometimes in the right part of the screen. It happens especially when I move or update large windows with a lot of white inside. I've tried by using the "XAA" acceleration instead of EXA but it says that XAA is not supported with this card and switch back to EXA. If I disable acceleration the pb disappears but the performance is not acceptable
osiris__: airlied: I got a question about r300ValidateBuffers
osiris__: airlied: it is called first time in r300RunTCLRender
airlied: osiris__: yup
osiris__: airlied: if it fails it will probably be called second time in r300RunNonTCLRender
airlied: yup no harm calling it twice in theory
osiris__: airlied: is it possible that it won't fail this time?
airlied: no I think the same set of buffers would need binding
osiris__: airlied: or maybe we should fallback to software rasterizer if it failed first time
airlied: I wasn't sure I cuold fallback to swrast any quicker
airlied: than returning true from both those stages
osiris__: airlied: yeah, but currently we call the r300ValidateBuffers in r300RenderStart(r300_swtcl.c) without checking the return value
airlied: that can die
airlied: the NonTcl should cover it
osiris__: airlied: is it possible that it could lock the GPU if r300ValidateBuffers failed?
airlied: at least I think it cuold
airlied: bad things can happen but I'd expect TTM to fail to validate
airlied: not gpu lockup
airlied: at the moment the drm should assert if validate fails and you emit a reloc
airlied: at least in the kms case
osiris__: airlied: but what in standard (non kmm) version? could it be one of the reasons of mysterious random lockups?
airlied: don't think it should really affect non-kms, it would fail vram validate at a gues
airlied: you can add the same assert to the reloc emission in nonkms
airlied: to test but I don't think it should effec it
elbeardmorez: hi. i'm trying to work out which part of my lastest git updates have caused the regression whereby only 1 of 2 pci cards are identified for probing. Which part of the x11 code base handles this please?
osiris__: agd5f or bridgman: do you know if the fragment program on r300-r500 hw can occupy insts e.g. 59-64 and 0-9 ? I'd like to implement fragment program manager - it would store as much fp's as possible on GPU and just change US_CODE_OFFSET, US_CODE_ADDR, US_CONFIG and US_PIXSIZE
osiris__: agd5f: of course it would give us some performance improvement only if all the regs (US_CODE_OFFSET, US_CODE_ADDR, US_CONFIG and US_PIXSIZE) didn't require pipeline flush (in docs I can see that only US_CODE_OFFSET doesn't require pipeline flush)
Terwou: glisse: http://pastebin.com/m52b28c87
osiris__: glisse: how do we know when ddx driver have changed something in GPU setup and we have to reemit all state?
glisse: osiris__: i don't think fragment program manager will give you major speed boost
glisse: Terwou: try with option agpmode=-1
osiris__: glisse: what will then?
glisse: minimize flushing
osiris__: glisse: program manager would certainly be helpful with minimizing flushing
glisse: in mesa you need to assume that all state are lost
glisse: you still can do a program manager when you build one cs buffer
osiris__: glisse: I don't understand. so we are emitting full hw state with every flush operation?
osiris__: glisse: oh, that sucks
osiris__: glisse: maybe we could add an ioctl to drm that will tell us if hw is dirty?
glisse: kernel doesn't know what dirty means
osiris__: glisse: dirty would mean that some other process have send us command sequence
glisse: osiris__: even so, by the time we get answer from kernel another process might have send new cmd
glisse: we could do somethings like r300 trick in cs ioctl thought
osiris__: what's the trick?
glisse: cs is split in two, first part is full state and are emited only if hw dirty, second is draw cmd
osiris__: glisse: sounds good
osiris__: glisse: would it be hard to implement?
glisse: hhhmm we would need to add some kind of context id so kernel & userspace knows about what they are talking
glisse: maybe only using process id is enough
glisse: could be tested with process id
osiris__: I thinks pid should be enough
osiris__: glisse: I used pid to implement killing app that caused the gpu lock
glisse: it would be fine if process id use only one way to talk to drm so Xserver won't work here as Xserver might send cmd by the ddx or through mesa
osiris__: and it worked well
Terwou: glisse: ok X starts now but major font corruption
rah: I have an r7xx; should I be use the master branch or the r6xx-r7xx-support branch?
glisse: Terwou: lastest everythings ?
osiris__: glisse: I don't understand. you're saying that under Xserver pid there could be two different contexts using gpu?
glisse: osiris__: yes ddx or mesa (AIGLX)
glisse: at least i think it's same pid here
Terwou: happens with airlieds kernel too IIRC and its a recent regression then
onestone: glisse: osiris__: what about opengl and openvg in one app? should be the same problem. or is gallium smart enough to handle it correctly in the driver?
glisse: onestone: would be fine as gallium will go through the same pipe
onestone: glisse: but there might be multiple direct rendering architectures in the future that will not share the same emit code
glisse: onestone: yeah
osiris__: glisse: then kernel could assign unique id to every new context
glisse: osiris__: i am not sure context is the best solution
glisse: too much stuff in kernel, maybe a better solution is to make cs return unique id (like fence) and userspace will use it as context id, so trouble is in userspace
osiris__: glisse: I don't think it's too much stuff. only two additional ioctls: 1)EMIT_FULL_STATE or something, that kernel would actually send to kernel if previous context_id was different 2) ASSIGN_CONTEXT_ID - self explanatory, and two additional fields in some radeon struct (last_context_id - obvious, and max_context_id)
glisse: 1 is not needed and not wanted, in cs you provide context id and kernel check against last context and emit or not the full state
osiris__: you see, even simpler :)
Terwou: glisse: my font corruption magically disappeared :)
spstarr: glisse: ping
sannes: Using glisse's drm-next kernel, when I do modprobe radeon modeset=1, the screen goes black ..
sannes: any suggestions?
sannes: (everything seems to look good in the kernel messages)
AndrewR: sannes, for me "modprobe fbcon" solves black screen (but i guess in my cas e it was more about kernel misconfiguration)
spstarr: compile fbcon into kernel
sannes: AndrewR : Ah, that worked
sannes: AndrewR: It had to be loaded before radeon right?
out3: hi i need some informations about tvout and radeon 9200 with driver radeon
out3: now tvout works but if i want play some movie in player i can see only black screen instead video
crdlb: out3: I'm not sure whether the video overlay can work over tv out, but you should try switching to textured video
out3: how can y try switch to textured video?
crdlb: what video player are you using?
out3: for example smplayer
out3: this option- textured video is feature of videoplayer? sry for my poor english
crdlb: no, it's a feature of the driver, but you must choose it in the video player
AndrewR: sannes, before, but i can type this blindly, too. (just try to compile-in fbcon)
AndrewR: sannes, i prefer to keep my kernel small, and have nearly everything as modules
out3: crdlb hm ok i try it searching
crdlb: out3: with gstreamer you can easily set it in gstreamer-properties, and it looks like Video > Output driver works for smplayer
sannes: AndrewR: Yeah, keep most as modules myself, test more stuff than I actually use :)
sannes: KMS seems to be working here (altough, very slowly with X..) And "[drm:radeon_cp_start_kms] *ERROR* invalid ioctl with kms radeon_cp_start_kms" in my kernel log..
nanonyme: bridgman: Hey.
nanonyme: Having an interesting concersation on the forums, I see. ;)
agd5f: out3: overlay only works on 1 crtc at a time. you can use xvattr to change the crtc by toggling the XV_CRTC attribute, or use textured video
bridgman: well, it's really the same conversation over and over again, but interesting new people ;)
nanonyme: I meant that Davy guy, that discussion has continued for quite a while.
bridgman: yep, he's asking reasonable questions, it's just that everyone has a different set of priorities
Zajec: what do you mean by overlay? just Xv?
bridgman: Xv can work with overlay or textured video
Zajec: ahh, see it now
Zajec: does anyone use overlay anymore?
bridgman: I think radeon defines a bunch of xv ports, 1 for overlay and 16 more for texvid
agd5f: Zajec: it's only epxosed on r1xx-r4xx chips
bridgman: not much; it doesn't work with a compositor, and the main reason for keeping it around was that it had some hardware support for tear-free playback
bridgman: going to 5xx we took out most of the video processing blocks from overlay; those chips were really designed for textured video from day one
agd5f: the overlay on newer chips isn't really well matched to video
mjr: I rather like the fact that my overlay works on the whole desktop rather than clipping halfway through the second screen :]
mjr: but of course, this is a lesser issue on the newer chips with textured video as well
sgcb: Just wondering, are there any benefit's to using Zaphod configuration for dual head?
agd5f: sgcb: only if you want independant heads
agd5f: otherwise it's inferior in every way
sgcb: independent heads?
spstarr: hey bridgman
mjr: I'd rather have twice the capacity in my existing head
agd5f: sgcb: :0.0 and :0.1 separate xscreens
agd5f: sgcb: can't drap windows between heads, etc.
sgcb: oh, i see. thank you
mjr: wait, the ol' X multihead configuration is actually named Zaphod? :]
agd5f: mjr: yeah
mjr: since when? :)
agd5f: for ages
airlied: mjr: when randr1.2 came out we needed a name for the older method, not sure who came up with it. ajax maybe.
Kano: hi airlied, agd5f
Kano: just tested current git and dont get edid
Kano: RADEON(0): Chipset: "ATI Radeon 9600SE AQ (AGP)" (ChipID = 0x4151)
Kano: interestingly VESA driver gets edid
Kano: radeon: http://paste.debian.net/35151
Kano: vesa: http://paste.debian.net/35148
agd5f: Kano: do you get an edid with 6.12.2?
Kano: if it would have worked with 6.12.2 then i would not have tried
Kano: or better it is miltonjohn's box
Kano: i just told him how to install git code
dols: i have an RV370 (X300 PCIE).
dols: i want to do dual-head
dols: and the card is supposed to have 128M
dols: but the driver only picks up 32M
dols: and doesn't enable DRI
dols: am i screwed?
bridgman: dols, why do you think the driver is only picking up 32M ?
Kano: hi bridgman
bridgman: is there any chance you have a HyperMemory card which only really *has* 32M ?
bridgman: hi Kano
dols: (II) RADEON(0): Detected total video RAM=32768K, accessible=32768K (PCI BAR=32768K)
dols: (--) RADEON(0): Mapped VideoRAM: 32768 kByte (64 bit DDR SDRAM)
dols: also lspci tells me something similar
dols: and yes it is a hyper memory card
dols: bah, pre-built dell
rah: I have an r7xx; should I use the master branch or the r6xx-r7xx-support branch?
rnoland: bridgman: any idea why video is out of sync now/again?
nanonyme: rah: Hmm, for EXA? r6xx-r7xx-support from DRM, master from radeon driver.
bridgman: roland; if you mean occasional tearing, I think that may just be a consequence of how tear-free is implemented
rah: nanonyme: I just mean in general
bridgman: if you mean "sometimes it just doesn't work" then I don't know
rnoland: bridgman: no, i mean it just playes way too fast...
nanonyme: rah: Well, the newest thing that actually does something is the EXA + Xv bit, that's doable by those two branches.
rnoland: when i first started messing with the r6/7xx code...
bridgman: I saw someone else mention playing too fast a while back -- don't *think* that's a driver thing
rah: I have issues with DRM :/
rnoland: the ati driver did it, but the radeonhd worked right..
rnoland: bridgman: i was messing with it again yesterday and both drivers don't sync now...
nanonyme: rah: What doesn't work? Can you give dmesg entry for inserting radeon module?
bridgman: rnoland; what is your refresh rate ?
rnoland: bridgman: it's a dvi attached panel....
rah: nanonyme: compiling doesn't work; I have a patched kernel
rnoland: bridgman: it seems to just run as fast as it can....
rnoland: bridgman: movie lasts maybe 10 minutes...
bridgman: cool; I always get bored watching movies
nanonyme: rah: What's the kernel version and what's the error?
rnoland: bridgman: hehe....
bridgman: seriously, that seems like a player problem; the driver isn't supposed to control playback rate AFAIK
rnoland: bridgman: hrm....
rnoland: multple players are doing it....
rnoland: both totem and mplayer...
bridgman: do they use anything common like ffmpeg ?
rnoland: bridgman: possibly...
rnoland: but i'm using the same player(s) with the nvidia card in right now and it's fine...
rah: nanonyme: kernel version is 126.96.36.199-rt8; I don't have a log of the error I'm afraid
bridgman: same video output stack, ie xv, or is it taking a different path with the nvidia card ?
rnoland: and the only thing that i changed the last time i saw this was swapping the ati driver for radeonhd
rnoland: bridgman: both are using xv
nanonyme: rah: Just do make clean && make drm.o radeon.o in linux-core directory and pastebin the error.
bridgman: ok, that's wierd
nanonyme: rah: Plus naturally sufficiently many lines before it. :) (If you're unsure what's sufficient, pastebin everything it says)
rah: there's the error
agd5f: rnoland: putimage just renders a frame. it's up to the player to determine the rate it sends the frames
nanonyme: rah: Hmm, sorry. Can't keep focused long enough to think clearly on the issue, probably off to bed. You have a double definition of ircreturn_t, seems, but the actual reason would take thinking.
rnoland: agd5f: so how does it determine the rate?
nanonyme: irqreturn_t even.
agd5f: rnoland: look at the player code
rnoland: agd5f: hrm....
rnoland: agd5f: swapped the 3650 back in with radeon driver...
rnoland: nothing else changed...
rnoland: playback is now way fast again....
agd5f: fast compared to what?
rnoland: agd5f: 1) what it should be and 2) what it was just a second ago with the nvidia card in....
agd5f: rnoland: with teh nvidia card are you using the proprietray driver or the open source one?
rnoland: both using xv
rnoland: I *think* it also still works right on r3/500
rnoland: i would have to double check that though...
rnoland: last time i saw this... the radeonhd driver worked, but ati didn't.
rnoland: agd5f: now it seems that neither work....
agd5f: rnoland: maybe the player uses the return from xvputimage for timing?
Kano: rnoland: mplayer?
rnoland: Kano: mplayer or totem...
rnoland: both do it...
rnoland: i don't have vlc installed, but...
Kano: rnoland: mplayer -vo x11 is pure
Kano: does not matter which driver then
Kano: does not scale without -zoom option but when this does not work it is mplayers/ffmpegs fault
rnoland: hrm... -vo x11 and -vo xv both play too fast...
Kano: -demuxer lavf
Kano: try that as extra or try another file
rnoland: demuxer no change...
Kano: try another file
rnoland: number of attributes: 6
rnoland: "XV_VSYNC" (range 0 to 1)
rnoland: client settable attribute
rnoland: client gettable attribute (current value is 1)
rnoland: how do i turn that off?
Kano: thats not used with x11 driver
rnoland: yeah, true....
rnoland: ah, if i set -vo gl it works right...
rnoland: different avi file, same problem.
agd5f: Kano: does this patch help with the ddc problem? http://www.botchco.com/alex/xorg/dvi_i2c_sw_use.diff
Kano: agd5f: he is gone now
Kano: will tell him tomorrow
agd5f: Kano: thanks
rnoland: how the hell is gl working....
rnoland: hrm... swrast...
rnoland: hrm... ok... wtf... vlc isn't playing too fast... but totem and mplayer do... which means that ffmpeg is getting whack with r6/7xx
DanaG: ever heard of www.publicsurplus.com ?
DanaG: example random item: traffic cones or an eMac.
DanaG: How different is ATI under PPC, anyway>
exeoeoe: http://3x3cut10n3r.mybrute.com/ <-- have fun & good luck
rnoland: agd5f: gah... it looks like mplayer is syncing off of the audio....
rnoland: hrm... the problem is if the audio is going to hdmi...
DanaG: exeoeoe has been spamming various channels with that link.
mentor_: Call netops
DanaG: ... or matybe it was just this one.