MostAwesomeDude: airlied: Sorry for ping. git master DDX doesn't do DRI on F11, and I can't get F11's version of DDX to build against git xserver.
MostAwesomeDude: Any hints?
MostAwesomeDude: This is kind of forcing me to only shatter classic pixmaps, which I think are not actually shattering during fallback.
MostAwesomeDude: I'd really like to have exaCopyDirty working for sure and not just in theory...
MostAwesomeDude: Ag. I'm ranting. Sorry. :C
DanaG: yay, fired up my old 9800 pro; now just have to update stuff on it.
DanaG: synergy + compiz == fail.
DanaG: =รพ
airlied: MostAwesomeDude: use rawhide X server ;-)
airlied: since you get the new EXA code
Telek: airlied: Thank you :)
MostAwesomeDude: airlied: But I already rebased patches once, don't wanna rebase patches again. :C
MostAwesomeDude: I'll kick it more in a bit.
airlied: MostAwesomeDude: or pull the F12 kernel
MostAwesomeDude: airlied: Maybe. Thanks. :3
MostAwesomeDude: might just be a little desperate due to Monday being pencils-down day
hifi: osiris_: umm, something went wrong
hifi: [41920.315110] Forbidden register 0x4F5C in cs at 1802
airlied: you need a kernel patch for kms
hifi: for kms and what?
airlied: kms and OQ
hifi: oh, right
airlied: http://people.freedesktop.org/~airlied/0001-drm-radeon-kms-add-rv530-R300_SU_REG_DEST-reloc-f.patch
hifi: I forgot I tested without kms
hifi: was that sent to upstream?
airlied: its in the queue
airlied: I don't normally send merges on the weekends
hifi: most probably will make it to 2.6.31?
airlied: yeah thats the plan
hifi: oh, and R500 and vsync is still borked
airlied: yeah I havea patch from MIchel but it didn't seem to fix r500
hifi: it was a speed issue for me
airlied: I was going to fix that before I asked Linus to pull
airlied: well for me with the patch I don't get any vsyncing
hifi: I get vsync allright
airlied: I don't think I have 1400fps refresh rate
hifi: but at some places my fps drops down to 20 or so where it was ~70 before
hifi: only change is if ddx enables vsync
hifi: and any idea what happens here:
hifi: [42436.650667] [drm:r300_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 5678080 have 5242880) !
hifi: [42436.650673] [drm:r300_cs_track_check] *ERROR* [drm] color buffer 0 (1280 4 0 1109)
hifi: when I try to access openarena control setup
hifi: is the screen height calculated wrong?
hifi: before the error had "color buffer 0 (640 4 0 520)" when the window was 640x480, if it's related
hifi: 640*4*520 is 1331200 and 640*4*480 is 1228800
hifi: seems like it
hifi: oh, and the first error was [drm] Buffer too small for color buffer 0 (need 1331200 have 1228800) !
airlied: seems like something tries to use a colorbuffer that is too small for what is wanted
hifi: why it would be bigger than the window if its expected to be the window's size
airlied: hifi: hmm not sure whats going on there
hifi: I tried to find out a commit but I went back over 2 months and still got the same result
hifi: at some point even glxgears started to segfault or without direct rendering
Telek: hifi: That's been true for at least 6 months I think :(
airlied: osiris_: http://people.freedesktop.org/~airlied/0001-r300-OQ-reimagining.patch
airlied: osiris_: works with swtcl as well
phercek: I figured out why my thunderbird was so terribly slow even with the latest git driver versions. The problem was I have RV670 AGP and AccelDFS is by default off for AGP because (based on the man page) it does not work with some AGP bridges. If the (non)working bridges cannot be identified (i.e. the decision cannot be done by per-bridge basis) it would be good if there is at least a note in Xorg.log about AccelDFS being off which can result to really bad slowdow
airlied: glisse, osiris_ : busy check proposal on the list, I overloaded it to get the current bo domain also
airlied: since I really want that in the DDX for optimising DFS
suokko: airlied: error check in radeon_object_busy_domain looks like it is in wrong place
suokko: or missing reserve call
airlied: oops cut-n-paste fail
airlied: suokko: just send replacement ;-)
osiris_: airlied: looks almost ok. you need to call radeonEmitQueryBegin/radeonEmitQueryEnd need to be called on every rendering operation
airlied: osiris_: why?
airlied: every rendering operation emits state
osiris_: airlied: because DDX could insert his rendering operations in the middle
airlied: not in the middle ofa CS
airlied: each CS will get a begin at emitstate time if query enabled, and an end at flush time if still enabled
osiris_: airlied: also remove PAGE_SIZE macro from radeon_queryobj.c (I see you've added it to radeon_queryobj.h)
osiris_: airlied: so we flush at the end of every CS?
airlied: if a query is active
osiris_: airlied: there's indentation error at the very end of the patch in "static inline void radeon_init_query_stateobj" function, which shouldn't be marked static
airlied: it needs to be static since its in a header file
airlied: I fixed the tab
suokko: airlied: Maybe that pq's extern inline idea would be better than static inline
airlied: no static is correct
airlied: oh forgot to remove some includes
osiris_: airlied: hmm, let me get this straight. every CS that is send by DDX or mesa driver has explicit flush at the end?
suokko: Only problem with static inline is that you may end up with multiple copies of same function if gcc chooses not to inline. (arguably that is linker bug not to merge them)
airlied: gcc shouldn't be choosing that ;-)
airlied: osiris_: well the only place we send a CS to the hw in mesa driver is in rcommonFlushCmdBufLocked
airlied: so whenever we send one and a query is active, we add it the end query onto it
osiris_: airlied: aah, ok. looks ok then
osiris_: airlied: there's just one thing I worried about
suokko: I guess there should be some kind of flush state list for this kind of states that need operation when cs is flushed. Or is OQ only one that will need that kind of save operation?
osiris_: airlied: in radeonBeginQuery we flush swtcl pipe, doesn't it remove the perf gain of OQ?
airlied: suokko: OQ is the only one I know off
airlied: osiris_: that doesn't flush to gpu
suokko: Maybe cache control would need too
airlied: suokko: for legacy CS we do cache emits
suokko: But I haven't read the details
airlied: in radeon_cs_legacy.c
airlied: but thats inside the CS module
osiris_: airlied: oh. did you check the OQ under KMS? it fails randomly for me
suokko: airlied: I mean the GPU cache flush
airlied: suokko: yup so do I
airlied: osiris_: I've just ran arbocclude so far
airlied: under kms, tcl + non-tcl
airlied: osiris_: the dma flush just emits the rendering commands to the CS
suokko: I think that cache control is hard coded to TryDrawPrims
osiris_: airlied: arbocclude is working for me too. it's the piglit's test that fails (bin/occlusion_query and glean/occluQry)
suokko: r300EmitCacheFlush call is in begin and end
airlied: suokko: also r300_vtbl_emit_cs_header
airlied: is used by legacy code
suokko: But is cache flush really required that often?
osiris_: suokko: probably not
airlied: suokko: its doesn't have any overhead if its already flushed
suokko: I was more like thinking that do we have to call it between every rendering operation
suokko: (Like scissors)
osiris_: airlied: in one CS we most likely have few rendering operation from the same VBO so flushing the caches that often can be a major perf hit
airlied: yeah we should play with it and see if we an increasee
airlied: its mostly there from the old r300 days where we better safe than locked up
suokko: Also r300 documentation claims that cache flush may take hundreds of gpu cycles to do so it is expensive to emit
suokko: airlied: ok :)
osiris_: airlied: why not flushing the cache would cause a lockup? I think it should be rendering errors at most
airlied: osiris_: GPUs aren't very good at not locking up
osiris_: airlied: git am is complaining about trailing whitespaces
osiris_: airlied: lines 36, 133, 702, 871 and 886 of the patch
nanonyme: airlied: Hmm, fail-fast system design or what?
suokko: :%s/\([^ \t]\)[ \t]\{1,\}$/\1/
airlied: that would imply design
suokko: thinks that r300TryDrawPrims needs some reordering. I'm thinking to delay dma allocation after all the state changes has been calculated
airlied: osiris_: I've updated the patch I'll check it in tomorrow, once I make it pass at piglit
airlied: and try and get r100/r200 to work
airlied: unless you think its okay for now
suokko: What doesn't work with r200 now? your patch busy patch?
airlied: OQ
suokko: ok :)
airlied: suokko: http://people.freedesktop.org/~airlied/0001-r300-OQ-reimagining.patch
airlied: that patch moves stuff atround so adding r200 support should be "trivial"
osiris_: airlied: it doesn't work with swtcl
osiris_: airlied: run arbocclude and go with the yellow box outside of the window
osiris_: airlied: I think there's radeonEmitQueryBegin call missing somewhere in swtcl path
osiris_: like in r300RenderStart
airlied: osiris_: oops
airlied: blames clipping or something like that ;-)
airlied: osiris_: you should never need a query begin
airlied: as once you emit state it will get emitted if dirty
airlied: and you always emit state before rendering
airlied: I'll see if I can fix that tomorrow as well
airlied: zzz &
chainsawbike: can any one tell me if the 3d code for rv770 is near usable? - im not to stressed about speed
nanonyme: Well, it's atm more speedy than usable, me thinks. :p
nanonyme: There's geometric corruption issues.
chainsawbike: tried to run compiz - it started but failed to do anything useful :P - would it be my end or is that expected?
nanonyme: Define useful.
chainsawbike: ill make a screenshot
nanonyme: That is, imo compiz by definition isn't anything useful so might be better to describe what you're expecting. ;)
chainsawbike: http://chainsawbike.selfip.com/hosted/Screenshot-1.png
chainsawbike: i tried to move the window above firefox
chainsawbike: far right is conky
chainsawbike: beside that is xchat...
adamk_: I didn't that when using compiz with my HD3250.
adamk_: 3450, rather.
adamk_: Or something thirty-something-fifty, anyway.
chainsawbike: mine is a hd4870
flo|linux: hi
flo|linux: i found a bug similar (but not fully identical: other programs that fail, however the same principle) to mine in the bugzilla. however it was was opened in 2007 and yet unsolved. should i enter a new bug or should i post a comment to that existing bug?
suokko: flo|linux: If you think cause of problems can be different (often if you don't have same hardware) then you should open new bug report
flo|linux: hmm, i dunno if it's the same problem...
flo|linux: i'll open a new bug, ok ^^?
suokko: ok :)
nanonyme: Hmm, something broke my resume from suspend. :(
nanonyme: Curious. The display doesn't seem to switch on without doing a VT switch. :)
nanonyme: Heh. The difference between Phoronix threads on open and closed drivers seem to be that in open driver side problems also get a solution. :3 (been reading them through, a nice amount of open driver threads actually reach some conclusion)
nanonyme:
spstarr: glisse: how goes GPU reset stuff?
spstarr: reads the osnews rant on X.org
terracon: a little flameish but I have to agree with the osnews guy
terracon: X fucks up far too often. hence the NEED for ctrl alt backspace
boghog: now that I think about it, I can't really remember the last time I used it
nanonyme: Which article?
terracon: http://www.osnews.com/story/21999/Editorial_X_Could_Learn_a_Lot_from_Vista_Windows_7
nanonyme: Pity he didn't say which graphics card he had and which drivers he used.
nanonyme: A potentially useful post ended up a useless rant because of that, mostly. :(
suokko1: But there is point that core server should never crash if any of drivers crash. There should be way to gracefully handle it and keep X running
nanonyme: suokko1: What if it's nVidia's drivers running that replace parts of X.org stack?
nanonyme: It might not be X.org stack's fault in that case.
nanonyme: As I said, because of necessary information that's just a useless rant, really.
terracon: yeah he didn't say what he was using
suokko1: But still there is design flaw that driver can crash whole server instead of only that driver. There should be also way to clean up after driver crash and restart it :)
nanonyme: Lack of necessary information even.
nanonyme: suokko1: Yeah and I'm sure I can make Windows 7 GUI crash too if I start replacing Windows core dll's.
Anorick: dear
suokko1: But that doesn't remove the real problem that Xserver is not resilient enough for bugs in one of its components :)
Anorick: Woops, wrong channel >.> apologies
terracon: np , heh
nanonyme: suokko1: I'm sure Windows 7 GUI isn't either if I'd replace the dll's. :3
suokko1: But that isn't my point. My point is that bug in radeon driver can also crash whole server. There is no bug free code so better write some code to handle the bugs in runtime
nanonyme: suokko1: My point was he said X could learn a lot from Vista or Windows 7 which might or might not be true but cannot be verified due to his lack of information. ;) But yeah, you're right, it could probably handle unexpected cases better.
suokko1: nanonyme: What I remember windows gui bugs was that bugs there only took one application down but usually state was broken same time so more crashes was excepted soon.
terracon: right near the bottom he says he's using the nvidia proprietary driver
nanonyme: Hah.
terracon: The fact that the driver code is proprietary (which it indeed was) is not relevant in this story in ANY way. X drivers should be contained properly, so that any bugs in there do NOT affect users' data.
terracon: http://www.osnews.com/thread?378834
nanonyme: terracon: It's not just the driver that gets installed when you install the nvidia "driver".
suokko1: But that is true hat blobs are still noe step worse than core X alone :)
terracon: nanonyme: oh I know. That's why my last nvidia card was a tnt2
nanonyme: terracon: My point was that if you start messing around with the graphics stack, breakages are to be expected.
yangman: you're also no longer "on the X.org stack"
nanonyme: You simply can't cover all problem scenarios.
suokko1: nanonyme: That why there is unit test to test all the possible inputs :P
nanonyme: If the question is whether the stack could be better and errors better, then I agree, it probably could.
suokko1: So at least it won't crash with any input (even invalid)
nanonyme: suokko1: What if the input is impossible with a genuine X.org stack?
nanonyme: Would you still know to test for it?
suokko: nanonyme: I don't care the rant really. I care about the point behind that rant
nanonyme: suokko: Then yes, as I said, I agree.
suokko: But if driver doesn't stay in its own area then driver developers should test it. So any problems when blobs are installed should go blob developers
DanaG: odd... I'm getting a null-pointer dereference on my R350.
terracon: they can't test anything when the xorg stuff get's replaced
DanaG: http://pastebin.com/f345e1da
DanaG: I'm using finch right now -- xorg hard-locks if I let it try to start.
DanaG: oddly enough, disabling KMS makes it work fine.
DanaG: or at least, it did with a previous kernel.
suokko: DanaG: not odd because the null pointer bug is in kms code
DanaG: yeah, I guess "odd" is the wrong word.
DanaG: And what IS odd, is that I then get my boot hanging at a couple of places, until I press ctrl-C.
DanaG: One is right after it detects the Winbond chip.
suokko: Is your kernel 64 or 32 bit?
DanaG: 32-bit.
DanaG: Linux GLaDOS 2.6.31-5-generic #24-Ubuntu SMP Sat Aug 1 12:48:18 UTC 2009 i686 GNU/Linux
nanonyme: suspects DanaG's computer must be running pretty hot
DanaG: Why? And CPU hot, or GPU hot?
nanonyme: CPU.
nanonyme: ondemand governor failed, too long transition latency of HW, fallback to performance governor
DanaG: aah, it's a mobile cpu on nforce2.
nanonyme: Yeah, it's not using any powersaving.
DanaG: Honestly, I would've been better off with a Via and the mobile.
DanaG: At least then I could use PowerNow.
suokko: mov 0x40(%edx),%ecx
DanaG: Actually, it runs pretty cool. I have it at 1.55Vcore (default for mobile is 1.45, default for desktop is 1.65).
nanonyme: Hmm, right. Anyway, back to the matter at hand.
spstarr: suokko: glisse was/is working on GPU reset support
DanaG: Oh yeah, what's the upper limit for R350 GPU temperature?
DanaG: upper safe limit, I mean.
suokko: spstarr: I think gpu reset should work with KMS
DanaG: Unfortunately, mine does not have a sensor buit-in.
spstarr: if we have GPU reset, then nothing dies
spstarr: the card is kicked and X continues on
suokko: spstarr: What if it is code bug instead? like that DanaG's problem with null pointer
suokko: is poor at matching assembly to C source
spstarr: well, code that is so hot is bound to have bugs
suokko: DanaG: I think that your agp subsystem is not initialized
suokko: or at least agp pointer in device structure is null
DanaG: hmm... I know I put agp-nvidia and agpgart in initramfs... or at least, I think I did.
DanaG: ah, agpgart-nvidia message is below the radeon oops.
DanaG: Oh yeah, and the module option "dynclks" -- does that yet do anything?
MostAwesomeDude: suokko: If you don't mind me asking, what design changes would you propose in order to prevent modules from crashing X?
suokko: no idea.
zhasha: MostAwesomeDude: It's simple... Kill the Batman
suokko: MostAwesomeDude: separate memory space and handling of fatal signal so that server can continue running
zhasha: Ideally, remove X from the equation
ajavid: hi
zhasha: create a core server that stores all information
DanaG: hmm, is it possible to force modules to load in a specific order in initramfs?
MostAwesomeDude: suokko: So, run each module of X as a separate process?
ajavid: I'm u sing debian and http://pastebin.ca/1531626 (log file) http://paste.debian.net/44366/ (conf)
suokko: DanaG: You probably should report that null deference to bugzilla so it gets fixed
zhasha: something dies, windows don't go boom
ajavid: I can't get 3d to work
ajavid: glxinfo|grep ren says software rasterizing
ajavid: please advise
suokko: MostAwesomeDude: It is possible just to override malloc/free. But I don't know if fatal signals can be handled gracefully
suokko: ajavid: Did you read the topic?
ajavid: yes I am aware of the problem but I thought I already had the linux-firmware package installed
suokko: That is common problem in debian how they package firmware (I didn't look the log yet)
MostAwesomeDude: suokko: X catches a lot of signals already.
ajavid: nowhere in the log did I find it looking for a firmware and not finding it
zhasha: ajavid: LIBGL_DEBUG=verbose glxinfo
MostAwesomeDude: But the problem, as I see it, is things like a double-free.
MostAwesomeDude: Some things just can't be recovered from.
ajavid: what is atom bios?
MostAwesomeDude: ATOM is just a set of tables on the card that describe things like modesetting and power management.
ajavid: oh
ajavid: firmware-linux got removed (i looked in aptitude log)
suokko: MostAwesomeDude: Rewrite it in C++ and disallow direct pointers ;)
zhasha: suokko: die in a fire
suokko: ajavid: You should put AccelMerhod "EXA" to xorg.conf
ajavid: why is that?
DanaG: ah, it was the order in which I had listed the modules, in /etc/initramfs-tools/modules
ajavid: (btw thanks for the tip on firmware)
suokko: ajavid: (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
MostAwesomeDude: suokko: Actually, if I had the time, drive, and proper mindset, I'd much rather use Python.
ajavid: suokko, what is EXA?
MostAwesomeDude: Proper MI, no memory management, etc.
zhasha: MostAwesomeDude: for drivers?!
MostAwesomeDude: zhasha: Drivers are goin' in the kernel now. :3
MostAwesomeDude: And for everything else, there's ctypes.
MostAwesomeDude: ajavid: EXA is an acceleration system. It's the one to use these days.
zhasha: did you just say you want to use an interpreted language for DRIVERS?
ajavid: good stuff
ajavid: also, alt+ctrl+backspace doesn't work either
zhasha: ajavid: not default on 1.6
ajavid: I tried nozap false and true (just to make sure)
ajavid: its in my conf paste
ajavid: what is wrong there?
MostAwesomeDude: zhasha: It's not interpreted. :3
ajavid: http://paste.debian.net/44366/
ajavid: (I changed to EXA)
zhasha: MostAwesomeDude: close enough
MostAwesomeDude: zhasha: It's roughly the same speed as non-JIT Java.
suokko: MostAwesomeDude: I think you can get memory management for free in c++ if you write code correctly :)
zhasha: but for DRIVERS
MostAwesomeDude: suokko: Boost =/= good memory management, and it's too heavy.
DanaG: odd... xorg log shows all signs of loading fine, including loading r300_dri, yet it's using swrast.
MostAwesomeDude: suokko: I thought I knew C++, but this guy showed me otherwise. http://www.gotw.ca/gotw/
suokko: You don't need anything boost like for memory management. STL is enough
MostAwesomeDude: Read through a few of those. The little things of C++ are *really* tough.
zhasha: MostAwesomeDude: it's not about speed, it's the whole memory management, python dependency, cloaking the machine architecture part
MostAwesomeDude: zhasha: Memory management is taken care of; Python deps are no longer such a big deal (RPM-based systems need it, Portage-based systems need it)...
MostAwesomeDude: Python's got a C-based FFI too. http://docs.python.org/library/ctypes.html
MostAwesomeDude: This is how things like pyglet work.
suokko: MostAwesomeDude: I know some of those and I know also that some of them are going to get fixed in next standard
zhasha: why would you want to rewrite it?
suokko: Btw, Boost is realy compile time heavy but it is very light in runtime if you disable debug code from it
MostAwesomeDude: suokko: Yeah, but my point remains that C++ is painful.
suokko: MostAwesomeDude: C is more painfull ;)
zhasha: suokko: ... no...
MostAwesomeDude: It's great for large games where speed is essential, but those big game studios also have dozens of whipping-boy just-out-of-school kids willing to write spaghetti for peanuts.
nanonyme: MostAwesomeDude: Or not-eve-yet-out-of-school even? :(
nanonyme: s/eve/even/
MostAwesomeDude: But anyway, this is all hypothetical; I'm not going to rewrite X and I don't know anybody else who would/will.
nanonyme: Speaking of Python, heard any news of the Gallium3D Python state tracker?
boghog: i always wonder if I should maybe learn C++
suokko: With C I'm feeling all time I have to write a lot of spaghetti just to handle the basic data structures etc
boghog: right now im only comfortable with C
suokko: MostAwesomeDude: I agree :)
nanonyme: boghog: Learning new languages can't really ever hurt, can it?
boghog: i was learning GLSL shader programming and I realised operator/function overloading can really create some elegant code
boghog: yeah
nanonyme: Like learn Haskell and never look at the world the same way. ;)
rsmith: good Haskell tutorial?
nanonyme: Sorry, I was stupid and managed to wipe all my bookmarks.
zhasha: MostAwesomeDude: I would like to see wayland retire the X server
nanonyme: I'd have one otherwise.
yangman: rsmith: http://book.realworldhaskell.org/read/
rsmith: thanks!
zhasha: but it would require a TON of work...
DanaG: hmm, CPU is pegged at 100% CPU usage, for some reason.
Er0x: hey does compiz work on r600?
nanonyme: It's considerably fast with some corruption last I checked.
nanonyme: (on my GPU on my specific software combination)
nanonyme: No promises. ;)
suokko: DanaG: Did you report your null pointer dereference to bugzilla?
DanaG: hmm, actually, I don't have an account there.
nanonyme: DanaG: It's not like they cost anything. ;]
zhasha: Would it be possible to implement X as a client-side only thing, that would communicate with wayland?
suokko: DanaG: Can you send me bug link if you fill a bug report? I can post there some more details that will help fixing it.
DanaG: hmm, I guess I'll do that, after I have breakfast.
nanonyme: zhasha: Why not simply just make Wayland fully replace X server and port it to be compatible with the necessary X.org stack components?
zhasha: nanonyme: how exactly do you mean?
suokko: zhasha: You can just make wayland handle X protocol
nanonyme: Well, we have a modular X.org stack. I meant as in designing Wayland so that it can smoothly step into where current X server is.
zhasha: suokko: no
suokko: As wel las you can make any program handle X protocol and then use what ever way to draw it in screen
zhasha: the X protocol would imply making acceleration in wayland, which is definitely not acceptable
zhasha: it'd have to be a client side library
nanonyme: zhasha: I meant rather for input devices and other such junk.
zhasha: nanonyme: X in wayland = bad
zhasha: X on top of wayland, using a library to bridge the gap = elegant temporary
suokko: goes to write some template code in C ... oops that means evil macros :/
nanonyme: *shrug* Whichever, as long as you don't have to immediately rewrite too much of X.org stack.
nanonyme: If you do, I doubt Wayland ever becomes anything useful.
zhasha: nanonyme: if I rewrite X? what do I look like, krh?
nanonyme: zhasha: You as in passive subject in English.
zhasha: oh :P
zhasha: I'd like to see X deserverized under wayland, such that wayland is the only server
zhasha: I know that's basically impossible
zhasha: OR running the X server but pulling all windows into wayland
nanonyme: As long as your idea supports remote X forwarding, sounds fine to me...
zhasha: remote X forwarding as in X over the network?
nanonyme: Yups.
zhasha: yeah, that could work
zhasha: or we can keep doing it the same way we do now, where X becomes it's own windiow
zhasha: window*
nanonyme: These "hey, X is a network-focused software, let's deserverize it and make it just a desktop graphical system" people seem to forget that there's actually people who are using X forwarding over SSH. :)
zhasha: nanonyme: but wayland puts everything client side
suokko: Is there anyway to make a window open to 2nd workplace from console?
nanonyme: zhasha: I'm not going to understand how exactly it works and whether it makes sense by one sentence, I'd need either a spec or a very good graph and delivering them to me would probably most be a waste of effort. :3
nanonyme: s/most/mostly/
zhasha: well, wayland is not designed for the networking aspect of X
nanonyme: Then it's not a good replacement.
zhasha: nanonyme: it is for the ordinary user
zhasha: wayland just hands out buffers for apps to draw to, which is exactly what most people need
nanonyme: Not really. If it can't do that, we're going to eventually have to dump Wayland and use the information gathered to design something that can both handle network environments and is also efficient in local situations.
nanonyme: It's not a sane compromise to drop the network functionality, really.
zhasha: nanonyme: why do you want to retain the old network functionality so much?
nanonyme: Or let me rephrase: whoever wants to do it will have to do it.
nanonyme: zhasha: Because I myself need it?
zhasha: for what?
nanonyme: Eh. For what it's designed?
zhasha: so you need to run apps on an other computer, but have it draw on yours?
adamk_: I do that all the time.
zhasha: but why?
nanonyme: zhasha: Yeah.
adamk_: Because I have various machines with X applications installed on that (mostly for backup purposes) but no monitor or keyboard.
adamk_: Why would I want extra monitors taking up room?
zhasha: it sounds like a "because I can" case
suokko: zhasha: campus licenses are fun with network transparent X ;)
suokko: So I can't install some special program to my computer because license woudl cost too much but I'm allowed to run it in university computer using ssh tunnel
adamk_: zhasha, Unless you are going to pay for the monitors and keyboard for those machines that I run X applications from, it's "because I have to" :-)
nanonyme: adamk_: Or volunteer doing recabling for you all the time when you need to use the other machine? ;)
suokko: And often some data is saved in one machine so it is easier to run application in that machine than transferring large amount of data to another
nanonyme: (which technically isn't that bad but if is quite a bit more hassle in the long run)
suokko: At least I'm very depend on ssh X tunneling :)
nanonyme: The funkiest use scenario of it I've seen is user terminals that don't allow local connections but only SSH and if you want to run anything graphical on it, it's going to have to be run on the other side of the tunnel. :)
nanonyme: But yeah, I'm pretty much confident the real solution will be able to do network functionality too as well as be an efficient desktop GUI system. If Wayland can't do that, Wayland isn't really the real solution. :p
nanonyme: It's not like there haven't been pilot ventures with the X server before that have died but given new ideas for the actual X.org stack implementation.
suokko: Google to rescue: NeatX
AndrewR: suokko, can you test xdemos/manywin 10? it hrd locks my computer in dri2 mode and gives [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at ca597748 in dri1 mode (rv280 agp card)
suokko: AndrewR: You have to run it with -s parameter
AndrewR: same wiith -s, in dri1 mode ... [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at ca5a9f48
suokko: AndrewR: and that is with my patch? I guess there is some bug state sizes then :/
suokko: I have to revisit them
AndrewR: suokko, one moment, i'll rebuilt mesa without your patches ...
zhasha: can X draw windows like microsoft surface?
zhasha: http://www.fahad.com/pics/microsoft_surface.jpg
AndrewR: suokko, yes, just mesa master works ....
suokko: AndrewR: thanks. I will fix that after I get r300 state sizes fixed
MNZ: zhasha, I doubt each photo is a window
zhasha: it's probably not, but could X do it as such
nanonyme: You're mostly asking whether it can rotate windows, right?
MNZ: X is incapable of drawing rotated windows I think, but an intermediate such as compiz can do the trick
nanonyme: MNZ: Not completely unexpected knowing the wobble effect. :)
zhasha: so it can be done
nanonyme: Actually I think I've even seen it done in an MPX demo once.
nanonyme: (the windows were rotated by with by moving your fingers, naturally)
zhasha: got a link to this demo?
nanonyme: Nope, I sadly have more of a graphical memory than a textual one.
EruditeHermit: zhasha: search youtube for MPX
zhasha: EruditeHermit: do it yourself and see how much non-multipointer-x you get
EruditeHermit: zhasha: the first video is MPX
EruditeHermit: and btw compiz already does rotated windows
EruditeHermit: its the "freewins" plugin
zhasha: but the "mpx demo" does not show any rotated windows
nanonyme: zhasha: http://www.youtube.com/watch?v=SSHQPDGuKnU There's at least that. Nowhere as cool as the one I saw though.
nanonyme: But yeah, it's obviously doable and usefulness percentage is about zero. :)
zhasha: nanonyme: not necessarily, if you have a large multi touch screen
zhasha: and XI2 capabilities
nanonyme: zhasha: That's exactly what the demo I saw was about.
nanonyme: Sadly no idea where to find it.
nanonyme: Some devs playing with the initial MPX support with XI2.
nanonyme: (or enthusiastics, whichever)
AndrewR: thinks all those multi-finger demos will work poor with many small objects on screen.. too fat fingers. (seriously, i can't imagine real non-sotting type of workloads with these things ...)
AndrewR: *non=sorting ...
AndrewR: ^(
nanonyme: AndrewR: Good point.
nanonyme: It makes more sense with touchpads than touchscreens, true.
nanonyme: (then again, touchscreens belong to a museum anyway, pun intended)
suokko: I hate evince search because it is so slow :/ Does anyone know pdf reader that has fast search functionality?
suokko: Searching register guide is surprising slow. It takes about 10 seconds which is unacceptable in my option
adamk_: I have no complaints with okular
suokko: adamk_: thanks. Okular is better
suokko: airlied: I think I caused kernel lock now so that I got at least a bit info what happened. I was running my hacked version of r300 mesa which probably has some state emit bug hidden there. Now I got probably GPU hang which caused IB scheduling failures form radeon_ib_schedule and radeon_cs_ioctl. This seems like blocking all disk access so whole computer is unresponsive except ssh connection which I had already open and active.
suokko: So is it possible that radeon is blocking with irqs disabled?
airlied: I doubt its irqs, probably blocked holding a lock
suokko: Also everything starting from hang has failed to write to disk (including the dmesg)
suokko: So I got to ssh terminal the drm error message but nothing was written to logs
nanonyme: suokko: New SSH connections probably wouldn't have worked either since it tries to read a few files at the beginning of the session? :)
terracon: someone needs a rebuttal to "Thom" at osnews
airlied: its probably blocking the gpu
suokko: nanonyme: yes. Only existing ssh worked. Also nmap failed to see the open ports
airlied: terracon: why?
terracon: airlied: well, did you read that article?
airlied: writing a rebuttal means we actually care what his opinion was
nanonyme: is seriously starting to love airlied's attitude towards events around him and hopes he learns it some day himself
terracon: it's not user per se. It's the unwashed masses that need the rebuttal
terracon: user = us
airlied: it would be great ot make X bulletproof, I'd prefer to make it work first though
nanonyme: Lucky you didn't use the word idiotproof since as we know, someone would just design a better idiot. :o
airlied: anyway he was running fglrx more than likely
suokko: airlied: Any more info that you would think would be useful? I guess first step would be prevent that gpu hang from locking kernel
terracon: nvidia actually
nanonyme: Even worse. :p
airlied: doubts nvidia would release a driver that tanks X on a window resize
airlied: fglrx actually had that issue
nanonyme: (as in, in terms of invasiveness)
nanonyme: airlied: You never know, they were releasing drivers pretty fast at one point. Sooner or later someone's bound to make a typo that blows everything up. :)
airlied: suokko: the stuff in debugfs any use or is it too late? what are you doing to crash it?
suokko: airlied: I was testing my reordered r300TryDawPrims with xmoto
terracon: hmm yes xpain. frustrating yet enjoyable
suokko: And I already lost functionality from ssh conenction so to oalte
terracon: suokko: did you know I'm Philip!!
suokko: It only worked for short moment and only for commands that probably were memory cached
airlied: sounds like some thread died holding a lock
terracon: after reading the comments he said it was a proprietary driver but I'm not sure if it was nvidia. Maybe I read that above. I'm not sure
suokko: terracon: no
airlied: I seen something similiar yesterday when doing
airlied: OQ
airlied: normally I just dump the IBs from userspace and see whats wrong
terracon: suokko: oh yes. Just look at all the fastest recording. Yes Philip. That's me, not
terracon: I might download some xmoto maps. Maybe there is one in there that I can actually compete
terracon: complete
suokko: airlied: So if yo utry to reproduce that it is good idea to have 2 ssh connections because one where I did run xmoto was dead from start (I couldn't kill xmoto)
airlied: suokko: sysrq-t might also help
suokko: I should learn to use sysrq.
suokko: airlied: dmesg had something interesting that I didn't notice from start of flood earlier http://nopaste.org/p/aWRYUjkSL
airlied: ah gpu reset failed
suokko: If I think carefully I might blame firefox for hanging the gpu ....
suokko: It has been many time focused when GPU hang happens
suokko: But it is not 100%sure blame
suokko: Often also hangs are related to heavy disk IO happening just before or same time
DanaG: PCI SATA controller == fail. I have one in my old desktop; it sucks.
DanaG: Or rather, the PCI bus sucks.
suokko: What is SATA in old laptop? :P
DanaG: Depends how old the laptop is.
DanaG: The desktop is an nforce2 with a SiI3112 chip stuck on the side.
DanaG: and yeah, it is "sii". odd. not "siL."
MostAwesomeDude: Silicon Image, IIRC.
DanaG: yup.
airlied: suokko: I have a CS checker for r100 mostly done, need to fix it up for r200 as well
airlied: that is useful for catching userspace doing stupid things
suokko: What about r300+?
MostAwesomeDude: airlied: I was thinking earlier about CS and performance...once things are super-incredibly-unbelievably stable, are some of the CS checks going to be disabled by default for speed?
airlied: suokko: it should already have one running ;-)
airlied: MostAwesomeDude: its possible, depends on if there is a major sore point
suokko: That was r500 card with rc6 kernel and cs checker didn't catch the problem
airlied: suokko: damn you must be doing something very special
suokko: airlied: Not much. Maybe only breaking whole rendering ;) http://nopaste.org/p/a9PRpMD07
airlied: you sure something in SetupVAP or shader setup doesn't require SetVertexFormat?
airlied: I'm not 100% sure
suokko: I'm not either but I was trying if that order would work. There is chicken-egg problem if that doesn't work.
airlied: bbl &
EruditeHermit: suokko: are you getting a hang on r300?
suokko: M52=X1300
EruditeHermit: when does it occur?
osiris_: suokko: there's a _mesa_bitcount function in mesa/imports.h
benh: agd5f: hoy
suokko: osiris_: I noticed the bitcount function after writing the code :)
benh: agd5f: any chance you can ask your fellow ATI folks what the "ATY,MRT" property is in the device-tree created by your "Mac" cards ?
benh: agd5f: there's also an "R2AD" prop
nanonyme: Hmm, I always thought it was the firmware on the machine that created the device tree... :) *shrug*
benh: agd5f: those stupid "mac" r5xx have no ATOM I can find
benh: nanonyme: not on PCIe cards
osiris_: suokko: if gpu reset fails for you try stopping X, then rmmod radeon -f && sleep 2 && vbetool post && sleep 2 && modprobe radeon
benh: nanonyme: the base tree is created by the firmware yes
osiris_: suokko: it works for me every time
benh: nanonyme: but PCI devices can have an OF "ROM" with f-code that modifies the node for the device
benh: nanonyme: adds properties etc...
nanonyme: Ah, right.
suokko: osiris_: stopping X caused my ssh freeze
osiris_: suokko: did you try SAK?
suokko: osiris_: no help. I tried it
suokko: Did you saw the dmesg?
osiris_: yes
suokko: [OT]Why none in phoronix remembers that modifying PHP code is simple? (EG results) :=)[/OT]
imranh: was anyone able to use Xv on a Macbook Pro. I get the "insufficient resource for operation" error when using VLC
imranh: has anyone had luck running xvideo on macbook pro?
suokko: imranh: https://bugs.freedesktop.org
[Enrico]: lol
simplexe: morning