airlied: mattmatteh: ther overlay stuff is in radeon_video.c
airlied: mattmatteh: don't think its documented publically yet
mattmatteh: ill take a lot at that when i get a moment
mattmatteh: airlied, thanks
mattmatteh: i am stepping away for a few
zmcgrew: Is anybody here running the latest git version on the rs480?
agd5f_: mattmatteh: have you tried adjusting the xv attributes yet?
agd5f_: otaylor, airlied: dst cache flushes are pipelined, freeing the tags is not.
agd5f: still, nothing mroe than a workaround until we sort out the IB sumission
airlied: agd5f: I think the dst cache pipeline is maybe only on r500..
airlied: but not sure.
agd5f: airlied: as far as I can tell, it applies to both, but I'll double check
mattmatteh: agd5f, yes i gave, i bought a calibration dvd and used the grey scales. even compared with x11 which seems to show dark black right. i can not get smooth or even gradients of black
glisse: airlied: pacify shouldn't be needed, i think newer fglrx code base don't use such things
glisse: but fencing system is better for properly handling sync & flushing
glisse: also for lockup i am startting to believe that this is the event engine which is touchy ie wait_until packet should be emited carefully
otaylor: glisse: what do you mean by fencing in this context?
airlied: otaylor: using new memory manager stuff.
glisse: otaylor: yup, right now in drm we could only do assumption on when to flush
glisse: so often we flush too much and at bad time
TobiasTheCommie: airlied: just wondering, there is a minor bug on the tv-out of the rv530, i made a bug report, but anything i can do to help fix the bug(i really have no hardware experience, so fixing it myself would just be random luck)
TobiasTheCommie: https://bugs.freedesktop.org/show_bug.cgi?id=13995 <- that one
arekm: still wonders about this tv-out problem http://carme.pld-linux.org/~arekm/MVI_0213.AVI. is my tv or radeon problematic?
TobiasTheCommie: hm, nice connection
airlied: TobiasTheCommie: yeah its on the list :0
airlied: TobiasTheCommie: not sure what could help, maybe dumps of registesr if it works on fglrx.
airlied: but its fairly down my list :)
airlied: zzzz.
TobiasTheCommie: airlied: it does work on fglrx, using that right now(would just like to go with opensource instead)
TobiasTheCommie: arekm: that looks... weird...
TobiasTheCommie: arekm: is it like that with x11, or only with xv?
TobiasTheCommie: noooo, not fairly down your list *sob*
TobiasTheCommie: dumps of registers, dumps of registers...
arekm: TobiasTheCommie: hm, didn't check with x11+tvout
TobiasTheCommie: i suspect it will work with x11(though that is just a bad workaround)
TobiasTheCommie: wait, it is only like that on the tv? not on the main screen?
arekm: will check at home
arekm: yes, only on tv
TobiasTheCommie: hm
TobiasTheCommie: weird
TobiasTheCommie: it kinda reminds me of some overlay problems i've heard of here and there.. but nothing definet..
TobiasTheCommie: i may just be pulling crap out my ass..
TobiasTheCommie: but try with x11
arekm: hm, I wonder if that tv "100Hz" technology could do something bad here
TobiasTheCommie: and opengl(2) for that matter...
TobiasTheCommie: no
TobiasTheCommie: 100hz is just how many times a second the display redraws, the problem you are seeing would not be caused by the TV redrawing more times(it just redraws an image twice instead of once(or a bit more or less depending on refresh rate from the gfx), no such artifacts would be generated)
TobiasTheCommie: imo
TobiasTheCommie: remember, crap, my ass..
TobiasTheCommie: but i am pretty sure on that one
arekm: TobiasTheCommie: ehem, on LCD tv?
TobiasTheCommie: yes
arekm: TobiasTheCommie: afaik 100Hz means calculating in tv intermediate frame and displaying these
arekm: so you get more frames displayed than frames that come in tv signal
TobiasTheCommie: i will admit, i don't have that much knowledge about lcd tv's, but i seriously doubt the refresh rate would cause the problem, it isn't generalized enough
TobiasTheCommie: yes, it redraws some of the frames
TobiasTheCommie: or rather, refreshes
arekm: so maybe it calculates intermediate frames wrongly
TobiasTheCommie: in that case, you would see a generalized flicker, not just certain areas being wrong
TobiasTheCommie: and it looks a bit to me like it is certain colours that are affected
arekm: I also got such problem on static pictures from my camera (when I connected camera via composite to tv)
otaylor: glisse: Hmm, not sure how much the fence system helps. Seems the main hurdle is just understanding when you have to flush and when you have to wait
arekm: but never saw this problem when watching tv
TobiasTheCommie: ok, that is weird
TobiasTheCommie: same port on the telly?
TobiasTheCommie: or same type
arekm: same port
arekm: but I've tried this on two tv. One modern LCD and one old 26" crt - same problem on both
TobiasTheCommie: makes it highly unlikely it is anything other than overlay
TobiasTheCommie: iirc there have been some problems with overlay, composite, etc, on multiple displays...
TobiasTheCommie: arekm: do you have damage enabled?
TobiasTheCommie: i would try x11, then afterwards disable composite, damage and render in the xorg, and see if that does anything with either x11 or xv
TobiasTheCommie: or opengl(2)
arekm: Will test. (composite explictly enabled here)
TobiasTheCommie: the crt, is that 100hz?
TobiasTheCommie: my crt tv is 100hz, and i've seen nothing like that(that i remember)
TobiasTheCommie: in any case, crap, my ass, and a girl is coming over and i'm naked, so.... gotta go put on some clothes now
arekm: lcd has "100Hz" thing. crt not sure, probably doesn't have 100Hz refresh
TobiasTheCommie: well, if you see it on crt(at all, even if it is 100hz) i feel pretty confident that you can rule out the telly in all ways...(though the camera thing is weird)
TobiasTheCommie: you aren't running compiz or something weird like that?
arekm: I've tried camera on lcd only, so don't know if this also visible on crt. radeon tv-out tested on both - crt and lcd
arekm: no, no compiz
arekm: pure kde 3.5
TobiasTheCommie: well, try the above, even if it is the wrong direction, it will help home in on the correct area...
glisse: otaylor: only userspace, user of the gpu can know when its necessary to flush or no, without such informations kernel have to assume the worst case ie flush after every command
glisse: well i am exegerating a bit but that's the idea
otaylor: glisse: Hmm, but can't you context switch to a different dri client after each submitted command buffer?
otaylor: glisse: So if the kernel flushes there it's fairly harmless (assuming that two flushes in a row are cheap, which I think they are)
otaylor: since the client would have to put a flush at the end of the command buffer anyways
glisse: otaylor: well i would prefer to not have client adding flush
glisse: in fact i may forbid userspace to write to flush register
glisse: note also that in ttm i don't have concept of lock and context like in current radeon
otaylor: glisse: You don't think it's ever necessary to flush within the internal logic of a single command stream?
otaylor: glisse: what about, say, render-to-texture?
glisse: i would need to reread some doc to be sure but "flush" well stall will happen anytime you write to unpipelined register
glisse: otaylor: fence are typical use case of render to texture you flag your dest buffer with a write flush
glisse: next command you send you use the previously rendered texture with a read flag
otaylor: glisse: So you break up the command buffer at points where when you need synchronizatin?
glisse: drm then know that you need to flush
glisse: otaylor: well the tricky part is their, i need to look a bit a coherency
glisse: i think i won't allow to flag buffer with read|write
otaylor: glisse: certainly would be nice if the docs went into that some more, it's hard to get a good sense of the hw model
glisse: well that's doesn't work for 2d, that is why i need to put more thought in all that
glisse: otaylor: my understanding is that as long as you don't change too much the context ie renderbuffer address & texture address you will have cache coherency btw read & write
glisse: but if you reprogram the engine you loose this coherency and you have to flush so that end result is in memory
otaylor: glisse: Trying to have read/write coherency between texture reads and color buffer writes seems like it would cause a lot of difficulty to implement efficiently
MrCooper: glisse: the 3D engine seems quite sensitive wrt flushes though; e.g. even just moving the flush from RadeonCompositeTile to RadeonDoneComposite locks up here
glisse: otaylor: yup its a lot of trouble, but some register are touchy like wait_until and i wouldn't want to allow userspace to directly use them
otaylor: glisse: do you consider the X server userspace in this context?
glisse: MrCooper: i think the problem here is in the event engine which fails to see idle when a flush is happening
glisse: otaylor: yes X server is userspace :)
glisse: MrCooper: i am pretty sure that if you don't wait for idle directly after a flush you should be fine
otaylor: glisse: hmm, would put strong pressure to get rid of 2D engine use, I think, then. Which might well be a good thing.
glisse: otaylor: we don't have 2d one r700 so we better get ready :)
glisse: s/one/on
MrCooper: glisse: I don't think that change makes any difference wrt this
otaylor: glisse: waiting for idle directly after flush is done all over the X server and seems fine. What seems to lock is waiting for idle *without* a flush
otaylor: glisse: or perhaps submitting an indirect buffer without a flush at the end
glisse: all this flush/wait is nightmare :) i will talk about it at xdc with example
glisse: otaylor: okay looked to my lockup cmd stream and this is the other way around you need to flush & reset some part of the engine before wait to avoid lockup
glisse: i keep forgeting this things
glisse: so this is why i don't think we should allow userspace to flush & wait
glisse: would be easier to add proper flushing & wait when fence are triggered than doing a complexe cmd stream analyzer to check if userspace is doing a proper flush before a proper wait
otaylor: glisse: it;s actually possible that a flush isn't necessary ... if you look at section 9.2.3 of the docs, it says "All 3D operations need to be terminated with a register write to the SC, US or some down stream register. Unless
otaylor: this is done, the SC/RS will never assert idle (which will be reflected as GA_BUSY). The final polygon rendered should still drain out of the pipe."
otaylor: glisse: But if you can wait infrequently enough, then trying to do something other than a flush isn't a big win
glisse: otaylor: this is for fragment program, vertex unit have others issue too
otaylor: glisse: Well, you can't prevent locking up the card, really. The command buffer could have an pseudo-infinite fragment programs, etc in it
otaylor: glisse: So there is no security advantage to restriction, though there may be robustness advantages
glisse: otaylor: if you don't allow wait from userspace then you can kill such program
glisse: otaylor: also from r5xx recovering gpu lockup is possible & shouldn't be too hard
glisse: and yes this isn't about security but about robustness
glisse: having gpu lockup suck a lot
otaylor: well, as long as we can still make things go fast :-)
glisse: any solution that might lead to give easy way to userspace to lockup gpu is a no go for me
glisse: otaylor: also i am waiting for amd some feedback on lockup and things they do about it
bigon: mmm great X crashes when switching to a different workspace when firefox is running with a flash video in it
bigon: with that backtrace http://paste.debian.net/767/ could it be the radeon driver?
MrCooper: looks rather like XAA, but a real backtrace from gdb would be more useful
bigon: how can a manage to run X in gdb?
MrCooper: you can attach gdb to the running X
MrCooper: BTW IIRC there already is a bug report about something like this
bigon: oh right
bigon: yeah I think it's mine, but I was not sure if I filled it afterall
bdkbdkbdk: I just got a Radeon HD 3650 card. Is it usable with the radeon driver? I tried 6.8.0-r1 and didn't work. In Xorg.0.log, it wrote a list of devices that it recognizes, but the 3650 wasn't one of them. Do I have to try radeonhd or fglrx?
Magnade: if you want accerlation of any kind you prob need to use fglrx
bdkbdkbdk: I'm not so interested in acceleration, but I'd like to run tvtime, and it wants DRI.
Magnade: you prob will want to go use fglrx for now then
orkid: there is a problem with the latest radeon drivers. when i surf in firefox, images sometimes are blacked out, viewing them (right click and view image), and unscaling them (original size) fixes the problem
orkid: i've seen this on my laptop, and thought it was only the laptop's card having problems.
orkid: i see this now both on the laptop (M7500), and on desktop (X800XT)
orkid: sometimes portions of the iamge will show
orkid: somtimes the full image,
orkid: sometimes all black
bdkbdkbdk: Thanks. I'll try it.
jakespeed: anybody know how how to fix ati blank screen on reboot problem
orkid: try power off ?
jakespeed: whats
jakespeed: anybody know how how to fix ati blank screen on reboot problem
jakespeed: anybody know how how to fix ati blank screen on reboot problem
jakespeed: ati blnks scren fix
arekm: ATI Technologies Inc Radeon Xpress 1250 - which driver handles this thing?
jakespeed: blank screen on reboot
Magnade: arekm: radeon driver should
arekm: Magnade: greping over source tells nothing about 4 digit xpress being suported
airlied: arekm: its an rs690
airlied: arekm: man radeon
libv: aren't the xpresses the intel ones and therefor rs600?
libv: with x1250 being the amd ones and rs690
libv: there was some subtle difference in the marketing
airlied: libv: the rs600 are fairly scarce both are called xperss.. just different numbers.
airlied: libv: but yeah GPU marketing naming leaves a lot to be desired.
Magnade: same could be said for cpus i think
arekm: airlied: hm, radeonhd source has it as RS600 : Radeon Xpress 1200 (M), M is mobility?
airlied: arekm: yup there are desktop and mobiles.
arekm: and IGP means integrated ?
airlied: arekm: yes..
arekm: airlied: blank screen after starting X, http://pld.pastebin.com/f4ff0ccc4 after patching with http://carme.pld-linux.org/~arekm/ati-x1250.patch
airlied: arekm: is that a laptop?
arekm: airlied: yes, samsung r20
airlied: arekm: what's the panel native resolution?
airlied: oh I see it now.
airlied: arekm: the BIOS appears to have a buggy i2c entry for LVDS..
airlied: I wonder if the monitor has DDC>
arekm: I guess it's 1280 x 800 according to specs (don't have it here)
airlied: agd5f: any ideas?
airlied: arekm: the patch looks correct.
airlied: arekm: not sure we've tested too much on rs690 laptop
agd5f: log looks ok.
agd5f: arekm: does VGA work?
agd5f: try restarting the xserver
PSYCHO___: little question. what does mean this: libGL warning: 3D driver claims to not support visual 0x7e
arekm: agd5f: no output on vga after just connecting monitor
agd5f: arekm: is the monitor connected when the xserver was started?
arekm: glen_ is the owner of that samsung
glen_: yes i own it right now, but not daily :)
glen_: booting with vga connected i saw console picture on vga.
glen_: kdm startup with radeon driver made both blank
glen_: with radeonhd 1.2.1 no screens found, should i install radeon driver too?
glen_: agd5f, this is with the radeon_drv.so arekm gave me with vga connected: http://pld.pastebin.com/f46430fbf before X startup the picture was only on VGA, after startup both vga and laptop displays are blank. and they don't restore even when killing X
glen_: and X server is dead, xrandr doesn't answer me when i tried to list display interfaces
agd5f: glen_: can you send me your bios?
glen_: please tell me how
glen_: biosdecode from dmidecode package?
agd5f: glen_: cd /sys/bus/pci/devices/
glen_: agd5f, http://glen.alkohol.ee/pld/rs600.rom.gz
agd5f: glen_: thanks!
glen_: no the pleasure is mine (if i get it working) :)
mattmatteh: agd5f, did you get my last post ?
agd5f: mattmatteh: when did post it?
mattmatteh: ill post again
mattmatteh: agd5f, yes i gave, i bought a calibration dvd and used the grey scales. even compared with x11 which seems to show dark black right. i can not get smooth or even gradients of black
agd5f: mattmatteh: ok
mattmatteh: agd5f, any more suggestions ? i was going to look at the xv source when i had some time
agd5f: mattmatteh: did you adjust the XV_GAMMA attributes?
mattmatteh: agd5f, yes i did
mattmatteh: agd5f, i didnt have anything to calibrate that with
mattmatteh: agd5f, i did try some other values but dont recall it fixing the problem
mattmatteh: i can try again
agd5f: ok
agd5f: I'm not sure of what else to try
mattmatteh: agd5f fglrx has some of the color problems, but less and different
mattmatteh: less where i dont notice in dvd's that i have tested with
agd5f: fglrx may use textured video
mattmatteh: ohh
mattmatteh: hmm
mattmatteh: is there a cpu usages difference with overlay and textured ?
agd5f: you could try that too, but you'd need to upgrade to the latest driver
mattmatteh: i think i did that already when i first asked about my problem
agd5f: probably a bit more CPU with textured video
mattmatteh: now with xv i use 40 % on my pentium3 799 Mhz
mattmatteh: gl works, but uses 99 % cpu
agd5f: mattmatteh: it's not the same as the gl output in some video apps
mattmatteh: and x11 hogs alot since i need to zoom
agd5f: it shows up as an Xv adapter just like the overlay
mattmatteh: i was wondering if it would be more than 40 that xv uses
agd5f: mattmatteh: it is Xv
agd5f: just handled by different part of the hardware
mattmatteh: agd5f, how can i verify that i am using radeon ?
agd5f: cpu is probably a bit more than the overlay, but less than sw
agd5f: mattmatteh: xvinfo or check your xorg log
mattmatteh: yup
mattmatteh: its radeon
mattmatteh: well, since fglrx was loaded first, the dark colors look like what they were for fglrx
moondrake: mattmatteh: to see if the problem happens also with text. video, play with mplayer -vo xv:port=xxx vid.avi, where xxx is the port base number given by xvinfo under the texture adapter.
otaylor: airlied: This is crazy, I can get the per-glyph command stream down (via hacks) to vtx_count=6, 6 vertices, repeat, and there is still an enormous per-glyph cost
agd5f: otaylor: the problem is the texture caches
otaylor: airlied: I can only imagine that there is some bug in the pixel or fragment shader code that is causing a reset or an enormous input area or who knows what
agd5f: I was talking to hw guys today
agd5f: the tex cach is not unified on r300, and using 1 tex per glyph is a loss.
otaylor: agd5f: Hmm, but this is drawing the same texture 1, 10, 20, or 50 times in a row
otaylor: agd5f: (with no setup in between)
agd5f: otaylor: re-using the same texture unit in flight causes a pipeline stall
agd5f: need to cycle through the texture units, and only invalidate teh tx cache when you gone through them all
agd5f: otaylor: also, if you are using multiple tx unit, we need to parition the tx cache on r3x
agd5f: TX_FORMAT1, bits 31:27
otaylor: agd5f: I certainly can see where changing the texture offset for a tx unit could cause a stall, but using the same unit to draw the same texture to a different location?
otaylor: (not that I disbelieve you, just trying to construct a mental model for how this works)
agd5f: the other issue is updating FS program, better th cache them and use US_CODE_OFFSET to select one from the prgram memory
otaylor: agd5f: Yeah, but hacking that out seems to not affect performance
agd5f: otaylor: hmmm