MrCooper: agd5f: stalling the engine until scanout is outside of the active area is a pretty big hammer... only needs to be outside of the destination area of the operation
nha: osiris_: make sure you delete the stipple pattern on context destruction. Remember that the context might be destructed while line stippling is enabled
osiris_: nha: stipple pattern texture is allocated in gart memory, and all gart allocations are automatically freed when destroying context
glisse: osiris_: better being safe than sorry :)
osiris_: is there a way to do git pull using http protocol (my isp is blocking all ports execpt http,pop and smtp :( )?
glisse: osiris_: ouch that sucks
glisse: even ssh ?
glisse: how on earth isp could be so dumb ?
glisse: you can also use some free traffic rerouter you might find on the net
glisse: it's often slow though
osiris_: glisse: even ssh, but I reroute it through port 80 on server with ext ip. the same with irc, and now I'm out of ports :/
glisse: osiris_: well you could pull by ssh
arekm: setup openvpn tunnel (if you have some remote server with spare IP)
osiris_: arekm: goot idea, I will setup tunel with ssh - a lot easier
arekm: that would mean ssh+ppp, is it really easier? :)
osiris_: arekm: no, ssh -R or -L
arekm: that's just single port redirection and that sucks
osiris_: arekm: I know, but that's enough for me
osiris_: found even simpler solution. it's enough to change protocol type in git config :)
osiris_: found even simpler solution. it's enough to change protocol type in git config :)
osiris_: sorry, wrong window
osiris_: glisse: here's the patch that adds GL_ATI_separate_stencil ext to r300 driver: http://pastebin.com/m4bc95834
osiris_: glisse: I'm not sure about these conditions: if (ctx->Stencil._TestTwoSide || ctx->Extensions.ATI_separate_stencil)
osiris_: glisse: shouldn't ctx->Stencil._TestTwoSide be true when ATI_separate_stencil is used?
glisse: osiris_: not necessarily looking into mesa would tell you :)
glisse: ATI_seperate stencil have less capacity than the arb extension
osiris_: glisse: I looked into mesa, and _TestTwoSide isn't set when ATI_separate_stencil is used, but I think it should. anyway the patch works, tested with stencil_twoside mesa test
osiris_: glisse: also intel driver advertise GL_ATI_separate_stencil support, but in stencil functions checks only for _TestTwoSide, so I think it's a mesa bug
osiris_: needs mesa guru
glisse: osiris_: well it's not mesa bug
glisse: mesa might have decided that all driver supporting ati_separate also support arb one
glisse: in fact only ati hw don't fully support arb
glisse: though it's enough for doom3 stencil
osiris_: glisse: by arb one you mean GL_EXT_stencil_two_side?
agd5f: MrCooper: do you think there'd be a problem updating the crtc_trig registers on fly in the accel code? I'm not sure how quick those changes apply
agd5f: also waits on each blit seems kind of heavy as well
glisse: agd5f: i wanted to ask you if you tested your branch with a windowed 3d games
glisse: see how much it does slow dow the 3d game
osiris_: glisse: hmm, so what shoudl I do? is this patch correct? does ctx->Extensions.ATI_sepeate_stencil is true when driver advertises that extension or when that extension is enabled with glEnable?
glisse: osiris_: well grep for it in mesa
glisse: and look if mesa always set _TestTwoSide when glenableATI_sepeate_stencil is call
agd5f: glisse: not yet, but I suspect it would
glisse: agd5f: i think we should worry about tearing only in composited world ie in the easy case :)
glisse: and just accept old world to have tear
agd5f: glisse: yeah probably
marcheu: glisse: in which case vsyncing should be done by the composite manager anyway
glisse: marcheu: yup
agd5f: ideally we'd pageflip
glisse: agd5f: i am already fighting my wait against wait until :)
osiris_: agd5f: could you ask amd devs how to properly calculate value for GA_LINE_STIPPLE_CONFIG.STIPPLE_SCALE field based on stipple factor?
agd5f: osiris_: I'll see what I can find
osiris_: agd5f: thanks
legume: bgoglin: ping
bgoglin: legume: pong
legume: Hi about VT switching - I have a bit more info from X1600 HD3850 which may or may not help
gustaf1: agd5f: do you plan to merge the vsync_accel-branch into master?
legume: It works OK for me using radeonhd on both cards - maybe that means it's more like radeon bug than xserver.
bgoglin: legume: are you talking about my VT switching bug ?
legume: yes - been reading archives
bgoglin: legume: your board is veeeeery different and its support is very young, mine has worked very well for years and just broke when upgrading to Xserver 1.5, so...
bgoglin: unless you can reproduce the fact that removing the keyboard section removes the bug of course
legume: Ok - I never ran the RV530 on anything older - but whatever radeonhd does that radeon doesn't works.
legume: will try without KB section
bgoglin: if you're trying to say that radeonhd is better than radeon, it won't work with me :)
legume: LOL - no I wouldn't dare :-)
osiris_: glisse: ok, I think I know what's going on. look at:mesa/src/main/stencil.c line 518
osiris_: glisse: we check there is GL_EXT_separate_stencil is supported
adamk: Any thoughts on what might have changed in the r300 driver in the last few weeks that would break the fisheye magnify mode in ccsm?
osiris_: glisse: the problem arise when both EXT_stencil_two_side and ATI_separate_stencil are supported
osiris_: glisse: radeon advertises both (with my patch) extensions, and the condition is true, but ctx->Stencil.TestTwoSide is false because in my program I use ATI stencil functions
glisse: osiris_: then it means mesa don't enable twoside when ati is enabled
glisse: and that you first patch test was good
osiris_: glisse: changing the condition to: (ctx->Extensions.EXT_stencil_two_side && ! ctx->Extensions.ATI_separate_stencil) fixes it
legume: bgoglin: Removing keyboard section does not fix it for me
osiris_: glisse: nope, it's wrong fix. but the problem is recognized
agd5f: gustaf1: probably not, at least not in the current state, it's more of a proof of concept
legume: I'll guess I'll file a radeon bug - there are other differences aswell: Vesa first totally fixed it for X1600 but DRI stll worked OK.
gustaf1: agd5f: ok. I was thinking of trying it out, but I'm not good enough with git to know how to grab it ;)
legume: vesa first doesn't totally fix it for HD3850, though and HD3850 has slightly different symptoms from X1600.
agd5f: legume: yeah file a bug. vesafb/uvesafb vs vga console all seem to interact differently
MrCooper: agd5f, glisse: I think it would still be worth to use this technique for avoiding tearing with textured video in non-redirected windows though, as tearing is very annoying there
agd5f: gustaf1: git clone git://people.freedesktop.org/~agd5f/xf86-video-ati
glisse: MrCooper: yup for textured video it might be not that painfull
agd5f: git checkout -b vsync_accel origin/vsync_accel
agd5f: MrCooper: definitely
marcheu: MrCooper: we do that in nouveau, but it can be sensible to i/o. nothing beats a real flip IMO so we have to implement that :)
MrCooper: 'to i/o'?
marcheu: other i/o
marcheu: like, disk access
MrCooper: sensible how?
marcheu: like, it makes the movie lag
MrCooper: not sure how disk access can influence the GPU FIFO :)
marcheu: not sure either
MrCooper: I think 'sensible' is a false friend, btw :)
marcheu: yup, realized after I wrote it
gustaf1: agd5f: thanks!
marcheu: anyway, my point is that nothing beats a blit when it comes to smoothness
MrCooper: 'sensitive' is it I think
marcheu: right :)
marcheu: ahhh I miss all my sentences now
MrCooper: it's also "sensibel" in German though :)
marcheu: anyway, my point is that nothing beats a swap when it comes to smoothness
legume: agd5f: willl do
marcheu: MrCooper: btw I suspect EXA can make you miss your scheduled frame because of the previous blits that get piled up before your vsync + xv blit
MrCooper: heh, EXA usually gets blamed for not making the GPU hard enough, I guess it can't please everybody ;)
MrCooper: 'making the GPU work hard enough' even
marcheu: I'm a big advocate of Xv having its own fifo when the hardware permits :)
glisse: marcheu: tu as des gouts de luxueux voila tout ! ;)
nha: adamk: sounds like something that uses fragment programs, so it could be my changes
nha: now I don't know what this fisheye thing is, so more info would be appreciated
adamk: nha, It uses fragment programs, but beyond that I'm not sure.
adamk: nha, When were your changes? I'm trying to locate a good entry so I can start bisecting.
nha: pretty massive changes over the last two weeks or so
nha: I did make some changes before that as well
adamk: I've jumped back to a2e435054c0d410e92d1e76a23f8d801a606537d on July 9th. I'll keep going back.
adamk: Yeah, I see a lot of your commits now.
nha: with some bad luck, the bad commit is going to be something huge like e81ba58bf4c20229677cdf89b5970b55cefb2199; in that case, the best thing is probably to isolate the fragment program in question and use RADEON_DEBUG=pixels to check what's going on
adamk: trispd should show a very lovely multicolored triangle using fragments, right?
nha: using software Mesa, trispd renders rows of red and blue gradients
nha: (you are taling about progs/demos/trispd, right?)
adamk: Well it's not rendering anything here... onestone always has me check that when it looks like a plugins using fragment programs in compiz no longer works :-)
adamk: Yes, that's the one.
nha: wow, that's odd
nha: looking at the source, it only uses basic OpenGL functionality
MrCooper: adamk: is that on R5xx? the fisheye magnifier works here (though I prefer the image overlay one :) with a snapshot from this week
nha: adamk: considering how basic trispd is, I really don't understand why it wouldn't work. Does it work with compiz off?
adamk: MrCooper, Yeah, an x1300.
adamk: Very odd. I updates compiz this morning from git, with mesa from git this morning, and now going back earlier.
MrCooper: well, it could be an R5xx specific issue then
adamk: Sorry, I took it to mean that you were using r500 too :-)
adamk: Well I've found a good commit: 1f4d0748ba92ff2c44faadc31a99f07e1bea28fb
adamk: I'm bisecting now.
dmb: what exactly is tearing?
quicksilver: when you change the frame being displayed while the screen is half way through displaying it
quicksilver: so you get half an old frame and half a new one.
quicksilver: it's only visible if by bad luck it happens often/consistently/at certain points on the screen.
quicksilver: and there is lots of motion going on.
dmb: sometimes when i use a gl app, i see horizontal lines on the right of the screen of garbage, could that be because of tearing?
MrCooper: sounds rather like a memory bandwidth issue
dmb: MrCooper, so i should probably report a bug on that?
dmb: argh, i wish there was an easy way to switch between fglrx and the open source driver
bridgman2: they're called partitions, dude ;)
dmb: i suppose
bridgman2: seriously, I think we do want to make it easier
dmb: on my ubuntu machine, i have to replace mesa and dri for the open source driver
dmb: for fglrx, i have to revert the mesa and drm
bridgman2: fglrx is going through a period of rapid change, and it's not a good use of time to document the transient situation very much; once it finishes the transition I think this will get easier
dmb: is the july release going to come out soon?
bridgman2: I'm thinking we should toss out a simple "swap driver" script and hope it gets maintained
dmb: maybe one that renames the libgl libs or whatever
dmb: and can easily revert
adamk: Except that on some GPUs and chipsets, you have to reboot. Switching from fglrx to mesa, or vice versa, can lead to lockups if you don't.
bridgman2: this is what I don't get -- don't you *always* have to reboot if you are replacing kernel drivers ?
bridgman2: I don't think any of these drivers are written to be patched in on the fly and take over from the driver which was just deleted ;)
adamk: Well on one machine at work I can switch from mesa to fglrx by simply unloading radeon and drm and then switching to fglrx.
jcristau: modprobe -r iwl3945; modprobe ipw3945 works. but then that's not a gpu.
MrCooper: adamk: it's called luck :)
adamk: But it's certainly not guaranteed to work, and I wouldn't encourage people to think it will by creating a script that makes the switch for them.
adamk: MrCooper, Yeah, I know :-)
dmb: bridgman2, nah, you can usually safely remove and replace modules
dmb: not sure about gpu stuff
adamk: It's hard to make promises when it interchanging between a closed source driver and an open one since you can't really be sure what state the closed driver is leaving the hardware in.
bridgman2: Yep; in theory I guess the suspend/resume/vt switch code might handle it but I don't think there is any attempt to make it work across driver installs; drm guys would know better tho
adamk: Well my attempt to bisect mesa failed... It insists that some commit for checking for OpenBSD is the bad one.
algae: after updating xf86-video-ati from 6.6.3 to 6.8.0 I get a segfault when starting X. my xorg.conf may need updating, but is sig 11 expected?
Ori_B: no, you should never get a segfault.
jcristau: algae: are you using mergedfb or xinerama?
jcristau: so that's probably randr 1.2 and a xinerama config not working so well together
jcristau: should be fixed at some point, but..
algae: FWIW, 6.9.0 behaves exactly like 6.8.0 (in that regard)
agd5f: algae: zaphod is broken on xserver 1.3
agd5f: with the radeon driver
algae: agd5f: broken only with newer radeon drivers? 6.6.3 works for me.
agd5f: algae: it's a bug in the xserver
agd5f: zaphod support is implemented differently in thenewer drivers since it has to live with xrandr support
algae: agd5f: so updating to xorg-server 1.4.0 might fix it?
agd5f: algae: should
gentoofu: go with 1.4.2
algae: agd5f: okay, thanks, i'll try 1.4.2 and report back.
ssieb2: I found what appears to be a bug in the radeon driver and I'm wondering if it's already known
ssieb2: starting initially with a cloned screen on two monitors, I can unclone them and put them beside each other and everything is great
ssieb2: but if I logout and log back in with that setting already in place, there appears to be a hard border around half way across the right monitor
ssieb2: I can't move a window past that point, the mouse goes though
agd5f: ssieb2: sounds like a window manager thing
algae: my test with xorg-server 1.4.2 was inconclusive. i'll give it another try soonish, but for tonight i'm calling it a day. thanks everyone for the help!
ssieb2: agd5f: or xinerama? the same window manager on an nvidia card with the binary drivers works fine...
agd5f: ssieb2: sounds like the window manager isn't aware that the screen size changed
ssieb2: agd5f: sorry, I'm slow responding. I'm at work... It's just strange that it stops half way across the monitor. I can fix it by switching to clone mode and back again
ssieb2: oh, another thing. The X log says that it's setting the virtual size to 2560x1024, but it actually isn't. I have to edit the xorg.conf file to set it to that
ssieb2: I should add that I'm very impressed with the work being done on the radeon driver. It's great to see an update to the driver and find more things working and other things working better.
agd5f: ssieb2: what xserver are you using?
ssieb2: I'm using F9, I'll check
agd5f: ssieb2: weird. what does the virtual size get set to if you don't set it in the config?
|acm|: hi there
|acm|: I am having a little problem with the radeon driver. scrolling in a gnome-terminal is slow (also in firefox and thunderbird - high cpu load). I am using version 6.9.0 of xf86-video-ati. I have also build drm support in the 2.6.26 kernel for radeon. If necessary I could paste my xorg.conf. any hints on this issue?
|acm|: xf86-video-ati is also build with dri with "dri" use-flag on gentoo.
|acm|: and the important info could be that I am unsing a x1400 (rv515/m54).
|acm|: most important
MostAwesomeDude: |acm|: Hmm.
gentoofu: EXA or XAA?
MostAwesomeDude: Could you check in dmesg for any DRM errors?
MostAwesomeDude: Also could you check your AccelMethod in xorg.conf?
|acm|: gentoofu: EXA
|acm|: I cant see any errors, except "AIGLX error: Calling driver entry point failed, reverting to software rendering"
|acm|: and there is an info that r500 support is initial ...
MostAwesomeDude: |acm|: In dmesg?
|acm|: MostAwesomeDude: no errors ... "loading microcode r500, num pipes: 1 ..."
MostAwesomeDude: |acm|: Sounds about right.
MostAwesomeDude: I assume that Fx 2 is fine, and only Fx 3 is slow, right?
|acm|: MostAwesomeDude: I set up gentoo 2 hours ago and I am only using Fx3, so ...
MostAwesomeDude: |acm|: Ah. Well, sounds like everything using Cairo is slow, prolly 'cause our EXA/render hasn't been optimized much.
|acm|: MostAwesomeDude: In Fx it isn't slow, but has high cpu load
MostAwesomeDude: |acm|: Oh.
MostAwesomeDude: Well, if it's not slow, don't worry about it.
MostAwesomeDude: Mine uses CPU, too.
|acm|: MostAwesomeDude: but "less /var/log/Xorg.log.0" is slow!
MostAwesomeDude: |acm|: Hmm.
|acm|: at scrolling to the bottom
MostAwesomeDude: Turn off smooth scrolling in Fx to decrease the CPU load.
MostAwesomeDude: Maybe I'll look into some render stuff later. I've gotta go take my A+ test.
|acm|: good luck
gentoofu: that AIGLX error may be the problem...
|acm|: gentoofu: maybe ...
|acm|: but how to solve?
gentoofu: can you pastebin your Xorg.0.log?
|acm|: there is also a x11-drm package in portage. so is this newer than the drm in kernel?
gentoofu: there's actually a drm-fix due to PAT incompatibitility
|acm|: gentoofu: i've read about this patch on some mailinglists
gentoofu: what version of mesa, btw?
gentoofu: you also need xorg-server that's newer than 1.4.2
|acm|: gentoofu: just one where r500 isn't supported thought ... 7.0.3. in 7.0.4 and newer r500 seems to be supported. it's just a bit confusing for me, because I used fglrx before.
gentoofu: install mesa-7.1_rc3
|acm|: gentoofu: are you using that version?
gentoofu: i used to. i switched to using zen-overlay and x11 overlay
gentoofu: but yeah, you need the latest mesa, drm, and xorg-server to have that AIGLX working
|acm|: the latest fglrx driver supports aiglx without any "hard masked" versions right?
gentoofu: the fglrx has their own thing that's taken care of
gentoofu: the open-source stuff has to have their stuff in mesa and drm
|acm|: is there any paper where the relation between the kernel modules and drivers is described?
|acm|: okay, but they got it working after a long time ... :)
gentoofu: well,l the open source have only started very recently
|acm|: thats true
|acm|: thank you for that information (mesa, drm ...) gentoofu
gentoofu: no prob
gentoofu: dang, i can't find the page where it lists the packages to unmask
gentoofu: but emerge complaining about dependencies on the latest mesa and libdrm package should be sufficient :D
GerbilSoft: http://bugs.freedesktop.org/show_bug.cgi?id=16749 i think this might be the same bug as the white flicker in OpenOffice when using 3D transitions in Impress
|acm|: GerbilSoft: should the bug belong to the issue above?
|acm|: xrender mode ... what's that?
GerbilSoft: possibly, though OpenOffice uses GL rendering
GerbilSoft: xrender mode uses the X RENDER extension for fancy windowing effects
GerbilSoft: instead of OpenGL
|acm|: okay and xrender is an xorg-server module?
|acm|: or extension ...
hbock: can a CRTC clone to more than two outputs at a time?
airlied: hbock: yes
airlied: hbock: thast what clone mean
hbock: airlied: so, if it is reported that at crtc has 5 possible outputs as clones, it can drive all 5 simultaneously?
airlied: hbock: in theory yes, cloning is messy though, you have to have all outputs accept the same timings.
airlied: this isn't always possible usually where laptop panels are involved
hbock: okay, that makes sense
hbock: okay yeah, now i get it
hbock: RRSetCrtcConfig sets the same mode for all outputs in the list, so all outputs must be able to accept the same modes, including timings
hbock: same mode* that is
airlied: hbock: exactly.
hbock: thanks! that's a huge help.
hbock: it's incredibly annoying that X11 errors are sent to clients asynchronously
airlied: hbock: I think you can get them sync for testing..
hbock: oh cool, thanks airlied. i need to read the xlib programming manual...