rainbyte: hi
ossman: agd5f, ping
agd5f: ossman: pong
ossman: agd5f, I'm trying to grok the r600 xv code, but it's a bit too different from the previous models
ossman: from what I can tell, it renders a rect without any type of scissoring?
agd5f: basic idea is the same, only csc is done via pixel shader
ossman: csc = color space conversion?
agd5f: it accumulates a a vertex buffer
agd5f: yes
agd5f: shouldn't need scissoring since you can render rects directly
agd5f: which is what it's doing
ossman: seems to be working. I haven't seen any diagonal tear
ossman: I am seeming something other that's very odd. Some parts of the output are only updated every other frame or so
ossman: anything you've seen?
agd5f: what do you mean?
ossman: basically I get a vertical tear (which is odd in itself). but the tear is not related to a race with the CRTC, like tears normally are
ossman: basically the screen gets divided into three parts. The leftmost and rightmost portion render properly. The middle one gets rendered only now and then
ossman: and when it isn't rendered properly it retains the old image
agd5f: I think I know what the problem is
ossman: I was hoping you might :)
agd5f: ossman: does this help? http://www.botchco.com/alex/xorg/sync_xv_before_sw.diff
ossman: let's see
ossman: agd5f, nope
ossman: no change
ossman: let's see... what was that command to get a screen shot?
agd5f: printscrn?
ossman: I'm remotely accessing this machine :)
ossman: there was some command line tool that someone here recommended back when I was messing with the bicubic shader
ossman: curses his bad memory
ossman: here we go. "scrot" :)
ossman: agd5f, http://homes.drzeus.cx/~drzeus/tear.png
ossman: there you see the effect
ossman: I don't know what the colored noise is about. that artefact hasn't been popping up until now
agd5f: weird
kcodyjr_: i do note the colored noise is about halfway down, and there is a s3offset = (srcPitch2 * (height >> 1)) + s2offset;
kcodyjr_: in that patch - sure that shouldn't be height << 1 ?
kcodyjr_: all i have to read is the patch, so 'STFU kevin' is a perfectly fair answer ;)
ossman: :=
ossman: :)
ossman: agd5f, removing that patch makes the color noise go away
agd5f: which patch? The one I just posted?
ossman: yes
ossman: I'll reapply it and see if things are consistent
agd5f: kcodyjr_: the uv planes are half the res of the Y plane
kcodyjr_: could you tell me what's the significance of the test, "id == FOURCC__YV12" ?
kcodyjr_: agd5f, shows what i know. ;)
agd5f: kcodyjr_: yv12 and i420 have the uv planes reversed
kcodyjr_: you even knew what made me ask that. pissah. ;) wondering why that test would make s2offset and s3offset want to trade places
ossman: agd5f, now I got the noise without your patch
ossman: things seems to be a bit random
kcodyjr_: wish i had radeon hardware in front of me guys, sorry...
ossman: I hope this isn't because of fried hardware. memory death tends to look a bit like this :/
ossman: agd5f, could this be a cache effect? you seemed to have some problems with those yesterday :)
kcodyjr_: ossman, wouldn't memory death not necessarily be in the same spot on the screen time after time?
ossman: if you don't have anything racing for memory allocation then things should end up in the same place in memory every time
kcodyjr_: so perhaps you could narrow that down by introducing -anything- that changes the timing?
ossman: the effect is only present for some sizes of the source buffer
kcodyjr_: it'd have to be a whole range of memory getting sensitive though; it's not like it
kcodyjr_: not like it's a row of discrete pixels
kcodyjr_: almost looks like that damned button glowy thing that windows likes to do
ossman: I think the line is just a single pixel high. in the screen shot it has been scaled
kcodyjr_: and the effect is isolated to the test area
kcodyjr_: screen res something other than 1360x768?
ossman: no, but the damage is in the source buffer. the hardware then scales it to the destination dimensions
kcodyjr_: ah ok. was gonna say, the screenshot itself is very clearly unscaled
ossman: I think its 320x240 scaled to 640x480
ossman: yeah, the screen shot is of what's on the screen
kcodyjr_: that shouldn't have such a visual effect then, unless some kind of AA or whatever is happening
kcodyjr_: 320x240 -> 640x480 is a precise 2x scaling, it should literally doublescan without any kind of fancy math... unless that's a hardware "feature"
ossman: it should be doing linear interpolation
agd5f: ossman: yeah, bad cache flush command :)
agd5f: patch on the way hold on
ossman: goodie
kcodyjr_: i'll stfu now. for now. ;)
ossman: ;)
agd5f: pushed
ossman: pulls
ossman: agd5f, yay!
ossman: that made the weird tear go away
ossman: but the colored noise is still there
agd5f: yeah, copy paste error
agd5f: I was only flushing 512 bytes of the Y texture
ossman: but the problem was so neatly arranged for each line
ossman: did I manage to precisely align the data to some cache size or something?
agd5f: could be
ossman: ok, on to the next issue then. vsyncing :)
ossman: where is the pixel shader being loaded?
ossman: I can't see anything obvious is the xv routine
agd5f: most of the shaders get pre-loaded in r600_exa.c
agd5f: since they live in vram
ossman: k. not the first place I'd look for a NV12 to RGB conversion routine though :)
agd5f: the composite shader gets loaded at runtime since it's variable at the moment
kcodyjr_: stored routines rock though ;)
ossman: agd5f, R600LoadShaders()?
agd5f: ossman: yes
ossman: I'll dig through that then
ossman: is there any documentation for the CRTC side of the chip? I guess I'll need that in order to trigger on vsync events
agd5f: ossman: for vline waiting, you'll have to use the IT_WAIT_REG_MEM packet 3 to poll the vline register
agd5f: ossman: http://www.x.org/docs/AMD/
kcodyjr_: agd5f, does that logically lead us to having a thread polling vline and firing off a signal when it sees the value it likes?
agd5f: kcodyjr_: the cp polls for us
agd5f: it stalls while it polls
ossman: agd5f, I only saw the ISA (which I guess describes how to write vertex and pixel shaders) and 3D docs
ossman: or is the CRTC stuff exactly like R500?
kcodyjr_: oh. hmm. is that stalling something we need to work around? or is that ok?
agd5f: ossman: same as r5xx, alsorv630 and m76 are r6xx chips
agd5f: and the display docs for those are there
ossman: ok. I'll give it a go then
agd5f: kcodyjr_: for our purposes it's ok, as we want to stall rendering until a certain event
agd5f: ossman: see cp_set_surface_sync() for how IT_WAIT_REG_MEM is used
kcodyjr_: ahh ok, so it'll look like; do what work we've got, wait for vblank, begin again
ossman: agd5f, ok, thanks
agd5f: wait for vline, just make sure the scan out is past where we want to be
agd5f: ossman: we have a programming guide which has better info, but it's still finishing up it's IP review
ossman: I have you until then ;)
agd5f: indeed :)
ossman: will that document give a general overview of the chip as well?
kcodyjr_: is it even possible for that to become nonblocking? assuming for a moment it would be desirable to do so, can vline be polled without blocking?
ossman: I get the impression that this chip is a lot more "CPU-like" than earlier chips
agd5f: yeah, pipeline flow, basic programming, cache flushing, packet info
kcodyjr_: that was my impression too. except for missing things like handling exceptions, it could almost support a microkernel...
nha: airlied: which git repositories do I need to look at to find your latest bufmgr work?
agd5f: nha: radeon_rewrite branch of his fdo repo
agd5f: mesa repo
nha: is there no drm part?
agd5f: er radeon-rewrite
agd5f: should work on pre-MM drm and MM drm
agd5f: nha: modesetting-gem or airlied kernel tree: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
agd5f: http://cgit.freedesktop.org/mesa/drm/log/?h=modesetting-gem
nha: ahhh, ty
agd5f: np
ossman: agd5f, hmm.. there are still users of WAIT_UNTIL in the r6xx code. is it just the VLINE stuff that no longer works?
agd5f: ossman: like I said, you have to use IT_WAIT_REG_MEM to poll the reg now
agd5f: wait_until only polls the engine noe
agd5f: *now
ossman: just trying to get the full picture :)
agd5f: IT_WAIT_REG_MEM lets the CP poll a reg or memory location
agd5f: you can poll for =,>,<, etc.
ossman: is it in the public docs?
agd5f: it will be in the programming guide
ossman: k. you don't seem to have uses defines in cp_set_surface_sync :)
agd5f: yeah, need to clean that up
ossman: hmm... I seem to recall that the VLINE stuff wasn't in the public docs either :)
ossman: feels he is working under the best of circumstances here
agd5f: for the first ordinal: [4] 0 = reg, 1 = mem, [2:0] function 000 = always, 001 = (<) ref val, 010 = (<=) ref val, 011 = (==), 100 = (!=), 101 = (>=), 110 = (>)
agd5f: ossman: it's the same regs as r5xx/rs690
ossman: agd5f, but for the r5xx we used WAIT_UNTIL so we didn't really get into which register stores the VLINE state
agd5f: next ordinals are addres_lo, address_hi, ref_val, mask, poll interval
agd5f: oh right
agd5f: ossman: D1MODE_VLINE_STATUS 0x653c bit 12 = D1MODE_VLINE_STAT
ossman: thanks
agd5f: np
ossman: now I think I should have everything, so I'll get to coding :)
agd5f: cool
nha: I had always hoped I would get around building an entire custom kernel *sigh*
ossman: agd5f, I spoke to soon :)
agd5f: ossman: no worries :)
ossman: should I use ereg() as a replacement for OUT_ACCEL_REG()?
agd5f: yes
ossman: I forgot we added the fancy reconfiguration of the VLINE boundaries each frame :)
agd5f: I haven't integrated the commadn submission stuff yet
agd5f: the r600 accel code pretty much ahndles it all by itself
ossman: is the plan to get all if it into the same code again?
agd5f: i haven't decided what the best plan is yet
ossman: I'll just put a special handler in r6xx_accel for now :)
agd5f: sounds good
agd5f: also for bicubic, you can set the filtering in tex samplers and then load the kernel into the TD_FILTER4 regs
ossman: k
agd5f: headers only list 2 , but there are actually 36 sequentially addressed
ossman: those are 3d and should be in r6xx_3d_registers I hope :)
agd5f: yeah, I think so
agd5f: yeah, they are.
rufsketch: hey all
rufsketch: does radeon driver support compositing for an x1200?
agd5f: rufsketch: yeah, should work with both radeon and radeonhd
agd5f: bbl
ossman: agd5f, what is the unit for the wait interval?
ossman: agd5f, you sure about that reg? it is always 0
rainbyte: hi
rufsketch: will radeon allow opengl acceleration on kde 4.2 with an x1200?
hifi: how is kde 4.2 related?
rufsketch: hifi: because it needs opengl acceleration to run smoothly
hifi: x1200 should be supported
rufsketch: hifi: and it disables all effects if it deems your card doesn't support them
rufsketch: all that's really required is 3D hardware acceleraton and compositing i think
rufsketch: but i wanted to know if anyone knew for sure that kde would support it
rufsketch: as it doesn't support the version i was using before
rufsketch: with xorg 1.4
rufsketch: k, i'll restart x and find out
hifi: X1200 is a RS690 chipset which is supported on current driver
hifi: I hate when people do that...
ossman: :)
EruditeHermit: lol
EruditeHermit: assume that it was a crash
EruditeHermit: or a wife
hifi: well, he was about to restart x so
EruditeHermit: oh
EruditeHermit: there you go
EruditeHermit: nothing malicious
hifi: but the timing!
EruditeHermit: unlucky
hifi: at least on this channel where restarting X is quite common people tend to quit IRC during explanation
EruditeHermit: they don't care for explanations =p
EruditeHermit: just want it to work
EruditeHermit: its a thankless task
EruditeHermit: =p
hifi: but then it ends up like this: "does card x work?" "yes, but" "ok thx, restart" *quit* "...you need current enough Mesa/DRM/Xorg" *join* "it doesn't work and it's your fault!"
hifi: waiting for rufsketch to return ;)
EruditeHermit: 3d btw is probably more to do with mesa
EruditeHermit: so far so godo
EruditeHermit: good*
EruditeHermit: =p
agd5f: ossman: should be. make sure you enable the vline stuff like we do for the other chips
ossman: agd5f, I did som INREG and printf debugging
agd5f: poll interval is in clks
ossman: and the reg is correct
ossman: but for some reason the triggering isn't happening as it should
ossman: is there anything else of value documented for the IT_WAIT_REG command?
agd5f: that's it
ossman: http://pastebin.ca/1330024
ossman: there's my routine
ossman: and I've determined that AVIVO_D1MODE_VLINE_STATUS toggles between 0x0001 and 0x1001
ossman: but it either locks up or does nothing depending on how I set the comparison operator
agd5f: ossman: that looks right
agd5f: bit 12 is that vline bit
ossman: and I can just stuff the register address in there like that?
agd5f: ossman: you need to shift the address
ossman: now you tell me ;)
agd5f: (AVIVO_D1MODE_VLINE_STATUS + radeon_crtc->crtc_offset) >> 2
ossman: tries again
ossman: agd5f, wee! it seems to be working
agd5f: excellent!
ossman: I'll fix up proper commits
ossman: agd5f, is there no check that we overflow the command buffer right now?
agd5f: correct
agd5f: like I said, it needs to be reworked
ossman: suspected as much. there is no rate limiting if I try to throw too much data at it
ossman: agd5f, http://git.infradead.org/users/drzeus/xf86-video-ati
ossman: darn... left some debugging crud in there
ossman: hang on
ossman: agd5f, ok, now you can use that repo :)
ossman: I got that color noise on a normal video now. so either my card is broken, or we have a bug somewhere :)
|chiz|_: I'm trying to get xf86-video-ati working on gentoo but I'm running into some trouble with dri check out, http://dpaste.com/117828/ line 722 would someone be able to help or point me to a page to make sure I have instealled it correctly
SL: probably incompatible xorg/mesa version?
kcodyjr_: why xf86-video-ati
Enverex: That's what some distros have the radeon driver in
kcodyjr_: oh i see
kcodyjr_: i run gentoo, and it was -radeon, i think
kcodyjr_: could be wrong
Enverex: No, it's ati on Gentoo
Enverex: ati is rage/ati/radeon and radeonhd is radeonhd. Not sure why they never split them
chithead: gentoo has split xf86-video-mach64 and xf86-video-r128
Enverex: Did they? Hrm
kcodyjr_: gentooism. anyway, you did point at the right problem line; you're missing r300_dri.so
|chiz|: the file is there
|chiz|: I'm thinking it's not a good version?
kcodyjr_: but compiled against the wrong version of something
kcodyjr_: _glapi_tls_Context missing symbol is the clue
kcodyjr_: is the right libGL.so active?
kcodyjr_: eselect opengl list
|chiz|: hmmm
|chiz|: I just fixed that but didn't restart x
|chiz|: let me try that out
|chiz|: yeah that fixed that :)
kcodyjr_: you're good then?
|chiz|: I guess so, I'd love to figure out how to make suspend work since it does work with fedora 10
|chiz|: I just have never had any luck with gentoo
kcodyjr_: i've had it working but it tends to break again
|chiz|: yeah it's possibly the only good thing about fglrx
kcodyjr_: what, that you can reliably suspend and then come -back- to nothing working right? ;)
|chiz|: no fglrx I can reliably suspend and come back to everything working
kcodyjr_: well, i have trouble getting fglrx to -boot- and come up to everything working
|chiz|: my cpu fan runs at full speed but it figures out what temp it really is after an hour or so
kcodyjr_: every time i restart X i have to go through it again, poking and prodding options, changing them back, for video playback to work for that session.
|chiz|: yuck, that sounds like a nightmare
kcodyjr_: hence my sudden desire to get involved with driver development.
chithead: |chiz|: you could try to start apcid before X
chithead: acpid*
|chiz|: chithead: what might that do?
chithead: |chiz|: it will make sure that the acpi thermal driver is loaded and silence the warning in line 39 of your pastebin
|chiz|: chithead: it has never actually been startecd
EruditeHermit: agd5f: did you ever figure out the random crashes with r300 mobility cards?
|chiz|: chithead: if I try to start it now I get the message ' can't open /proc/acpi/event: Device or resource busy'
EruditeHermit: agd5f: I think I know what part of the code might be causing them and I have another issue that may be related but I could use your opinion
agd5f: EruditeHermit: what random crashes?
EruditeHermit: agd5f: http://www.phoronix.com/forums/showthread.php?t=14424
agd5f: ossman: pushed! thanks
agd5f: EruditeHermit: I haven't been able to reproduce it
agd5f: EruditeHermit: where do you think the problem is?
EruditeHermit: in the render accel code
EruditeHermit: http://bugs.freedesktop.org/show_bug.cgi?id=19129
EruditeHermit: I have the same card as those complaining
EruditeHermit: Radeon mobility 9600 M10/11
agd5f: EruditeHermit: disabling renderaccel is a pretty big hammer
EruditeHermit: yeah
agd5f: disables use of hte 3d engine for render accel
agd5f: it's probably the same issue
EruditeHermit: I have another problem
EruditeHermit: which I can reproduce
EruditeHermit: that may be related
EruditeHermit: when I increase brightness
EruditeHermit: or decrease it
EruditeHermit: I am unable to input anything
EruditeHermit: or click on anything
EruditeHermit: I get 100% cpu usage
EruditeHermit: I have to do a VT switch
EruditeHermit: and I get a responsive desktop back
agd5f: EruditeHermit: apci issue
agd5f: acpi
EruditeHermit: is it purely acpi?
EruditeHermit: for example in gnome
EruditeHermit: when I click the applications menu
EruditeHermit: it gets highlighted
EruditeHermit: but doesn't draw the menu
EruditeHermit: and text input doesn't work
EruditeHermit: but I can move the mouse cursor
agd5f: EruditeHermit: brightness is done via acpi
agd5f: assuming you are talking about laptop panel
EruditeHermit: yes
EruditeHermit: but why does it cause X problems?
agd5f: acpi fiddles with ioports and such
EruditeHermit: I see
EruditeHermit: well
EruditeHermit: I hope the render accel info is helpful
EruditeHermit: is the render accel code a lot of code?
agd5f: yes. it's most of the useful accel code
EruditeHermit: =(
EruditeHermit: do you have an mobility 9600 machine?
agd5f: yeah
agd5f: thinkpad t41
EruditeHermit: well let me know if I can do anything to help resolve it
agd5f: will do
chithead: |chiz|: you can start apcid only if X is not running
EruditeHermit: thanks
|chiz|: oh ok
|chiz|: I thought that you could have compositing turned and run opengl applications with the open source drivers
|chiz|: if it is supposed to work maybe I need some options in my xorg.conf
|chiz|: movies don't work with compositing turned on either :(
|chiz|: is there some way to make this work?
osiris_: does r300 hw support npot textures?
RTFM_FTW: it supports NPOT through GL_[ARB,EXT]_texture_rectangle
RTFM_FTW: it doesn't support support the full range of WRAP, FILTER, ... modes or targets in the GL_ARB_texture_non_power_of_two specification
RTFM_FTW: REPEAT, MIRRORED_REPEAT or the various MIRROR_* modes for WRAP or mip-mapping aren't supported for example
agd5f: osiris_: yes, all radeons do
agd5f: but not all clamp modes as RTFM_FTW noted
agd5f: r6xx/r7xx support all the clmap modes as well
RTFM_FTW: basically as long as one stays within the confines of the RECT specification all of the generic NPOT stuff will be equally native
RTFM_FTW: so use *_texture_rectangle as a basis for support
RTFM_FTW: at last for non-D3D10 compliant HW
RTFM_FTW: err least
|chiz|: I was able to get movie playback working but still strange things happen when I try to lauch an opengl program :(
agd5f: |chiz|: Xv stalls the pipeline while redering video to avoid tearing
agd5f: disable it by closing the Xv app or adjusting the XV_VSYNC xv attribute with something like xvattr
ossman: minimising the app should be sufficient though
|chiz|: hmmm well video playback is living up to my expectations now I would just really like to see opengl apps work with compositing enabled
EruditeHermit: |chiz|: r600/700?
|chiz|: r500
agd5f: |chiz|: needs dri2
|chiz|: how do I make sure that is enabled?
EruditeHermit: it doesn't exist yet for radeon
EruditeHermit: well it might
EruditeHermit: but in very early development only
EruditeHermit: glisse was working on it
|chiz|: hmmmm ah
EruditeHermit: perhaps in a few months if we are lucky
|chiz|: ok
EruditeHermit: agd5f: does the r6xx-7xx stuff work with radeon too now?
EruditeHermit: I noticed that its also in the radeon section of xorg git
EruditeHermit: blah, net went down
EruditeHermit: crappy ISP having outages all the time
jim_ec2: comcast sux!
EruditeHermit: so does ATT
EruditeHermit: all ISPs are sucking these days
jim_ec2: I finally got my clearwire back
jim_ec2: it's actually more reliable than my cable
EruditeHermit: you have wimax?
jim_ec2: not yet :(
jim_ec2: I have a wimax nokia n810
EruditeHermit: unlucky
jim_ec2: clearwire has been doing cellular broadband service
EruditeHermit: the producy lifecycle for n810 was 5 months
EruditeHermit: lol
jim_ec2: it's nice, a fairly small modem with no drivers to deal with
jim_ec2: internet anywhere there is cell service
jim_ec2: lifecycle in development or expected life?
EruditeHermit: err
EruditeHermit: product life
EruditeHermit: I have an n800
jim_ec2: cool, is that running maemo?
osiris_: airlied, MostAwesomeDude: any idea why 3d app wouldn't refresh it's window if fp reads fragment.position.z?
EruditeHermit: jim_ec2: yes
EruditeHermit: its awesome, but I wish it had a faster browser
EruditeHermit: i mainly just use it for quick note taking and internet radio
jim_ec2: yeah I take notes/ssh and play mahjong
jim_ec2: I wish I could get konqueror running on it
adamk: rnoland, FYI, googleearth works here without LIBGL_ALWAYS_INDIRECT.
jim_ec2: mozilla browsers are so heavyweight
osiris_: anyone here with rs480 or rs690 hw?
osiris_: ...and using r300 dri driver
chithead: osiris_: I use rs740
osiris_: chithead: unfortunately you're no help for me. rs740 has vertex shaders and there's no 3d support for it in r300 driver.
chithead: iirc rs740 is a die shrink of rs690, nothing more
osiris_: chithead: I don't think so. IIRC it's r600 based
chithead: no, only rs780 is r600 based
osiris_: chithead: oh, good then :)
osiris_: could you run few tests for me?
chithead: unfortunately I don't have access to the machine until monday
osiris_: too bad:(
osiris_: glisse: how was the first day at fosdem?
osiris_: nha: ping
ossman: agd5f, still around?
rufsketch: hey all
rufsketch: when using the radeon driver and kde 4.2, i get some really strange rendering errors when shadows are enabled
rufsketch: with an x1200
rufsketch: is anyone else able to replicate this?
osiris_: rufsketch: you have desktop effects enabled, right?
rufsketch: osiris_: correct
osiris_: rufsketch: what backend are you using? opengl or xrender?
rufsketch: opengl of course
osiris_: rufsketch: do you know how that shadows are calculated?
osiris_: is it a fragment program?
rufsketch: osiris_: i think it's a plugin
rufsketch: osiris_: but i'm not 100% sure
osiris_: rufsketch: I know about few non tcl hw(i.e x1200, x200) related bugs so you're probably hitting one of them
rufsketch: osiris_: i don't know what non tcl hw means
osiris_: rufsketch: non tcl hw - hardware without tcl unit (no vertex shaders)
rufsketch: osiris_: but if it's a known bug, i guess i'll just wait
rufsketch: osiris_: that said, is 3d in wine not supported?
dodo1122: hi, i'd like to try the experimental 2d/3d support for r7xx gpu's, do i need anything else except for radoen driver from r6xx-r7xx-support branch, libdrm and mesa from git?
chithead: drm needs r6xx-r7xx-support branch too. also there is no 3d acceleration yet
dodo1122: chithead: ok, i'll try that
dodo1122: thanks
osiris_: rufsketch: I believe it depends on wine version. I remember I was able to play Painkiller game about a year ago on x1250, and I wanted to play some today but it just crashed
osiris_: rufsketch: ...warcraft3 works on current wine version on my x1250
osiris_: rufsketch: so it depends on the game and wine version
osiris_: rufsketch: but don't expect much. you probably won't be able to play any game on your x1200 because of too low fps
chithead: x1200 is not *that* slow
osiris_: chithead: with oss drivers it is
chithead: if you use dual-channel memory the performance is comparable to mid-range r300 cards
osiris_: chithead: I'd say that bigger problem here is lack of hw vertex shaders
osiris_: chithead: warcraft3 is unplayable here (about 5 - 10 fps)
chithead: osiris_: I think rs690 has vertex shaders. it is rv410 minus hardware tcl. only rs480 doesn't have them
osiris_: chithead: nope, rs690 doesn't have vertex shaders
MostAwesomeDude: chithead: HW TCL *is* vertex shaders.
chithead: ok, then I was misinformed from http://wiki.x.org/wiki/RadeonFeature
chithead: how comes r100 has hardware tcl but no vertex shaders? and rs690 the other way round?
osiris_: chithead: the page is correct, although little misleading. vertex shaders are supported on rs690 but only in software
MostAwesomeDude: chithead: That page is talking about programmable shaders, which were not present before the R300 series.
MostAwesomeDude: So there was HW TCL on the R100, but it wasn't programmable.
chithead: so if one were to do sw tcl on r100, then vertex shaders would be possible too? o_O
MostAwesomeDude: (R200 is special; it technically has programmable shaders, but they're so limited that it's laughable.)
MostAwesomeDude: chithead: Yes.
MostAwesomeDude: Slow, but yes.
MostAwesomeDude: However, it's much easier to just say "Nope, no shaders, just fixed-function TCL."
MostAwesomeDude: Mostly, the division is because all Radeons in the r300 families can have their HW TCL (including vert shaders) switched off, even if the TCL engine is physically present.
ossman: MostAwesomeDude, are you one of the people with inside access to docs? :)
MostAwesomeDude: ossman: Not to anything terribly special.
MostAwesomeDude: The r6xx docs are out.
ossman: is trying to get the filtering kernel on r6xx working, but not getting anywhere
ossman: not enough of them I'm afraid
MostAwesomeDude: Hm.
MostAwesomeDude: Well, unfortunately, no, I don't have any special docs. bridgman or agd5f might be more helpful.
ossman: they seem to have a life or something as they're not here :)
osiris_: damn. I'm hitting probably a race condition somewhere :/ shadowtex mesa demo doesn't work normally, but works when run under valgrind in most cases
bridgman_: I have no life. What's up ?
rufsketch: osiris_: i want to run a small 3D modelling program
MostAwesomeDude: XD
bridgman_: ahh... filter kernel, hold on
rufsketch: osiris_: but i haven't had too much luck getting it to run with fglrx drivers either. though at one point it actually was running fine with fglrx
osiris_: rufsketch: try with different wine version, maybe you'll get lucky
rufsketch: osiris_: I'll try. though when i reported the bug to wine, they said it was a driver issue
osiris_: rufsketch: could you post a screenshot of the corruption in shadow plugin?
rufsketch: osiris_: I get a black screen where the 3D workspace is, but the 2D toolbars show up fine
rufsketch: osiris_: sure can
osiris_: MostAwesomeDude: do you have any idea about the window-doesn't-refresh problem?
MostAwesomeDude: osiris_: I don't know what that is?
osiris_: MostAwesomeDude: when I'm running an 3d app (i.e. mesa fp/tri-depth) that reads fragment.position.depth the window shows the correct image for a fraction of second and then some garbage appears
osiris_: and window resizing, moving doesn't update the image
MostAwesomeDude: osiris_: Hm. Sounds like off-by-one in FP register allocation.
airlied: osiris_: sounds like something locked up.
airlied: is the app stuck somewhere?
bridgman_: osiris; sorry, we had a data center power upgrade today and I still can't VPN into the office systems; will try again later tnnight; I looked at the "672 pages of unreleased documentation" and that didn't help either, unfortunately ;(
osiris_: airlied: no, I it works ok. no cpu eating and I can cleanly close it
airlied: osiris_: gdb attach to it? stuck in some wierd place?
ossman: bridgman_, I've set the texture sampler to bicubic, and I'm stuffing values more or less at random into TD_FILTER
bridgman_: I think we need to dip into the hardware design docs, unless agd5f remembers from the last dip
ossman: I get lots of weird effects, but nothing I really understand :(
bridgman_: I'll try later tonight
bridgman_: s/osiris/ossman/ sorry, too little sleep
ossman: :)
airlied: nha: well if you don't want kms+mm you can test bufmgr legacy codepaths :)
osiris_: :)
MostAwesomeDude: airlied: Anything needed before we can port the r6xx code into the KMS+GEM tree?
rufsketch: osiris_: note that these corruptions stay on the window when using effects such as cover switch or present windows
rufsketch: http://img231.imageshack.us/img231/7884/corruptionfj4.png
airlied: MostAwesomeDude: kcodyjr already ported the legacy codepaths
rufsketch: and they move with the window as if they were a part of the window
airlied: MostAwesomeDude: however we have to write the MM stuff
airlied: and CS stuff
osiris_: airlied: nope, it just waits in glutMainLoop
MostAwesomeDude: Ah. Joy.
airlied: osiris_: wierd.
kcodyjr: airlied, MostAwesomeDude: i was planning to go home tomorrow and dig in to the CS, and some remaining OOPS problems
ossman: bridgman_, I'll be heading off to sleep in a bit. but if you or agd5f can find anything, please share and I'll continue tomorrow
MostAwesomeDude: airlied: Well, gonna try more r300 stuff. Gonna get SW TCL clear paths set up, and see if willing testers are experiencing the same lockups as me.
osiris_: airlied: yeap, and it happens only when 3d app reads frag.pos.depth in fp
bridgman_: ossman; will do
osiris_: rufsketch: I'm getting the same corruption
MostAwesomeDude: osiris_: Check out the frag.pos setup; IIRC we actually force frag.pos.depth to either 0 or 1.
King_InuYasha: gah
osiris_: MostAwesomeDude: nope, I have rewritten that code. sometimes the correct image stays in window until a repaint happens.
King_InuYasha: not even Secret Maryo Chronicles!?
King_InuYasha: the FOSS radeon driver craps out when I try to play that game
King_InuYasha: it worked once, reeeeaaally slowly
rufsketch: osiris_: so it seems like a driver bug ?
osiris_: rufsketch: yes. I'm working with that code now so I will try to fix the bug if I manage to find the cause
osiris_: airlied: any idea about the works only with valgrind problem?
airlied: osiris_: valgrind stops memory from being reused, however it usually tells you when things do that.
rufsketch: osiris_: awesome, thanks a lot
rufsketch: osiris_: do you need me to try and gather any info for you?
osiris_: rufsketch: nope, thanks for report
rufsketch: osiris_: thanks for working on it!
osiris_: airlied: is there a way to narrow down the problem?
airlied: osiris_: nothing springs to mind, isn't post pushed via texture coord?
airlied: maybe you are rasterising wrong textures or someat.
osiris_: airlied: yes it is now. it wasn't pushed at all in non tcl case
osiris_: airlied: moving the light source fixes the problem (the new texture is uploaded then) hmm, maybe the scene is beeing rasterized before we finish uploading the tex?
airlied: osiris_: or we upload the wrong one in some path or other.
osiris_: airlied: have you tried my fogcoord patches?
airlied: osiris_: left laptop in office... try on monday
osiris_: airlied: do you still have rs690 hw?
airlied: osiris_: yup I assume you had it working on that :)
osiris_: airlied: yeap, could you try mesa fp/tri-depth* on your rs690 to see if the window will "hang" as for me? (without my patches)
airlied: osiris_: with the mesa from F10 it hung the GPU :)
airlied: I need to try a later one
osiris_: airlied: oopsie :) btw. don't try demos/pointsblast on non tcl hw - it hangs my rs690
airlied: osiris_: rs690 with latest mesa also == hang
osiris_: airlied: try this patch http://pastebin.com/m4f9fc78c
nha: osiris_: pong?
osiris_: nha: take a look at: http://pastebin.com/md05307d
nha: airlied: actually, I *do* want kms+mm; if I have a little time to spare I would like to help get it into a shape where it can be merged into mainline
osiris_: nha: why there additional insts after native rewrite?
nha: let me check this...
nha: okay, this sequence is generated by the code that handles shadow textures
nha: if you know of a way to do shadow textures natively in the hardware texture samplers, we would not need this
nha: but as it stands, these instructions treat the value from the texture as a depth value that is to be compared to the texcoord.r value, and a corresponding output value is generated by the CMP
nha: STATE[0] contains the ambient shadow value
nha: the RCP is needed for perspective divide, and so on
osiris_: nha: so it's the texture type that causes new insts to be added?
nha: essentially yes
nha: the texture compare mode influences the exact code, to be precise
nha: the code that adds the sequence is in transform_TEX in r?00_fragprog.c
nha: see also the build_state function in the same file
RTFM_FTW: mmm use SET ops for the R comparison
osiris_: ok, thanks
airlied: osiris_: seems to reject against mesa master
RTFM_FTW: don't use CMP
RTFM_FTW: I assume this is R5xx?
osiris_: airlied: one moment, will pull and rebase
airlied: nha: any help on the 3D sitde would be great, I'm nearly finished radeon now.
nha: actually, I believe the log output suggests it's r3xx
osiris_: nha: yes, its r300
airlied: nha: even comments on how bad the merging is :)
airlied: I intend on splitting common_misc.c up a bit, and maybe renaming things back to radeon_
airlied: once I have all 3 drivers agreeing.
nha: I'll still have to get the lay of the land, and actually get things working
nha: is compiling a kernel from your drm-rawhide branch a good idea to get the kernel memory manager?
RTFM_FTW: ah I didn't bother looking at the paste... :P
nha: osiris_: re your patch, around lines 850: is there a particular reason you're disabling the pointsize attribute?
nha: I'm trying to wrap my head around the whole fog thing
osiris_: nha: so it doesn't hang the hw :)
MostAwesomeDude: nha: Have fun with fog. :c
osiris_: MostAwesomeDude: no fun with fog anymore:) it works (at least on non tcl hw )
airlied: nha: yes thats the best way
osiris_: airlied: http://pastebin.com/m7aadb13f
airlied: osiris_: okay no hang, just screwd up delayed rendering
airlied: osiris_: it renders fine, moving the window bad, but thats all the fp tests
mattst88: airlied, not at FOSDEM?
airlied: mattst88: not from .au too far :)
mattst88: yes, I can imagine travel time would make it a hard to justify.
osiris_: airlied: yeap, you're right. I've never run other fp tests :P
airlied: mattst88: that any 5 wk old baby :)
airlied: ^any^and
mattst88: oh right, I meant to congratulate you :)
airlied: osiris_: do you think that patch can make TCL fog any worse?
mattst88: airlied, given the later comments in fdo bug 16549, where would you guess the bug is? I haven't been able to find a working version.
MostAwesomeDude: mattst88: We're just watching FOSDEM from afar. :3
mattst88: the bug appears to be present with r128 cards as well, so it is probably more general than the title says.
osiris_: airlied: tcl fog? you mean depth based fog?
airlied: mattst88: sounds like the alpha DRM_CAS is broken,
mattst88: MostAwesomeDude, and waiting for Phoronix to post the videos :)
airlied: you could try falling back to generic code.
airlied: disable the alpha drm cas code in libdrm so it always goes into the kernel
mattst88: airlied, OK, I'll try that./
airlied: osiris_: no just the effects of that patch on the TCL codepaths
airlied: I'd be inclined to push it to master :)
airlied: and I'll test it next week hopefully
osiris_: airlied: when a driver exposes EXT_fog_coords all fog (depth based and fog coord based) is done with shaders. so there's no tcl codepath in that case
osiris_: airlied: no, please don't push it yet. there are few leftovers, and I don't know if I haven't screwed up r500
airlied: hehe. okay I'll test it on r500 next week then
airlied: I don't have an r500 in my remote rack.
osiris_: airlied: oh man. I need some sleep, because I've just understood what you were asking about :P
osiris_: airlied: it's possible that tcl path got screwed, because I don't know this path that much
osiris_: airlied: and I don't have any hw to test it on
spstarr: fog.
osiris_: airlied: there're only two places where my patch could screw tcl path: vertex buffer setup and vertex program outputs setup
EruditeHermit: what does for(;;) do?
EruditeHermit: how long does that go for?
chithead: EruditeHermit: #friendly-coders may be a better place to ask
EruditeHermit: what is radeon_accel.c primarily for?
bridgman: ossman; good news is that I found hardware docco describing how the texture units work and how the weights programmed into the registers fit into the overall texture filtering pipe
bridgman: the bad news is that there seems to be an assumption that the weights have already been fairly heavily processed before loading, and there seems to be an inconsistency between the description of how the weights are stored/used and the bitfields for the registers
bridgman: it's also not clear why we have two register defns for 6xx/7xx but only one register for filter4 on 5xx, which AFAICS does more or less the same thing but in a more limited way
bridgman: unless agd5f has a revelation I think I'm going to have to speak with someone who knows the hardware inside-out, or at least poke through our source code and see what we program into the registers
bridgman: realistically that means Monday at the earliest
bridgman: that said, you probably have bitmaps sitting around for an unprocessed image and a bicubic-filtered image, and the GPU is fast enough that you could probably just write a program to stuff random numbers into the weights and pick the resulting image which looked most like your known good bicubic output
bridgman: as usual, I'm mostly joking, but...
bridgman: my guess is that bits 22-27 in the first register should be ignored; on 5xx you had 2 1-bit fields plus a 4-bit field with values from 0-8 for a total of 36 valid combinations; in 6xx you have 36 registers, so it seems like you can address the registers directly instead of writing value+index in the same reg
bridgman: what I don't get is why we are writing 2 values per register (right+left or top+bottom) when the weight_pair field kinda indicates that only one of the two will be written
bridgman: anyways, we'll find out