airlied: settles in for afternoon read..
rx__: considers killing trees to print the acceleration guide
airlied: glisse: I assume you'll have r500 gallium driver writen during FOSDEM ;)
rx__: now that there's r5xx docs he has no excuse not to have it written right?
airlied: well opefully if he is a tfosdem he'll get drunk and write it.. :)
rx__: have the x talks started yet?
rx__: i'm not seeing any vids on the radeonhd.org site
airlied: not sure its like 9am now I suppose..
bigon: the opening talk begins in an hour
bgoglin: agd5f: by the way, the (still broken) log using http://www.botchco.com/alex/xorg/debian465864.diff is available at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465864
mcgreg: AMD Releases 3D Programming Documentation - wow
mcgreg: thanks all ppl who worked on this
mcgreg: you guys rock
mcgreg: airlied agd5f do I understand correctly that you both work at AMD and actually had access to those docs/informations for a long time already but couldnt use them due to you NDA/contract to AMD?
michaellarabel: rx__: The X talks don't start until 14:00 local time today. I am hoping to have each unedited video talk at RadeonHD.org within an hour of each talk ending (permitting net speed and any other issues).
airlied: mcgreg: no I work for red hat and I have had access to some of this info under NDA for about 3 years... mainly reg info..
mcgreg: oh then I messed up something :)
airlied: mcgreg: agd5f receently started working for AMD and he createed that document from various internal stuff
mcgreg: uh that must have been a lot of work for 1 or 2 persons
arekm: hiz mentioned in recent doc is the same as hyper z?
airlied: arekm: yup.. hierarchical z...
arekm: oh, so there is now a chance to see hiz in r300? ;-))
airlied: arekm: we already have it I thinlk
airlied: marcheu reverse engineered it years ag
glisse_: airlied: likely a stupid question hiZ RAM is some dedicated ram we don't have to alloc ?
airlied: speaking of z.. I'm gotta go get some..
airlied: glisse_: I think so..
airlied: glisse_: but not 1005 sure
airlied: 100% even.. bb tomorrow
glisse_: airlied: well that's my understanding too from quick read of doc i have
b0le: I have reinstalled entire system (upgraded kernel to 2.6.24) and reinstalled X, but I am still getting kernel panics - does this "[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner ffff81001cdf4ec0 ffff81001e8fda80" mean anything? (the *ERROR*'s starts in kernel logs once I start glxgears (with indirect rendering))
MrCooper: b0le: it means something is doing stuff that requires the DRM lock without holding it; might be interesting to get a backtrace from where that happens
b0le: MrCooper: gdb or kernel messages?
MrCooper: b0le: gdb
b0le: MrCooper: so, I need to step through in gdb untill I get the error, and then get a backtrace?
b0le: hmm what should I set as a break point?
b0le: I was going to try radeon_cp_reset, but that doesn't work (I assume because it is in drm not X)
b0le: MrCooper ^^^ ?
MrCooper: b0le: grep for RADEONCP_RESET() in xf86-video-ati
b0le: I got to go now, I'll try it again monday
b0le: thanks MrCooper for the help
desai: i'm using the radeon driver on a M56GL [Mobility FireGL V5250] (thinkpad, if it matters). it is r500 based. the driver seems to work fine, with one exception. whenever i close and reopen my laptop lid, the screen goes to this crazy-looking flashing ansi sort of screen. a change to vt1 and back fixes this corruption. this doesn't happen with radeonhd, fwiw. does anyone have any clue what might be causing this?
ajax: we're probably doing something with the acpi lid event that we shouldn't be.
desai: is there any info that would be helpful to nail down the problem?
desai: or is there a place to file a real bug report?
desai: cool, thanks
dli: the lid close/open issue is solved here :( because I enabled suspend2ram, so, the bug hidden now
ganymede: hello, i was wondering with the current radeon 3d drivers, do opengl and xv windows get composited properly? with proprietary drivers, the contents of such windows stick to the screen while their window decorations are transformed.
ganymede: (i can't test the current drm code in mesa because my card is an unsupported one)
MrCooper: ganymede: only DRI2 will fix that
MrCooper: for OpenGL that is, XVideo is unrelated
MrCooper: that just requires a textured video adaptor instead of an overlay based one
ganymede: MrCooper: but i guess somewhere along the line, Xvideo will cease to exist, and video will just be done with 3d parts?
MrCooper: maybe, but it can still be available via XVideo
ganymede: i'm not too familiar with video drivers, but is nvidia GL_ext_texture_from_pixmap is the reason it works with nvidia and not with plain AIGLX?
MrCooper: the traditional DRI drivers just have no means of knowing how to render to redirected windows correctly
ganymede: oh, and nvidia obviously doesn't use tradition DRI, so they can bypass that restriction
MrCooper: right, they have their own direct rendering infrastructure and GLX implementation
MrCooper: gotta run, bbl
damentz: agd5f: so what are you guys doing right now w/ the 3d docs?
agd5f: damentz: I'm not doing anything with them at the moment
damentz: "Among the areas covered in this 3D guide are the command processor, vertex shaders, fragment shaders, Hyper-Z, and the various 3D registers."
damentz: but i'm guessing, you'll just go back to what you've implemented and double check them against the docs?
damentz: i heard that hyper-z really boosts performance for 3d gaming and the like
agd5f: yeah, pretty much.
ajax: i'm grunting through adding the US registers to radeon_reg.h
ajax: unfortunately all my r500 kit is at work, so i won't be actually testing anything until at least monday
rx__: are you going to push an updated radeon_reg.h beforehand?
ajax: (translation for mortals: US is the "unified shader" block, the thing that implements fragment shaders, which would be what implements Render accel and the interesting bits of 3d)
ajax: rx__: of course.
rx__: great :)
rx__: is it just me or are there no vids to watch?
ajax: what an odd shader engine
ajax: although, probably the most straightforward thing in the world to execute.
agd5f: arggh. so much hate for gatos code
agd5f: it doesn't want to get along with textured video
ajax: RADEON_FALLBACK(("Junk driver\n"));
ajax: tee hee.
dmb: so is the radeon and the radeonhd driver going to be eventually merged?
Goga777: it's good idea :)
ajax: hmm. moderate amounts of overlap with the R300 US regs. i pay attention, really.
ajax: cute, R300 composite hook sets a bit in R300_US_CONFIG that's not documented in R500.
dmb: ajax: lol
PSYCHO___: is os driver capable of playing hddvd or blueray?
PSYCHO___: i came up to one today
PSYCHO___: and it is realy not working
PSYCHO___: aka slow as turtle should be correct
Magnade: PSYCHO___: playing hddvd or blueray requires a very quick computer since no video cards supported in linux can decode h264
agd5f: ajax: I can look stuff up if there are any discrepancies
Magnade: PSYCHO___: then you have the encryption issues
PSYCHO___: hmm might be so
PSYCHO___: cause i have 2ghz cpu :)
PSYCHO___: and i don't thing it is too slow
Magnade: this 1.8ghz comp i have has issues playing mpeg2 at blueray/hddvd resulotions
Magnade: h264 at that res is many times worse of course
PSYCHO___: well i have hddvd disc
PSYCHO___: not h264
Magnade: 720p plays ok as long as it doesnt have to deal with the deblocking code to much
PSYCHO___: and h264 is playable
PSYCHO___: bacause i have lots of doc movies in hd
Magnade: they basicly use h264 in the codec tho
PSYCHO___: but this is first time i deal with actual disk
Magnade: diffence is its higher resolution
PSYCHO___: now i tried it in vlc
PSYCHO___: and it died on sigsegv
PSYCHO___: i didn't press enter again...
PSYCHO___: it does not resize
PSYCHO___: so problem is there :)
Magnade: if you tried mplayer make sure to run latest svn
PSYCHO___: it's kinda new
PSYCHO___: i guess
PSYCHO___: ffmpeg is 3 days older
Magnade: should be plenty new
osiris_: agd5f: current radeon still doesn't find my monitor on hdmi port, and I have to force it :(
agd5f: osiris_: using latest git? got a log?
agd5f: osiris_: what board?
osiris_: agd5f: latest git, board is Gigabyte GA-MA69G-S3H.
osiris_: agd5f: log is at http://ns351745.ovh.net/Xorg.0.log
osiris_: agd5f: could you create a patch that disables those CailRead/Write debug messages? they are really annoying
agd5f: osiris_: can you send me your rom?
osiris_: agd5f: yes if tell me how to get it
agd5f: osiris_: cd /sys/bus/pci/devices/
osiris_: agd5f: http://ns351745.ovh.net/rom.dump
agd5f: osiris_: does this help? http://www.botchco.com/alex/xorg/osiris.diff
osiris_: agd5f: no change
osiris_: agd5f: maybe it's important: I'm using HDMI->DVI converter supplied with motherboard
agd5f: that should be fine
agd5f: osiris_: revert the patch I sent you
agd5f: osiris_: radeon_atombios.c line 1765, change 3 to 2 and try again
osiris_: agd5f: it works!
agd5f: osiris_: cool!
agd5f: I'll commit a proper fix
osiris_: agd5f: does this affect all rs690 based boards?
agd5f: osiris_: they all seem to use one higher than the table would suggest
agd5f: one entry higher
agd5f: argh. doesn't seem to be any logic to it.
agd5f: actually I htink I figured it out
osiris_: agd5f: so what is it?
agd5f: if it has 2 DFP ports, it uses 3, otherwise 2
osiris_: agd5f: woot!! that patch fixed two other problems.
osiris_: first: I can now use 1440x900@75hz and motherboard doesn't generate that high freq very annoying noise.
osiris_: second: screen doesn't "jump" anymore. it did before, it was moving randomly for about 1/10 sec from time to time (sometimes very often - few times per 10 sec, sometimes once a 20 minutes)
agd5f: osiris_: fix pushed :)
osiris_: agd5f: great!
osiris_: agd5f: is this a problem if xrandr says that certain mode has 70.6kHz/75Hz and monitor's osd reports 70.5kHz/74.8Hz?
agd5f: osiris_: slight variances in the clock
agd5f: it's fine
osiris_: agd5f: there is only one problem left with rs690 on radeon ddx. it's VT switching
agd5f: osiris_: yeah, it's scaler related
agd5f: I think
rx__: that sounds familiar ;)
osiris_: agd5f: what does this scaler do?
agd5f: osiris_: scales non-native modes to the size of the panel
rx__: are scaler regs different between r500 and rs690?
osiris_: agd5f: to me it looks like some regs aren't restored during vt switch, but IANAE
agd5f: osiris_: yeah pretty much
agd5f: the DDIA regs aren't either for that matter
agd5f: so it could be twofold in your case
osiris_: agd5f: and it should be pretty easy to find them, because switching to different resolution when back from terminal restores the display
agd5f: osiris_: DDIA regs are 0x7200-0x7290 IIRC
agd5f: I don't remember the scaler regs off hand
rx__: if it's anything similar to the problem i had w/r500 then it's this reg #define AVIVO_D1SCL_SCALER_TAP_CONTROL 0x6594
agd5f: rx__: yeah, it's the same they are all in the 0x65xx-ish range
rx__: must be another reg then :)
agd5f: rx__: well there are a ton of scaler regs
agd5f: we don't currently save/restore them all
osiris_: agd5f: why do we save bios and surface registers even for AVIVO cards when they are restored only for !AVIVO cards?
agd5f: osiris_: the bios scratch regs are used on all cards and the surface regs are used by r5xx at lease
agd5f: possibly a typo
agd5f: radeon textured video pushed
osiris_: agd5f: that was quick :)
agd5f: osiris_: I've been working on it for a week or so already
Tigerchen: agdf: including r500?
rx__: when you say radeon you mean legacy
agd5f: rx__: yeah, but r5xx will be coming soon
GhePeU: hi. what exactly is textured video? I'm fairly up to date with exa, dri2, ttm, etc., but it's the first time I hear of textured video
airlied: GhePeU: Xv using textures instead of overlay
airlied: GhePeU: its composite friendly
GhePeU: ah, ok.
GhePeU: does it require specific work by the player or does it replace xv with the same interface?
airlied: its just provides another xv adaptor
agd5f: GhePeU: shows up as an Xv interface
Xoipos: Too bad I can't try it out, I'm not at home. Hehe.
airlied: so the player needs to be able to choose adaptors
agd5f: GhePeU: it also provides 16 ports
GhePeU: I was googling for textured video and apparently with mplayer it is possible to choose the xv port
GhePeU: I'm going to try a git snapshot to check if it works here
GhePeU: the next release from git head will be 6.8.1?
loswillios: Adaptor #1: "Radeon Textured Video" port base: 74 :) on my RS400
damentz: whats kdrive?
damentz: i keep hearing about it?
loswillios: what's the benefit from it? lower CPU usage on video playback?
loswillios: damentz: a tiny X server
airlied: loswillios: it shouldn't work on rs4xx yet :)
airlied: loswillios: nope its composite friendly
airlied: loswillios: and it can work on r500 cards with no overlay..
damentz: loswillios: oh really
bgoglin: can textured video show up on multiple outputs at the same time?
damentz: airlied: holy crpa, that means i can get wobbly video playback now?
damentz: i'm using r300
loswillios: airlied: heh, ok. compiz freezes here anyway
airlied: damentz: in theory
airlied: bgoglin: yes
loswillios: but composite works quite ok
damentz: airlied: so do those 3d docs help?
airlied: damentz: well they contain info I didn't know before which is always usefull..
bgoglin: can we expect some sort of documentation for the default agpmode problems?
airlied: bgoglin: no something that is documented.
airlied: bgoglin: also no AMD's fault..
airlied: bgoglin: mostly problems with host bridges
damentz: airlied: i heard they were thinking of a linux hybrid driver
damentz: kind of like intel does in a way
bgoglin: but fglrx doesn't seem to have such problems
damentz: parts closed source and parts open source
damentz: i'm guesing they would use open source on the parts more sensitive to kernel changes
damentz: and then shader code would probably be closed
airlied: bgoglin: they may have a lot more workarounds, perhaps we can find out something from it later.
ajax: agd5f: would be interesting to know what bit 8 of R300_US_CONFIG is supposed to do.
agd5f: ajax: it's a perf counter field
ajax: seems like a strange thing to want to emit every time through PrepareComposite.
GhePeU: well, textured video works here
agd5f: ajax: probably a typo
GhePeU: but there's a problem with the border pixel
airlied: ajax: so US_CONFIG on r300 is different than on r500
agd5f: ajax: does it work ok without it? bits 4-23 are all perf counter controls
airlied: the first few bits are levels on r300 hw
ajax: agd5f: haven't tried, was just walking through the r300 Render code and comparing notes. the only bit in R500_US_CONFIG is to determine whether (nan or inf) * 0 gives you nan or 0 back.
airlied: that bit doesn't exist on r3xx..
ajax: airlied: right; the nan behaviour is dx9, the 0 behaviour is legal in dx8.
osiris_: when switching to terminal RADEONSaveScreen and RADEONLeaveVT are called, and when switching back RADEONEnterVT and then RADEONRestoreScreen, right?
GhePeU: apparently it depends on the port it's using
ajax: osiris_: that sounds right, yes. to be sure of the order i'd have to go trace the code, but i'd expect that's correct.
osiris_: ajax: the order is insignificant for me. I just want to know which functions get called, I'm tracing VT switch bug
bgoglin: agd5f: textured video seems to work fine in compiz. but in my metacity, it shows crap when the window crosses the screen boundaries
bgoglin: (on rv370)
agd5f: bgoglin: how big is your desktop?
bgoglin: current 1400 x 1050, maximum 2048 x 1152
GhePeU: I'm testing textured video too, and there's a problem with the border pixels, apparently depending on the xv port I'm forcing mplayer to use
osiris_: what about switching resolutions? RADEONSwitchMode? can't find there anything mode specific
GhePeU: on port 74 the pixel have an offset and they're green. on port 75 they're purple, on the whole superior edge and in a specific "random" pattern on the inferior edge
airlied: osiris_: mode switch comes from randr-1.2 codepaths..
airlied: osiris_: SwitchMode is for legacy mode switch and just calls the randr-1.2 stuff
agd5f: bgoglin: clipping bug on r300 I haven't sorted out yet
GhePeU: on port 76 they're purple with a "random" pattern on both edges, on port 77 green again, 78 purple with different patterns, 79 blue, etc. etc.
agd5f: GhePeU: what chip?
osiris_: airlied: so which function is the one where I find some reg writes?
GhePeU: RV370 5B63
GhePeU: a one pixel-wide line
agd5f: GhePeU: screenshot?
airlied: osiris_: depends on the card, atombios does mos tof it
agd5f: osiris_: for VT switch or mode set?
osiris_: mode set
airlied: osiris_: atombios does it
agd5f: osiris_: radeon_mode_set() and radeon_crtc_mode_set()
GhePeU: agd5f: can i send it via dcc?
agd5f: the first is for outputs the second is for crtcs
agd5f: GhePeU: I suppose
agd5f: osiris_: radeon_crtc_funcs and radeon_output_funcs hook the functions into randr
agd5f: osiris_: see xf86CrtcSetMode() in xf86Crtc.c in the xserver
ajax: agd5f: thanks for the typo catch
agd5f: ajax: np
agd5f: you spotted it :)
agd5f: I should go through and replace all the magic numbers in the r300 render code
osiris_: agd5f: I just want to find out which regs get written when setting mode to check if all regs gets restored during VT switch
agd5f: osiris_: all that Cail stuff is the regs
airlied: osiris_: not that easy, easier to just dump all regs before after and see which bits change
GhePeU: apparently I can't send it. it could be a problem here, the last time I used dcc I was connected via modem and now I'm behind a router
agd5f: GhePeU: imageshack or somesuch?
GhePeU: yes, uploading now
GhePeU: port 76: http://img522.imageshack.us/img522/2378/port76vc2.png
GhePeU: port 80: http://img292.imageshack.us/img292/2781/port80jv9.png
agd5f: GhePeU: not sure off hand
GhePeU: Apparently it works if I'm playing the movie in a window without scaling
agd5f: probably an issue with the scaling factor on the texture coordinates
agd5f: rounding error or something
GhePeU: yes, I suspected. I'm trying to check if there's a specific size after which the problem appears
GhePeU: well, it seems that there's no "trigger size", the bigger the window, the more evident the problem is
GhePeU: at 1:1 it's ok, then gradually the edge pixels get corrupted
agd5f: GhePeU: yeah, sounds like a rouding errors in the texture coordinates
GhePeU: that said, good work! cpu usage is low, i can't see clipping or other evident problems
agd5f: GhePeU: you can if you cover a full vertical segment of the video :)
agd5f: stride seems to go crazy when the width is clipped
GhePeU: do you mean if, for example, i place half the window out of the screen?
osiris_: agd5f: are scaler regs described in docs amd released?
rx__: a quick search says no
rx__: well.. actually i searched scaler
airlied: I think one of the regs doc has it in it..
rx__: airlied; actually i never knew where you found that tap scaler reg
rx__: when i reported it i didn't see it in any docs :/
airlied: rx__: radeonhd I think.. or maybe other secretz.
GhePeU: agd5f: you're right, with some video I can see clipping. It still beats x11, however
GhePeU: since it's almost 3 am here, it's past time to go to bed...
rx__: probably 'other secretz'
osiris_: hmm, I fixed VT switch, but then I broke mode set
osiris_: woot! I've made it!
osiris_: VT switching and mode setting works!
airlied: osiris_: nice one..
osiris_: hope I didn't broke it on other cards
osiris_: here is the patch: http://pastebin.ca/915875
osiris_: feedback is welcome
airlied: osiris_: hmm that might cause other systems to bust.. so its must be the memory controller stuff is wrong.
airlied: esp removing adjmemmap registers
airlied: okay so r500 rotate and textured video are now in the tree
airlied: I think rotate needs more work
dli: airlied, I thought we get X-Video also
airlied: dli: yes r500 xv now works..
airlied: thats what textured video is
dli: $ xvinfo
dli: X-Video Extension version 2.2
dli: screen #0
dli: no adaptors present
airlied: dli: you running git master from 5 mins ago?
airlied: dli: or you on rs690 or r600?
dli: airlied, r500, your commit was 22 mins ago
dli: airlied, I built and restarted X after that
airlied: dli: does your log say anything about Xv
osiris_: airlied: I checked couple of times, and I don't understand why there was AdjustMeMapRegister call. when we back to X from terminal we just have to restore previous fb and agp locations, right?
dli: (**) Extension "XVideo" is enabled
dli: (II) Loading extension XVideo
dli: (II) Loading extension XVideo-MotionCompensation
dli: (II) Loading extension XVideo
dli: (II) Loading extension XVideo-MotionCompensation
dli: (II) RADEON(0): Will try to use DMA for Xv image transfers
airlied: dli: so I get all that and it works fine for me..
airlied: xvinfo gives me textured adapter..
airlied: can you pastebin the log?
airlied: osiris_: that call is there for some reason that I'm unsure off, but the memmap stuff is very messy..
airlied: there are races between the drm and X and also when doing zaphod.
osiris_: airlied: drm is messing with fb and agp location only during init, isn't it?
airlied: osiris_: and resume
osiris_: airlied: and resume happens when entering vt?
airlied: osiris_: yes ususually after a suspend/resume cycle
osiris_: airlied: what zaphod has to do with memmap stuff
airlied: osiris_: actually new zaphod might be okay.. older stuff used to call a lot of codepaths twice..
airlied: gotta go shopping bbl.
osiris_: is going to sleep
dli: airlied, the Xorg log, missing Xv: http://paste.debian.net/49815
airlied: dli: I suspect something stupid in your conf file maybe
airlied: as I'm usgin the same GPU here for developing it on.
airlied: and it works here
airlied: time to hit pool....