ganymede: since there wasn't a mesa channel or gallium channel, does anyone know that status or feasibility of 1. ARGB GLX visuals and 2. full screen anti-aliasing like in the proprietary drivers? and 3. OpenCL?
airlied: terracon: got it, mostly works for me :)
joecool: felipec: this channel has the actual devs in here, not #ati
felipec: joecool: ah, right, this is the one I was looking for :)
joecool: alright pastebin your log first.. that should tell if something is seriously wrong
felipec: joecool: yes, but right now I'm in a version in the middle of a bisect, and with XAA
felipec: do you still want the log?
joecool: hrm, i suppose it's not gonna be as much of a help
joecool: it might be worth it though
felipec: joecool: http://pastie.org/338450
felipec: http://pastie.org/338451
felipec: (the conf)
joecool: hrm...
joecool: how old is this one i'm looking at
joecool: the driver i mean
felipec: it's 0e99017 (dec 11)
joecool: direct rendering doesn't show enabled, are you manually disabling it?
joecool: you on a T60 too?
felipec: I didn't disable it, yeah, T60
joecool: felipec: yeah it looks like the kernel module isn't working... did you get the git version of that as well?
felipec: joecool: nope, I'm using the one that comes in F10 (2.6.27.7)
joecool: if it's not too much to ask, do you think you can get the log with EXA enabled
felipec: of course, brb
felipec: joecool: that reminds me of another problem
felipec: EXA is unbelievably slow after reseting X
joecool: yeah that's not normal behavior
felipec: http://pastie.org/338461
felipec: joecool: yeah, it was working much better on F9
joecool: yeah you have issues, direct rendering is not enabled
joecool: there are a couple packages that need to be up to date, at or near git versions to get it all working
joecool: i'm not 100% sure as i'm running all-out git X
felipec: well, I'm using the latest packages of F10
joecool: i don't know if they are new enough.. hold on a sec
felipec: maybe I should try my own vanilla kernel
joecool: get the latest x11-drm
airlied: felipec: whats the original problem??
felipec: airlied: I have a lot of them, but the annoying ones are glitches and Xv stops working after restarting X
airlied: felipec: what card?
felipec: airlied: R520 (X1300)
airlied: AGP?
felipec: I guess so
joecool: no, it's pci-e
airlied: oh its PCIE.
joecool: it's a laptop card, mobility radeon in a lenovo T60
airlied: felipec: what kernel and -ati rpms you got installed?
felipec: airlied: kernel-2.6.27.7-134, xorg-x11-drv-ati-6.9.0-61
felipec: but right now I'm running latest git
airlied: latest git is a bad idea, unless you boot with nomodeset on Fedora
airlied: it might be worth trying -62 out of koji
felipec: airlied: where is that?
airlied: http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-ati/6.9.0/62.fc10/
felipec: airlied: thanks, restarting
joecool: btw, props on the tear-free stuff... it's working well
joecool: thanks
felipec: airlied: yeap, the glitches seem to be gone, and Xv still works after a restart :)
airlied: I must push -62 out.
felipec: airlied: so you are using a branch for Fedora?
airlied: felipec: modesetting isn't in master yet so if not using the F10 driver you need to turn modesetting off.
airlied: or build from my branch but then you just get whats in koji anyways.
joecool: felipec: he's a dev
felipec: joecool: yeah I know, I've seen his commits :)
felipec: airlied: where's your branch?
airlied: http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=radeon-gem-cs
felipec: joecool: airlied: thanks for the help
felipec: is it normal that X is using 50% of the cpu to render video with Xv?
airlied: I'm not sure, I'd have to profile it to see, but it probably is close enough.
airlied: its doing a lot of copying.
joecool: felipec: lemme check
joecool: felipec: it is using alot more then the old way... but it's at the cost of having decent playback i guess
joecool: i see about 30-40% usage for 720p content
felipec: joecool: decent playback? you mean the no tearing?
airlied: thats not in the Fedora package yet.
felipec: exactly
felipec: ah, now I'm seeing the glitches I was seeing in F9
felipec: the right part of the screens have some minor flickering
felipec: would disabling mode setting and using upstream improve Xv performance?
airlied: felipec: try disabling modesetting it might improve it.
spstarr_coding: craves for AGP :(
spstarr_coding: kms + PCI mode.. is.. beh
airlied: slow?
spstarr_coding: well, yeah
spstarr_coding: stable,but slow
terracon: hmm cravings
terracon: I crave fast stable open graphics stack
terracon: will these cravings be satisfied in the near distant future? dri 2 , etc
terracon: kernel-2.6.27.9-152.rc2.fc10.i686 xorg-x11-drv-ati-6.9.0-62.fc10.i386 kms disabled , currently stabl'ish
airlied: spstarr_coding: I don't supose booting with radeon.agpmode=1 radeon.gartsize=32 helps?
spstarr_coding: never tried gartsize opt
felipec: airlied: is the kernel option 'nomodeset' ?
spstarr_coding: airlied: I can try that in a moment
spstarr_coding: brb
airlied: no hurry.
airlied: felipec: yes.
felipec: hmm, I thought disabling that would make the console go back to the crappy VGA mode, I don't notice any change with nomodeset
airlied: the console should go back to the crappy mode and non-graphical boot
airlied: unless someone has a vga= line
spstarr: airlied: fail
spstarr: same thing
spstarr: corruption
felipec: airlied: ah, ok, typo
airlied: spstarr: ah well rules out gartsize hopefuly.
airlied: spstarr: this is all without composite?
adamk: Heh, did your AGP card ever arrive? :-)
airlied: adamk: yup got it, it works fine here.
spstarr: airlied: no comp on
airlied: slight issues but nothing as bad as others are seeing.
adamk: airlied, lol
adamk: Isnt' that always the way.
spstarr: airlied: this has to be GPU specific :/
terracon: how conveeeeeeeeeeeeenient. perhaps agp is ........ satan!
spstarr: otherwise, there's bugs in the GEM/TTM
spstarr: non kms, agp works fine
terracon: from the church lady/church chat snl
airlied: spstarr: it could be AGP bridge issues.
spstarr: but what does KMS do vs non-kms ?
airlied: spstarr: dynamic GART
spstarr: is it possible that you have to do something different wrt to dynamic GART on the mobiles?
airlied: chipset more liekly than gpu.
airlied: I think I can plug this card into my 865 chipset.
airlied: will do this week.
spstarr: ok, if it's the agp bridge we can get the erratas from Intel?
spstarr: 82855PM
spstarr: thats the Processor to AGP Controller
spstarr: I assume the bridge also
airlied: wonders if we have any of those laptops locall.y
terracon: so if I understand this correctly every agp bridge needs to be tweaked now. via, nforce, sis
airlied: terracon: they always did, we might just need more tweaks to use them dynamically.
terracon: I think I'll upgrade to a pcie system sooner rather than later
spstarr: hmm
spstarr: airlied: ask the intel folks maybe?
felipec: airlied: disabling modesetting definitely help Xv
felipec: hmm, but now it seems I'm getting the same minor glitches I had on F9
rhodan: hi
rhodan: cat i expect the qt4-acceldfs-pixmap error to be fixed until christmas?
rhodan: *can
rhodan_: or will it be fixed with dri2?
airlied: glisse: btw seeing some regression reports in stability since nha's indx buffer fixes.
airlied: glisse: not sure if you know much about that, I'll review it.
spstarr: airlied: i dont suppose you have anything for me to test today, given it's a weekend ;)
airlied: spstarr: nothing more at ths point.
tlp: airlied: are you still focusing primarily on kms work?
airlied: tlp: when I'm not doing my real job.
tlp: what's your real job?
airlied: maintaining X on RHEL.
tlp: ah
airlied: I got distracted for a week or so recently by that, so I'm hoping to get back to more kms bits.
tlp: I think you said something about a memory manager needing to be (re)written or something before improvements could be made to r5xx.
airlied: mainly for radeon I want to get new mesa from glisse up and going.
airlied: tlp: with glisses mesa on top of kms in theory things like fbos are now possible.
tlp: ah
airlied: but I need to get all that code into rawhide and stabilise it.
airlied: so I can get dri2 and fbresize type things.
tlp: DRI2 sounds nice
airlied: but it would be nice to solve all the various issue the mm and kms bring up along the way.
mattst88: airlied, I thought kms stuff was your real job? is that not a big priority for RH?
ajax: sure. so's RHEL.
ajax: the joy of owning both the shipped product and the developing product is, sometimes, you have to neglect the one for the other.
ajax: often multiple times in one day
ajax: we juggle priceless eggs in variable gravity, to abuse a Niven quote.
mattst88: where are you from, ajax?
ajax: well, i live in boston, and i work for red hat.
ajax: i'm originally from various embarassing places in the midwest.
mattst88: at some point I'm going to visit the raleigh campus, I'm not too far away from it
ajax: only time i've been there was orientation when i got hired
ajax: nice enough place, but seems to suffer from the same problem as the "boston" office, namely, it would be nice if it were in a city.
revx: ajax: embarassing places in the midwest?
ajax: nothing good has ever happened in peoria, for example.
revx: nothing good has happened where I live (which is why I plan to get out of here by mid 2009 :)
revx: but I don't know how that equates to embarassing :P
mattst88: ajax, the raleigh office is right beside NC state, isn't it?
ajax: yes. i find ncsu campus unpleasantly sprawly.
mattst88: yeah, that's what I've heard
spstarr: but but.. RHEL5 is so obsolete now ;)
airlied: obsolete but making more money than anything else :)
airlied: ajax: move to BNE I have a spare desk :)
airlied: in a rare change of form the office is in the city.
ajax: meh. i have broadband.
ajax: and i'm less than 30ms from most of the devel servers, unlike BNE
ajax: i just need to bring more of my toys home so i can wfh more effectively
revx: ajax: is the work at home on your own time?
airlied: hehe.. I went the other way, the remote access switch is sorta useful at home.
revx: airlied: oh I saw something sorta cool: ajaxterm for remote access
revx: gives you ssh over http :)
airlied: I've got http://www-607.ibm.com/shop/asiapacific/webapp/wcs/stores/servlet/default/ProductDisplay?catalogId=-36&storeId=36&langId=036&dualCurrId=89&categoryId=4611686018425016404&productId=4611686018425058722
airlied: its got 16 kvm ports I can access over tcp, granted its with java app
airlied: that combined with remote power sockets means rarely having to see machines.
revx: airlied: but do you have that at home? :)
revx: airlied: I mostly use the ajaxterm to get around the decision by my school's network administrators to only allow http and https outbound
airlied: revx: well I can sit at home and access all the machines from my laptop.
airlied: not having the machines in my house is my primary goal, so I don't have noise/electricity costs.
airlied: but you really need video for GPU work, so its not like you can just rack machines like server ppl.
revx: hmm for some reason that reminds me: is the only regression testing that exists for most dri drivers waiting for bug reports of such to come in?
airlied: yes, pretty mcuh, we have piglet as well.
airlied: but it doesn't cover all the things that we hit.
airlied: esp stability issues
dmb: hey bridgman :P
bridgman: howdy
revx: bridgman: how cold does it get up there this time of year?
bridgman: farenheit or celsius ?
revx: either works as long as you specify :)
bridgman: ok, last night was around 4F
bridgman: daytime just below freezing
bridgman: I live out in the sticks though; Toronto area is warmer
revx: I live right next to lake michigan so I get a slight warming effect :)
revx: (as in the lake is .83 miles from my house)
bridgman: yeah, living near the lake is nice
bridgman: unless you live in Buffalo I guess; all the bad winter weather seems to dump there rather than coming up across the lake to Toronto
revx: you don't get some of Lake Superior's fun stuff?
moses: can anyone here help me with my ATI?
moses: im trying to get maximum video playback qualitty
bridgman: which GPU ?
moses: x1600
moses: i have used everything i know of
moses: to help my playback
bridgman: ok good; are you running the radeon driver ?
moses: yeah
moses: the one the website reccoments
moses: reccomends*
moses: it seems like it sucks ass though
bridgman: which website ?
moses: amd
revx: URL?
bridgman: ok, sounds like fglrx (our proprietary driver)
moses: http://ati.amd.com/support/driver.HTML
moses: its the catalyst control system
bridgman: yep, OK. This month you'll get the best video quality from the open source radeon driver
bridgman: next month might be different ;)
moses: lol wow really?
bridgman: which distro are you running ?
moses: xp home
moses: can you link me to the os
moses: one
bridgman: oh, ok; for xp then the amd drivers are the way to go
bridgman: what kind of video problems are you having ?
moses: just the video quality is horrid
bridgman: this is really a linux channel ;)
moses: awww
bridgman: be more specific please ;)
moses: i can see all the pixels
moses: its fuzzy
moses: as all hell
revx: well I certainly hope you can see all of them :P
revx: moses: what media player are you suing?
revx: using*
moses: vlc
bridgman: does vlc run on xp ?
revx: bridgman: yep
moses: yeah
moses: its nice
moses: it worked good with my gforce
bridgman: wow; learn something new every day ;)
revx: moses: you'll have to fiddle around with the postprocessing settings
moses: where are those?
revx: moses: somewhere in the options -- I'm not a windows user :) (or a vlc user for that matter)
moses: is it on vlc or the graphics card driver?
revx: vlc
revx: bridgman: I guess the rather generic name for the channel is what does it...
revx: perhaps s/#radeon/#xf86-video-ati/ :)
bridgman: it's worse than that; xf86-video-ati is a wrapper for three drivers; mach64, r128 and radeon
bridgman: this channel is only for radeon ;)
revx: indeed :P
moses: ah so im screwed
moses: it seems like a shitty driver = (
revx: moses: this has everything to do with how VLC is using the video card
revx: the card is pefectly capable of accelerating different types of postprocessing
moses: ok
dmb: bridgman, 4f? damn
terracon: smplayer for windows too
dmb: 20f last night for me
moses: well i hope someone gets back to me in videolan
dmb: in NJ
terracon: http://smplayer.sf.net
revx: moses: you could also try ##windows
dmb: moses, what card do you have?
moses: x1600
dmb: is that not a radeon?
moses: it is
dmb: does fglrx work?
revx: dmb: he's using windows
moses: im on windows
moses: ^_^
dmb: oh, we don't do windows here
moses: i know = (
bridgman: yep, it's a radeon; problem is that the X driver, the drm driver, and the mesa driver are all called radeon, as is the card and an obscure moon in the Star Wars universe
bridgman: but it's a slow night
dmb: bridgman, i have a mach64!
dmb: were you around those days?
revx: bridgman: I wonder how much longer the Radeon name is going to last... but then I look at how long AMD rocked out Athlon.. and now Opteron
moses: amd needs a new driver...
moses: lameeeee
bridgman: I joined ATI just after the mach64 was launched; work was just starting on r128
dmb: ah
dmb: did the mach64 have programmable textures?
bridgman: moses; not sure what to say - all of the hits I'm finding on vlc/windows/ati seem to think quality is real high, ie no obvious settings to change
moses: no its not though1
moses: !
bridgman: dmb; I think so; don't remember if it was single texture or 2 texture though
revx: moses: check the postprocessing settings
bridgman: yeah, I understand ;)
dmb: oh
dmb: i need to find the developer of mesa driver or drm driver for mach64
moses: im a noob can you help me with that?
dmb: EXA makes everything turn blue
moses: revx:
dmb: and the pointer turn into a box
revx: moses: I'm dropping the name because I have no idea what it looks like in VLC's settings
moses: ok
moses: well in vlc
moses: theres all these filters
revx: check around 'post processing' 'video output' 'hardware acceleration' etc in the settings
moses: that are for postprocessing
bridgman: I think the mach64 driver was written by the tungsten guys; same ones are still there
bridgman: MrCooper would probably remember
moses: should i check all the filters?
moses: theres a shitload of postprocessing options
bridgman: moses; the vlc faq doesn't say much but talks about checking screen depth more than I would expect in the 21st century; maybe vlc defaults to something crappy like 16bpp ?
moses: that is possible it looks like a depth problem
moses: i just gotta find that optuion
bridgman: dmb; I'm just looking through the mesa source, wait one
moses: omfg
dmb: vlc works fine for me
revx: bridgman: do you know if the 3d stuff for r700 will come about at the same time as the r600 docs?
dmb: on linux that is
moses: the quality on mine is shit
bridgman: seems like the usual suspects; dave airlie, keith whitwell, brian paul, eric anholt, ajax, felix (works for amd now)...
bridgman: revx; yes, one package for both is the plan
dmb: ah
dmb: so i guess filing a bug is the best solution then
dmb: had a hard time using the search function of bugzilla
revx: bridgman: actualy I've resorted to an interesting project for my winter break since there isn't any accel for me
bridgman: revx; what kind of interesting project ?
revx: bridgman: I'm trying to improve the software rendering performance of ioquake3 under mesa
bridgman: neat...
revx: bridgman: since I have a 4 week break (starting yesterday) I thought I'd look into it
bridgman: there are some very cool things being done with just-in-time compilers these days
dmb: how does software mesa compare to the software implementation in windows?
moses: should i change the postprocessing quality?
moses: its @ 6 now
bridgman: it might be interesting to try playing with gallium and the softpipe driver
revx: bridgman: is softpipe functional?
moses: fuck 6 is max
bridgman: dmb; don't know for sure but my guess is that mesa has more performance optimization
revx: if so I may do that since it may be more useful down the line than working with the old swrast stuff
bridgman: I think softpipe is kind of the reference so most likely to work
revx: there's some obvious stuff I've seen in the swrast source in comments and code
revx: like triangle strips are rendered as seprate trianges!
revx: nothing is saved between triangles...
bridgman: ooh
revx: in the case of quake3, EVERYTHING is emmited as a trigangle strip
bridgman: s/ooh/eew/ ;)
revx: -g*
dmb: GL_LINE_STRIP?
bridgman: in fairness, once hw acceleration showed up I bet performance optimization of the software rasterizer stopped being a priority pretty damn fast ;)
bridgman: and that was at least a decade ago...
revx: bridgman: I'm worried the same thing is going to happen to me :P
bridgman: yep, you have to look for places where software rendering is interesting, like, say, when a big company is coming out with a big honkin chip that uses software rendering
dmb: bridgman, i don't know if you can say this or not, but do you know if ati is working on an opengl 3 driver (fglrx)?
bridgman: we share a lot of opengl code between all the OSes so if one OS gets it they'll all get it
bridgman: I don't know for sure but I imagine it's important for at least one of the OSes ;)
revx: bridgman: well for me working on swrast helps me learn and understand rendering algorithms very clearly ;)
bridgman: yep, I think swrast is really important that way
dmb: lol
revx: bridgman: there are some things in general that kinda bother me
bridgman: there's a fairly recent software renderer for windows that looks pretty good
revx: the use of fixed point math, as it exists came about due to old hardware limitations
bridgman: fair amount of discussion in the beyond3d forums
bridgman: yeah, 10 years ago CPUs didn't exactly shine at floating point
revx: but due to some of the ugly hacks, there are things that the compiler could figure out how to improve that it's blocked from doing so
bridgman: it's only when all the CPUs picked up fast SIMD that it started to make sense
spstarr: hullo bridgman
bridgman: revx; too bad it's not open source so anyone could fix it; oh wait, it is ;)
bridgman: hi spstarr
spstarr: bridgman: do you have any known erratas for the RV350?
spstarr: or know if we can get those somehow?
revx: ROFL
dmb: revx, are you committing your changes?
revx: dmb: if any are worthwhile
bridgman: I can look around; docs for pre-5xx aren't that easy to find
bridgman: looking for agp-related ?
bridgman: rv350 was about the time we switched to pcie and heaved a great sigh of relief
bridgman: unfortunately everyone kept using agp despite the suckage
bridgman: agp was really cool back in the mach64 days ;(
dmb: 4MB of video ram my mach64 had
dmb: has*
bridgman: I keep telling marketing we should charge $100 extra for agp cards, then ship a pcie card and free motherboard
dmb: i guess agp was a pain in the ass to deal with?
bridgman: yeah; in principle it was great and it introduced some good concepts, but the specs were too loose so different combinations of hw didn't necessarily work together, and there were too many revisions & versions so it was impractical to test all combinations
revx: bridgman: wasn't AMD a driving force in the creation of AGP?
bridgman: we were certainly a driving force in the adoption of AGP, at least we sold the most AGP chips
bridgman: didn't think we were involved in the design though, will ask
revx: I was probably first reading the GPL when that was going down
revx: well I guess that came a bit after :P
bridgman: the original agp spec was probably ok, but the later revisions started to hurt
bridgman: I don't remember having problems until we got into 4x and 8x
dmb: oh
bridgman: I wasn't heavily involved; this is just anecdotal
revx: bridgman: I've been looking into taking advantage of several cores with swrast.. as such I've been looking at how to parralelize things
revx: bridgman: tiled rendering is what airlied suggests
revx: bridgman: but there are other places where there are natural splits -- like fragment ops(in fact all the write_span stuff is commented about wanting that to happen)
dmb: threaded?
revx: bridgman: /wg 13
bridgman: yeah, there's lots of interesting ways to split up the work
revx: oops
bridgman: one thread for vertex processing, another for pixel processing is the obvious one
bridgman: tiled rendering is nice because you get great cache hits
bridgman: I figure one core for the game, one for the OS, one for vertices and one for pixels
revx: hmm with regards to splitting off the shader ops, I'm not sure what to worry about in terms of side effects of fragment programs on GL state
bridgman: should keep the CPU busy for a couple of years
bridgman: I think you can just treat it like a pipeline and flow everything down; if state changes upstream it doesn't need to affect pixels from objects that were drawn before the state change
revx: if say I have several slaves executing fragment ops...
revx: indeed
bridgman: didn't think fragment programs can change the actual gl state, can they ? thought it all flowed downhill
revx: but then there comes the need to seralize certain things
revx: bridgman: well if you render two trianges with different z values at the same pixel, but the z test is enabled....
revx: order matters there
bridgman: we don't serialize much in the hardware; a bazillion things run in parallel and we only bother flushing anything when it comes to do something like render from a texture you just rendered to...
bridgman: in the hardware you have to turn off early z test if the shader program fiddles with depth; presumably the same would apply for a software renderer ?
bridgman: or are you talking about a different z test ?
revx: well if there are z or stencil tests that could be affected by previous primitives...
revx: I'm trying to see if I can come up with a specific example where simply "copying GL state" (not quite to that extent) at the time a pixel is being drawn will fail
bridgman: I didn't think order mattered there, although I've always been a bit fuzzy on what happens once you start alpha blending; it seems like order should matter but...
bridgman: my comment was for z/stencil, not your last line
revx: fragment A is created first from GL calls, then fragment B -- from the perspective of the client... but the renderer easily could get to B before A if they're put in different threads
spstarr: bridgman: thanks
spstarr: bridgman: yes agp related
bridgman: ahh, just looked at the AGP spec; I think things started going downhill as the voltages started to go down; AGP 1x and 2x were 3.3v, 4x was 1.5v and 8x was 0.8v
bridgman: you really need differential signalling for those voltages and speeds if you want reliable operation with "built to a price" consumer hardware IMO
spstarr: bridgman: did you see the corruption videos i have and images? i think so?
bridgman: you can make single ended signalling reliable with a $500 PCB and lots of ground planes but...
bridgman: I'm on a 21.4 Kb/s dial-up line; if they were bigger than an avatar probably not ;)
revx: bridgman: one solution I have is to have a 'lock space' in the framebuffer -- one bit for each element. When a fragment is emitted by the framebuffer, the lock is checked -- if zero, rendering procedes and it's set to 1(cleared after the slave does all ops on that fragment). If it's 1 when emitted, the geometry thread will wait until it's clear
bridgman: wow, 26.4 K tonight
dmb: ?
bridgman: how do you know if all ops are done on the fragment ? Are you assuming pre-sorted triangles or something ?
dmb: bridgman, no broadband in your area?
revx: bridgman: the geometry thread only sets and checks the locks -- never clears them
bridgman: I'm still not sure why you need a lock but there's more rust on that part of my knowledge ;)
revx: that's up to the thread processing the fragments
bridgman: No cable or dsl; I can get satellite but my house is surrounded by 60' trees and I'm on a north facing hill so I have to cut something like 170 trees to get line of sight on the bird
revx: bridgman: or build a tower!
bridgman: yep; 60 foot towers aren't cheap though, and what I really want is an observation tower
revx: build an observation tower
revx: and conviently put your dish on it :)
bridgman: yep, that's the plan, but probably won't happen until about 2012 or so ;(
revx: bridgman: that's the end of the world!
bridgman: ahh, then 2011 ;)
bridgman: or I could probably buy everything cheap in 2013
revx: bridgman: I'm trying to think of a more elegant solution
revx: the lock would block the geometry thread until a shader op was done
revx: what I'd like to do is find a way to do this:
bridgman: oh, a more elegant solution for the renderer; I was typing about a more elegant solution for getting me satellite internet
bridgman: I still don't understand why you need the lock
revx: Fragment A is emitted for opertions, it's location is recorded. Fragment B is emmited, it's position maches A's, so it's added to say A->next to be redered right after (BUT NOT BEFORE!) A
revx: other than that the slave fragment renderers would just be FIFOs
bridgman: but why does fragment sequence matter ? Z is nature's way of sorting all that stuff out
revx: bridgman: it doesn't matter if someone is not doing funky stuff
bridgman: again with the possible caveat about alpha blending
revx: but some people out there like to do fancy stuff involving reads of the framebuffer
revx: and assume something's there....
revx: (having a 1 factor in alpha blending being a perfect example :)
revx: 1*DST
bridgman: ahh, ok; but usually there's a deliberate flush between the regular stuff and the funky stuff, and the funky stuff is coded so that per-pixel execution sequence doesn't matter
spstarr: bridgman: airlied things its the intel agpart
spstarr: thinks
revx: bridgman: now I don't know to much about how much shaders can get away with -- I don't know yet how much state I may need to replicate for the lifetime of a given fragment
bridgman: modern GPUs have literally hundreds of fragments in flight at the same time, could be for the same pixel, and I don't think anybody enforces strict execution sequence
bridgman: the code has to be sequence invariant
bridgman: spstarr; things is close enough - does dave think the agpgart is broken or just that's where the hacks to make it reliable will probably go ?
revx: bridgman: so then I could make mesa set up some threads for executing fragment FIFOs... and modify the span_write* stuff to just send off fragments to these, not caring...
bridgman: the main trick with AGP seems to be cutting it back to the point where card and chipset can talk reliably
RTFM_FTW: that last point is one of the reasons why we aren't allowing FB reads directly from the shader
spstarr: bridgman: AGP 1x dont work 2x, 4x no with KMS only
spstarr: bridgman: non-kms it works fine
bridgman: rtfm_ftw; just in time, I'm getting out of my depth real fast ;)
RTFM_FTW: heh
revx: now one of the things I want to avoid is copying every bit of state needed for each fragment when I know for sure it's going to be identical in spans at least
bridgman: spstarr; are you saying 1x is broken both with and without kms, while 2x and 4x work with no kms ?
revx: and probably more than in just spans...
spstarr: no only with kms on
spstarr: any AGP mode on shows corruption
bridgman: Dave's theory earlier was that kms (and mm) on resulted in a lot more bus traffic and more chance for corruption; is that still the working theory ?
bridgman: Seems that would only hold if there was memory pressure...
spstarr: well my GART size is bigger
bridgman: with kms or without ?
bridgman: if anything I would expect less traffic with a larger gart, assuming it is all being used
spstarr: without I force the GARTSize to 128MB
bridgman: and with ?
spstarr: but with kms it's dynamic
spstarr: ^^^
bridgman: I guess the question is whether dynamic results in less memory pressure or more; I would expect less
bridgman: how much vram on your card ?
moses: what was the vlc player before this last update
bridgman: it's quiet... too quiet
revx: haha
revx: ugh... the uglist part of this whole splitting off the fragments: Deciding what state to copy and how to do so
revx: right now the process consists of me skimming a very large chunk of any fragment op code to see what I need...
revx: which is going to take a long while :P
spstarr: bridgman: 64MB
spstarr: bridgman: BIOS has a aperture of 256MB for intel-gart
bridgman: are you seeing the corruption even when doing simple things, or only running apps which might have more textures than can fit on your video card ?
bridgman: Could be games or I guess compiz at high rez might do it...
bridgman: what is your screen rez and virtual size ?
bridgman: actually even a 2560-wide screen is only going to take maybe 9 mbytes so I don't think you would be getting enough memory pressure to swap unless running a 3d app
bridgman: so Dave may be thinking that something just doesn't get initialized right on the kms path
bridgman: will leave that to the experts ;)
EruditeHermit: what is the plan for merging the kms code to master?
EruditeHermit: and the gem stuff
spstarr: bridgman: just starting X
spstarr: bridgman: here:
spstarr: bridgman: http://www.sh0n.net/spstarr/radeon/
bridgman: EruditeHermit; don't know schedule but presumably whenever devs feel the API is stable, which usually translates into "all the evil bugs are fixed and all the higher level functionality has been at least prototyped"
bridgman: probably getting pretty close to that
EruditeHermit: cool
spstarr: bridgman: you can see all sorts of 'fun' on that url :)
EruditeHermit: bridgman: so are we going to get r600/700 3D by christmas?
EruditeHermit: =p
damentz: that would be cool
EruditeHermit: I read a post by you on phoronix which left that a possibility
spstarr: bridgman: even the bios rom is there if you need it :)
spstarr: bridgman: http://www.sh0n.net/spstarr/radeon/kms-agp-badness.png is what I see with AGP on with KMS
bridgman: it's still a possibility, problem is that 30 seconds after I know for sure Alex is posting and a minute earlier I don't know when it will happen
spstarr: there's videos with that
bridgman: only 341k, back in an hour ;)
damentz: bridgman: btw, exa is good - there is an optoin that is off by default due to some issues with compiz
damentz: "EXAOptimizeMigration"
damentz: instantly everything is fast
damentz: found out a while
damentz: breathed some new life into my mobility 7500 and 9000 cards
damentz: regarding 2d of course
spstarr: bridgman: oddly, the text glyphs begin to become less corrupt as you use it
spstarr: its very odd
orkid: damentz: thanks, i'll have to try it out :)
damentz: orkid: it works with xserver 1.5.3 on my systems
damentz: i don't know if that option exists for 1.4.x and lower
spstarr: bridgman: its odd your up @ 1am on irc ;)
bridgman: looks up ExaOptimizeMigration on Google
damentz: bridgman: it's in the manual
bridgman: I got home late ;)
damentz: bridgman: 'man exa'
spstarr: airlied is likely lazing about at home or something :)
bridgman: is running Vista right now ;(
spstarr: bridgman: heh, im just sitting in the kitchen watching tv
spstarr: I love my new freedom living on my own :)
damentz: > Option "EXANoDownloadFromScreen" "boolean"
damentz: > Disables acceleration of downloading of pixmap data from the framebuffer. NOTE: Not usable with drivers which rely on DownâloadFromScreen succeeding. Default: No.
spstarr: wifi internet anywhere in here
damentz: err woops
damentz: copied wrong one
bridgman: TV is blocked by the same trees as satellite internet, so I have to wait for the DVD
damentz: oh dangit, i forgot to upgrade to hte latest version of xorg to get the latest manual
damentz: haha, hold on
damentz: will take a sec
bridgman: ahh, it's in the server not the driver
EruditeHermit: bridgman: I thought it was all done, just waiting for IP review
bridgman: yep
bridgman: but IP review is non-trivial
EruditeHermit: yeah
EruditeHermit: will the 3D support be similar to what is available in r500 and below?
EruditeHermit: i.e. only openGL 1.3
EruditeHermit: or will it be OGL 2.0 compliant?
EruditeHermit: I am thinking of buying an HD4850
bridgman: we don't have much of the 3d driver code done yet, just demo 3d calls and using the 3d engine for EXA and Xv acceleration
EruditeHermit: ah
bridgman: first big milestone will be getting to same level as 5xx, but we're releasing enough info to get to 2.x or higher AFAIK
EruditeHermit: but, you won't be working on it yourselves?
EruditeHermit: in the near future
spstarr: bridgman: but yeah, if you can find docs that would be helpful for us :)
damentz: Option "EXAOptimizeMigration" "boolean"
damentz: Enables an additional optimization for migration of destination pixmaps. This may improve performance in some cases (e.g. when switching virtual desktops with no compositing manager) but causes corruption in others (e.g. when starting compiz).
damentz: Default: No.
damentz: bridgman: there
damentz: had to update to xserver 1.5.3 from 1.4.something
damentz: forgot about that, reinstalled my whole system so i could use ext4 in sid
bridgman: we'll be working on it ourselves as well, but it'll go faster with more people
bridgman: we have plans as far as 1.3-ish right now
bridgman: damentz; is it just me or does that not say anything useful ?
bridgman: the fact that EXA OptimizationMigration enables an additional optimization for migration is a total surprise, I never would have guessed that from the name ;)
damentz: bridgman: it just mentions that with this option, 2d performance will increase but 3d compositing would be corrupted
damentz: haha
bridgman: geez, sounds like all those drug warning labels