spstarr_coding: i still can't help, never installed the thing ;/
jnoah1984: I prefer open drivers, so I thought I might as well help them along. :)
luke-jr: on computers I own, I run 100% Free
jnoah1984: But everyone starts some where and for me, at least I have programmed for years...albeit nothing like this though.
luke-jr: heh
luke-jr: I've hacked Linux onto a cable modem
luke-jr: that's the closest I've come to it IMO
jnoah1984: MostAwesomeDude, you will need gcc3.??
spstarr_coding: MostAwesomeDude: I don't know if *everything* that was added to XFree86 was bad, keithp was part of XFree86 before too, but there was enough bad ;)
spstarr_coding: MostAwesomeDude: DRI was in XFree86 :)
MostAwesomeDude: spstarr_coding: No, but there were a lot of bad calls which have had to be undone.
MostAwesomeDude: spstarr_coding: And now we're moving to DRI2 and KMS. :3
jnoah1984: KMS?
spstarr_coding: I still fail to see how DRI2 is the saviour, I only consider it a stepping stone for Gallium
MostAwesomeDude: Kernel mode-setting.
luke-jr: is upgrading xorg-server likely to fix my suspend issues?
spstarr_coding: kms however, is huge
airlied: spstarr_coding: DRI2 for the last time has *nothing* to do with gallium.
spstarr_coding: MostAwesomeDude: im not even sure kernel mode setting was discussed in the old XFree86 days, but maybe it was
spstarr_coding: airlied: i know
airlied: spstarr_coding: so its why do you insist on putting them in sentences together that make no sense?
spstarr_coding: its a different track, (one I still think we should just abandon until we move to gallium)
airlied: spstarr_coding: http://dictionary.reference.com/browse/orthogonal
jnoah1984: I have too many gcc versions intalled....
luke-jr: Gallium (pronounced /ˈgæliəm/) is a chemical element that has the symbol Ga and atomic number 3
airlied: spstarr_coding: doing DRI2 doesn't have any affect whatsoever on gallium
spstarr_coding: airlied: so there is no shared design in Gallium with respect to what DRI2 is trying to accomplish?
airlied: spstarr_coding: like I don't mind you specualting here but please try to restrain the outright falsehoods.
airlied: spstarr_coding: not a bit.
spstarr_coding: ok, that clears it up for me
spstarr_coding: airlied: the reason I asked that was if krh was designing DRI2 he must have had a reason vs getting on board in helping gallium out (if he is or not I dont know)
airlied: spstarr_coding: because RH want DRI2.
spstarr_coding: ah
airlied: we don't really care about gallium.
airlied: RH is all about moving the core infrastructure forward, so people can write drivers to use it, in some cases we push the drivers forward to show off the features we want in the core.
spstarr_coding: so do you think DRI2 will solve all the remaining design issues encountered vs DRI?
airlied: gallium isn't core infrastructure
airlied: gallium is just a replacement for the 3D driver in Mesa so far.
spstarr_coding: i thought the goal of that 'was' to become a core infrastructure
airlied: spstarr_coding: DRI met its design brief very well, we just needed something different for modern GPUs.
airlied: back when DRI was designed shared backbuffers were really the only choice.
airlied: since VRAM was limited.
spstarr_coding: airlied: now DRI2 is not just changing the GLX but also the DRI code in Mesa?
airlied: spstarr_coding: it doesn't change GLX, GLX is a separate protocol
spstarr_coding: I see
airlied: it might hook into the GLX code in one or two places but GLX doesn't need DRI or vice-versa in reality.
spstarr_coding: i see a glxdri2.c file which made me wonder
spstarr_coding: there's new structures, changes
airlied: thats the loader to load the 3D driver into the X server.
airlied: there are 3 loaders.
airlied: dri/dri2/swrast
spstarr_coding: right the software raster (CPU)
spstarr_coding: so if the changes of DRI2 are mostly internal to Mesa and not exposed to the GLX?
spstarr_coding: airlied: i guess what worries me about DRI in general is the race issues people encounter, where it's difficult trace things, its that level of design
airlied: spstarr_coding: its not difficult to trace at all, its just nobody bothered.
spstarr_coding: but isn't that getting us into the mess? if the core is sound we shouldn't be seeing this :/
airlied: most of the DRI code that talks to the 3D driver was re-written by krh.
spstarr_coding: oh!
airlied: Dri2 is based on the same interface
spstarr_coding: he totally rewrote it?!
spstarr_coding: man its a coding machine
airlied: spstarr_coding: he rewrote the loader a year or two ago
airlied: for the first DRI2 implementation
airlied: thats probably when the race appeared.
spstarr_coding: its->he's
airlied: AIGLX rewrote all that code
spstarr_coding: I only thought DRI2 was more or less an addon to what is missing from DRI, some additional internal structural changes
spstarr_coding: yeah krh did the AIGLX stuff, i remember this
spstarr_coding: that wasn't long ago either
spstarr_coding: ie DRI2 isn't a total rewrite of DRI but if it is.. ok
spstarr_coding: thats pretty big then
airlied: it just cuts down DRI to what we need for the modern systems, DRI isn't that big in the first place. DRI is only 13 protocol events
airlied: two of which are deprecated.
airlied: 2 more are just querys.
spstarr_coding: so then most of it is just structs all over?
airlied: dri is a protocol between the libGL and the X server
airlied: dri2 is just a replacement protocol that is better for modern needs
airlied: libGL talks to the X server, then the interface into the drivers needs to convey the messages.
airlied: so that is why the driver loaded changes.
airlied: dri2 is only 7 protocol messages.
spstarr_coding: but to convert from X11 representation to OpenGL the DRI is doing this?
airlied: nothing to do with X11 or GL
spstarr_coding: hmm
airlied: DRI2 is only dealing with drawable and buffer management between the direct rendering client and the X server.
airlied: and authentication
airlied: as was DRI1
spstarr_coding: but don't we want the kernel to do all buffer management and not userspace?
spstarr_coding: or is this GPU buffer specific
airlied: spstarr_coding: see there you go missing the point again.
spstarr_coding: ie r300 buffmgr code
airlied: if you have a client rendering to an X server, they need to talk to each other.
airlied: so if you have compiz wanting to use a pixmap as a texture, X needs to be able to tell the client driver what the shared handle is
airlied: so the compiz process can access the object containing the pixmap data.
spstarr_coding: so that is the drawable?
airlied: all DRI2 really does is pass the drawables and associated buffer handles
airlied: http://cgit.freedesktop.org/xorg/proto/dri2proto/tree/dri2proto.txt
airlied: actually explains it all
spstarr_coding: looking, when I remember debugging the race or trying to, i just ran into so many structures for drawables, contexts, GLXContexts, DRIContexts...
spstarr_coding: i know they are there to keep track who has what
airlied: they are just different wrappers for mostly the same thing depending on what piece of the stack you are in.
spstarr_coding: so then shouldn't they have been merged into a common structure shared?
airlied: nope as they are opaque in some places and just passed around as handles.
spstarr_coding: ok
airlied: some parts are private to some parts of the stack etc.
spstarr_coding: well i see a lot of casting
spstarr_coding: airlied: is there any checking being done on the pointers coming and going?
spstarr_coding: 'No errrors defined by the DRI2 extension.'
airlied: spstarr_coding: you have some pointer validation code for C? how does that work?
spstarr_coding: well, if you know the pointer you could store the pointer addresses in an array somewhere
spstarr_coding: then compare against a list of known pointer allocations
spstarr_coding: if its not, you know its a bogus pointer
airlied: spstarr_coding: and? what does that get you?
airlied: spstarr_coding: you still don't fix the bug.
spstarr_coding: well, maybe a safer way to abort without blowup?
airlied: spstarr_coding: it won't fix the problem though.
spstarr_coding: and instead throw a nice stack trace to X log showing the code path you got there with somehow
airlied: papering over it with a proper abort provides less info than the backtrace.
airlied: we have a nice stack trace.
airlied: you gave it to us
spstarr_coding: from gdb, but it doesnt tell me why someone destroyed it and not tell anyone
airlied: spstarr_coding: valgrind would tell you what codepath destroyed it
airlied: it normally says blah accessed memory, which was freed at blah2
airlied: with stack traces of blah and blah2
spstarr_coding: i thought we tried valgrind before... or maybe not?
airlied: spstarr_coding: the thing is you don't need anymore info to fix the bug.
spstarr_coding: why is that?
spstarr_coding: the stack from gdb didnt tell me the code path that showed where it got destroyed if that happened elsewhere in time
airlied: you know where the pointer is being accessed illegally, you know where the code frees that pointer, two printfs should be enough to see
airlied: a) free 0xpointer b) accessing 0xpointer
airlied: the free path is probably always going to be the exact same...
spstarr_coding: looking at trace now
spstarr_coding: dixLookupPrivate shows privates set to 0x15c which is bogus
spstarr_coding: #11 0x006a02d7 in ContextGone (cx=0x15c, id=20971551) at glxext.c:98 shows a bogus pointer
spstarr_coding: airlied: what is confusing to me is how is this being passed around and ending up in private
spstarr_coding: someone is calling ContextGone with badness in the first place
airlied: 0x15c is just an offset from a NULL pointer
spstarr_coding: right
airlied: so something is using a null pointer.
airlied: and pulling a struct member from it
spstarr_coding: right
spstarr_coding: so then if this is simple I should be looking at who is calling ContextGone
spstarr_coding: since we see the bad pointer at this instance
spstarr_coding: __GLXcontext* cx
spstarr_coding: so a corrupt __GLXcontext
spstarr_coding: but ContextGone's stack shows __glXFreeContext and a correct __GLXcontext structure being destroyed
spstarr_coding: thats why i cannot understand how thats a bogus pointer when the pointer being destroyed within ContextGone's callto __glXFreeContext (is right)
spstarr_coding: i could understand if it was being passed to __glXFreeContext with the same bogus pointer, but it's not
spstarr_coding: glxext.c: __glXContextRes = CreateNewResourceType((DeleteType)ContextGone);
spstarr_coding: scratches head on the 'Create' part of that routine
spstarr_coding: if I look confused it's because the name contradicts what the function pointer being passed in is doing
airlied: that creates a client resource that gets freed when the client dies.
airlied: it'll get freed by calling ContextGone
airlied: in order that X can free things when clients die uncleanly it uses resource types.
spstarr_coding: hmm
spstarr_coding: it almost seems like the structure of this code could use some modernization, like kernel has register/unregister struct ops
airlied: spstarr_coding: not really... its jut C code.
spstarr_coding: ok so since calling CreateNewResourceType this will call ContextGone
airlied: it will call ContextGone when the client exits.
airlied: or dies.
spstarr_coding: so where does that get us? we know it either dies or exits, I know when you enable/disable kwin composite, the client is going to exit
spstarr_coding: and client i assume whatever initiates the GLX from client side (kwin)
rmh3093: airlied, any chance you can make your mesa repo use latest dri2proto
spstarr_coding: airlied: that's where im stuck, I don't know if this stack is a result of an abnormal exit, or a proper exit not handled
spstarr_coding: airlied: if the function pointer is being passed in then wouldn't CreateNewResourceType's call to the function pointer to ContextGone have to pass in arguments?
spstarr_coding: given ContextGone requires a __GLXcontent * and an XID
spstarr_coding: funcs = (DeleteType *)xrealloc(DeleteFuncs,
spstarr_coding: (next + 1) * sizeof(DeleteType));
z3ro: rx__: so does that ubuntu fglrx supposedly work with xorg 1.5?
spstarr_coding: wth
spstarr_coding: static DeleteType *DeleteFuncs = (DeleteType *)NULL;
spstarr_coding: its NULL
spstarr_coding: + offset
spstarr_coding: airlied: what its passing in is a bogus pointer (although I dont see where the ID is coming from yet
z3ro: spstarr_coding: take a look at the realloc man page. realloc can accept a NULL pointer.
spstarr_coding: z3ro: thats ok, but where is id coming from
spstarr_coding: #11 0x006a02d7 in ContextGone (cx=0x15c, id=20971551) at glxext.c:98
spstarr_coding: the function pointer passes no XID in
spstarr_coding: the call is only setting the first argument(?) to NULL+offset (0x15c)
spstarr_coding: z3ro: https://bugzilla.redhat.com/show_bug.cgi?id=445331
spstarr_coding: its baffling me because cannot seriously track how thats possible
spstarr_coding: now unless XID is static somewhere
spstarr_coding: FreeResourceByType would have to be passing it to the function pointer
z3ro: hmm I'll take a look as soon as the bugreport loads...
z3ro: damn useless dsl
spstarr_coding: heh
spstarr_coding: it is
spstarr_coding: (*DeleteFuncs[type & TypeMask])(res->value, res->id);
spstarr_coding: fine we establish res->value = 0x15c and res-id= 20971551
spstarr_coding: that doesnt explain how __glXFreeContext all of a sudden gets a valid __GLXcontext pointer
spstarr_coding: nor does this explain how the pScreen passed is bogus
spstarr_coding: getDrawableInfo
z3ro: hmm I'm not sure. it's hard to debug this kind of thing without actually being there with gdb yourself.
spstarr_coding: I should note, DRI2 has no routines like this.. :)
spstarr_coding: i see none of that in http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxdri2.c
spstarr_coding: airlied: you know, DRI2 will make this likely go away
spstarr_coding: will -> 'might'
spstarr_coding: its a different code path, getDrawableInfo is gone
spstarr_coding: the way drawables are being handled in DRI2 look much different
spstarr_coding: oh
spstarr_coding: dri2GetBuffers ~= getDrawableInfo
spstarr_coding: so technically DRI2 might also have the race.... speculating
marcheu: dude, stop somking pot. there is no race in DRI, it's a bug in your driver
spstarr_coding: marcheu: well, im not so sure
spstarr_coding: whatever getDrawableInfo void *data is being passed into (callback) is garbage
spstarr_coding: its crashing because the pScreen being set is garbage
spstarr_coding: pScreen = drawable->base.pDraw->pScreen;
spstarr_coding: this we know from the stack
spstarr_coding: how exactly do you debug callbacks in X
marcheu: with gdb
spstarr_coding: breakpoint?
spstarr_coding: if I set a breakpoint will gdb show me a back trace with bt f?
marcheu: yeah, how else ?
spstarr_coding: showing who initiated the callback?
marcheu: if you have debug info...
spstarr_coding: yes
spstarr_coding: well then, let's try it.. i have the symbols now
spstarr_desk: ok set
spstarr_desk: data=0x8bb65b0
spstarr_desk: examines
spstarr_desk: oh nice
spstarr_desk: im used to IDE debuggers ;p
spstarr_desk: i want to have gdb print that pointer casted
spstarr_desk: marcheu: how do I get gdb to show me the contents of a structure from the pointer?
spstarr_desk: the value passed in is a generic pointer
spstarr_desk: installs ddd
spstarr: hmmmmmm
spstarr: no corrupt pointer
spstarr: ?
spstarr: airlied: im watching the data pointer and its not bogus... (remember that trace was before the mega cleanups you've made in drm
spstarr: enable/disable composite not locking up
spstarr: so then, time to debug why VT switch locks up..
spstarr_desk: airlied: VT switch locks up because of an ioctl wait
MrCooper: marcheu: there's certainly a bug in glxdri.c: it keeps a pointer to a DrawableRec but doesn't make sure it stays valid
spstarr_desk: MrCooper: i can't seem to reproduce that issue anymore
spstarr_desk: MrCooper: what I can reproduce is VT switching will crash X/lock X, but not lock system, the GPU is not dead
spstarr_desk: MrCooper: almost seems that we're not releasing the DRILock on vt switch back
spstarr_desk: MrCooper: do you think that bug (if an issue) exists in the DRI2 loader ?
MrCooper: no idea
spstarr_desk: hmm, ok
z3ro: load average: 5.99, 4.59, 3.59
z3ro: damn I really should get my opteron going again.
glisse: airlied: btw what's your plan for gem/mesa ? using my branch or bufmgr branch ? just so i don't waste my time
airlied: glisse: well I'd like to see what nha wants to do :)
glisse: airlied: bufmgr asbtraction doesn't fit cs
airlied: glisse: he has kept his branch passing piglit etc, whereas my efforts were always regressing.
airlied: but I suppose if you get yours working we can bash it back into shape :)
glisse: well piglit hit the hdp cache
glisse: otherwise i got piglit working
airlied: I must re-test all that, I just disabled hdp in Fedora.
airlied: I was going to just flush it on map
glisse: still openarena mess with polygons a little bit like a new bug report i saw on mesa head
glisse: yup there is a flush bit in hdp reg
glisse: i think we should write it on map
glisse: should be enough, the trick of writing in bufmgr is just a workaround for this cache
airlied: I started playing with it, then saw tcore disables the cache.
glisse: well tcore doesn't care much about perf :)
airlied: yeah I just wanted to rule it out of some issues I'm seeing for now.
glisse: it's about getting hw do somethings with the safest path :)
airlied: I'm still getting EXA pixmaps with the VRAM zeroing in them when they should have data.
airlied: I've no idea where its failing.
glisse: you zero with a blit ?
glisse: or with memset
airlied: blit.
airlied: blit + flush + wait + fence
glisse: hdp shouldn't interfer here
airlied: yeah I was removing everything I could...
airlied: it may be my clean flags or something...
airlied: I
airlied: I suppose I should try porting the DDX to bo/cs
glisse: maybe offset computation is wrong in the blit
glisse: so it zero at some others place, i really don't see anyothers way
airlied: yeah its very random though..
glisse: even if you read back from cpu with hdp cache only first few dwords might have stalled data
airlied: glisse: yup... this is much worse than that.
glisse: has cache isn't that big
glisse: so i think you can rule out cache
airlied: yup even dst cache barely explains this, I'm hoping all flushes before coloroffset0 changes are okay.
glisse: fglrx flush pipe (write to one sc & z reg)
glisse: then flush cache and wait for idle
airlied: must dig out my revenge traces.
airlied: I also made my tree do commit rounding, need to push that
airlied: dang on other laptop.
airlied: will push in morning.
airlied: glisse: you going to add aperture checking?
glisse: in cs kernel side ?
airlied: in the libdrm
glisse: oh there is somethings in the legacy code in mesa for this
glisse: it only count texture size heaps
airlied: yup I've done it only for VRAM in my DDX code.
glisse: as i am unsure how to do it in cs/bo yet haven't done any code for it
airlied: my r300-bufmgr-fedora branch has it for legacy.
airlied: also the fix if we can't actually fix all the textures in to fallback to sw
airlied: anholt has done Intel to submit if it reaches referencs to 3/4 of their aperture size
airlied: we could probably do something similiar for VRAM and aperture
glisse: airlied: yup in my legacy i submit if relloc > textureheapsize-1M
airlied: christ cgit is slow.
airlied: so as long as you don't emit a 1MB buffer at the end you'll be safe :)
glisse: yup 1M seemed fine as first approx
airlied: really you need to do those in advance so we can fallback without a problem.
airlied: esp for textures if they are bigger than VRAM.
glisse: well the problem is how fallback is handled in mesa
airlied: well I just returned to the swrast
airlied: http://cgit.freedesktop.org/~airlied/mesa/diff/?h=r300-bufmgr-fedora&id=576ee3db94bd79092fe7f69b4ac8293367b6dfb1
glisse: btw non tcl path is broken for me
airlied: it should be okay, what bits are broken?
glisse: well mesa head if i for non tcl i got only garbage on screen
glisse: haven't tracked down what is the culprit
airlied: wierd, r300-bufmgr-fedora works fine on non-tcl at least for gears
airlied: I run it on my rs690.
glisse: i run it on card with tcl :)
airlied: I'll see if I can some time to test your branches...
airlied: so we can get DRI2, I might try a DDX port as I can compare it with the code we have now a lot easier.
glisse: also i got ddx dri2 bits here, i need to push them
glisse: well it's not big code
airlied: glisse: based on bo/cs/?
glisse: no it use the current ddx code
glisse: but there is few thing in ddx which are broken
glisse: as flink
airlied: how can that do DRI2? do younot need handles for exa pixmaps?
glisse: i mean it use kms branch
airlied: ah cool.
glisse: so it has bo/cs but not using the interface i done in libdrmradeon
airlied: is there a radeon_cs_gem.c?
glisse: i started dri2 with bufmgr at the time
glisse: still there is a couple of change in ddx to not forget about flink name and few things like that
glisse: can't remember
airlied: glisse: uggh exit if dma_alloc fails :)
glisse: yup
glisse: :)
glisse: the idea was to never go that path
glisse: as it wait for previous buffer to be free
glisse: if previous buffer never free then we are in a lockup situation
luke-jr_: well, that -r1 for xorg-server didn't fix anything
luke-jr_: :x
spstarr_work: glisse: any DRI2 stuff I can test from git yet? even if its limited
spstarr_work: otaylor: if you switch VTs with composite on w/ rv350 and not use kms will it wedge?
spstarr_work: or will X crash
otaylor: spstarr_work: would rather not wedge at the moment
spstarr_work: :)
otaylor: spstarr_work: generally running compiz hasn't been very stable for me, even without kms
otaylor: spstarr_work: but that may be better now ... haven't tried in a week or so
glisse: spstarr_work: dri2 won't happen until i fix openarena
spstarr_work: well, I can use composite more now, even enable/disable it without it blowing up, but i cant VT switch
glisse: so until i got some time to look at that
spstarr_work: glisse: do let me know, I want to see if DRI2 has the same code path issue im triggering or not
glisse: at least won't happen on my branch
rmh3093: wine does not render things properly i just notices with the kms driver
rmh3093: does anyone know how to disable agp with the kms driver?
tlp: I suppose I'd need to rebuild my Ubuntu Intrepid kernel to test out kms, eh?
tlp: pings spstarr_work
spstarr_work: hmm?
spstarr_work: rmh3093: radeon.agpmode=-1
rmh3093: tlp, you can pull from my kernel, it has kms on .28-rc3
spstarr_work: will go to PCI mode
rmh3093: spstarr_work, no no
rmh3093: thats not what i mean
rmh3093: i want to compile my kernel with out agp
glisse: rmh3093: iirc you can't
rmh3093: but the drm module is complaing about missing symbol
glisse: that's why you can't
glisse: drm/radeon depend on agp
rmh3093: glisse, there has to be a way to ifdef that properly
rmh3093: this part return drm_agp_init_ttm(dev);
rmh3093: is what is the problem
rmh3093: does #ifdef CONFIG_AGP work for =m and =y or just =y
luke-jr_: http://pastebin.com/m7f5c2186 <-- help plz ☹
glisse: luke-jr_: nothings to do with radeon likely x input problem if you build your xorg clean and rebuilt it with lastest input bits
rmh3093: glisse, http://rafb.net/p/R1Cl6e48.html
luke-jr_: eh, why would it be input?
rmh3093: why wouldn't something like that work
luke-jr_: this same version runs fine on 2 other systems
luke-jr_: I can't see input being different, input is pretty standard
glisse: rmh3093: because agp is referenced in many others place
glisse: luke-jr_: xorg input code is under heavy rework
rmh3093: glisse, if it was referenced in other places wouldnt i have more undefined references
glisse: likely, but you never know what kind of stall build files might lay around in your tree
rmh3093: brb, want to reboot and test this
rmh3093: glisse, it seems to be working fine and my dmesg is clean, i just removed eveything from my kernel dir and will now checkout a clean copy, and reboot on that, but it think that ifdef will be fine
tlp: rmh3093: ah, k, I'll look into it this evaning.
glisse: rmh3093: i always have low expectation but it seems others place already got agp config ifdef section
rmh3093: tlp, i just cant confirm that it works for the case when agp is a module
rmh3093: cause i dont have an agp card
tlp: does
rmh3093: but i built it as a module
rmh3093: and it worked
luke-jr_: glisse: yeah, but the same code is used for input everywhere
glisse: luke-jr_: i don't understand what you mean
luke-jr_: everyone using X.org will be using the same input drivers; the liklihood they're malfunctioning so often is slim
luke-jr_: mice and keyboards don't vary much like video cards
glisse: luke-jr_: well my point was that if you built your xserver yourself you might have built with mismatch input component or while it was in a broken state
glisse: so you should update and clean build it
glisse: and the message in your log as nothings to do with the graphics stacks it's somethings in events queue
luke-jr_: glisse: it was clean built
glisse: cleanly building X is tricky especially if you dev package on your system :)
rmh3093: glisse, im gonna test this ifdef in my kernel tree and see if anyone bitches about it
rmh3093: i just got 11 3 second stalls
rmh3093: started openoffice
rmh3093: and it recovered a bunch of docs i had open
rmh3093: and it stalled for each new window
rmh3093: heh
luke-jr: glisse: emerge xorg-x11 is pretty clean
glisse: luke-jr: well i guess gentoo handle all the pain for you :)
glisse: still this message doesn't look related with ddx at all
fat_chris: luke-jr, did you install xorg-server-1.5.2-r1 in the end?
glisse: try to emerge the mouse or keyboard driver
luke-jr: fat_chris: yes
fat_chris: i take it that it didn't kill kittens :P
luke-jr: fat_chris: didn't help anything either
luke-jr: so what do I try now?
fat_chris: is it still the same problem?
mcgreg: do a radeon 4850 or a radeon 4650 models work with radeon driver? with or without 2d acceleration? perhaos xv (textured video)?
mcgreg: considering to get such a nice card but I would like to know how good they will work with the radeon driver
luke-jr: fat_chris: AFAIK
luke-jr: the log stuff is only maybe 20% of the time
luke-jr: most often, there is nothing in the log
luke-jr: mcgreg: I would expect 3D acceleration these days, though 4[68]50 don't look like Radeon models..
tlp: what are those? r5xx?
mcgreg: R7x0 as afr as I know
tlp: ah
tlp: there is no 3D accel for those, AFAIK.
luke-jr: didn't realize r7x0 existed
tlp: there is acceleration for R5xx and below, with r6xx in the pipe (I think)
tlp: however, it's still not quite on par with fglrx in my experience, at least with r5xx.
mcgreg: tlp: I really didnt ask about 3d :) but I asked about textured video and 2d acceleration ;)
tlp: oh, right :p
tlp: I forget there are other things sometimes, since those always seem to work.
mcgreg: tlp: currently 3d on my current r500 (x1300) seems to be quite broken here
mcgreg: dunny why
mcgreg: it used to work fine
mcgreg: montsh ago
fat_chris: i think r600 and above require 3d for 2d to work
luke-jr: Accelerated 2D*
fat_chris: they need 3d for 2d acceleration though
fat_chris: so just wait a while for 3d
mcgreg: well, that also not THAT important ;) the most important part is , would they generally work? -> 4650 and 4850?
mcgreg: since I believe I've read somehting on phoronix that 4650 would have problems?
mcgreg: even iuf fglrx is superior in most cases it caused me a lot headache before the oss radeon driver... so I still wouldn't loike to use it
otaylor: mcgreg: If you only want to use free drivers, then you'd be better off buying the cheapest r500 you can get (a 1650 say), using that for 6-9 months or so until the newer cards are supported, and then buying a (by then cheaper) r4xxxx
mcgreg: otaylor: hmm well, thats wasn't my point ;) I am indeed also using other operating systems which can use the 3d capabilities of the 48/650. I am just using linux for mostg stuff, except for a few games that requite "fast" 3d. so I really just want it to work generally on linux. the most important feature would be textured video for xv. everythign is is optional :)
otaylor: mcgreg: AFAIK, you can get dumb frame buffer level perfomance on a 4[68]50 with free drivers right now and that's about all
mcgreg: ok , that's what I wanted to hear (actually not, I hoped it would be supprted a little better)
mcgreg: but I think I could live with that, for a little while ;)
Beuc: Hi, I'm under Lenny, and I just installed a new radeon card. It works fine, but I'm surprised to see that the font rendering changed (the size isn't the same). Do you know what is causing this?
tlp: maybe the font changed.
tlp: I noticed that too
tlp: (on Intrepid)
Beuc: I took a screenshot before and after plugging the card, at 15' interval though
Beuc: so the rest of the system didn't changed at all
otaylor: Beuc: reported dpi can affect font size, card can affect the ability of the system to get the dpi from the monitor
Beuc: I'm about to replace a client's nvidia with a radeon 9600, but it this changes the font size and messes their openoffice documents layouts, this isn't gonna work ;)
Beuc: otaylor: I see. Is there a way to configure this?
otaylor: Beuc: what desktop env?
Beuc: otaylor: it's Gnome
otaylor: Beuc: version?
Beuc: checking...
otaylor: Well, doesn't really matter
otaylor: Either in Font Properties or Appearance Properties depending on the version
Beuc: I'm using 2.22.3 but the client is using 2.14
otaylor: go to the font settings, click on the dpi, change to 96 (yes, it may already look like 96, change it, change it back)
otaylor: Beuc: OK, for your client, things will be OK, dpi in gnome 2.14 ignored what the monitor reported
Beuc: Cool, it's was 105
Beuc: Thanks, it's still good to know since they'll upgrade eventually.
Beuc: 96 still isn't the previous value though, I'll fiddle with the value
Beuc: Apparently I get the same rendering with 98dpi. Ah, the joy of fonts :)
Beuc: Or rather 101 but that doesn't matter. Thanks for the tip :)
Erektium: do I have to make an Option "gartsize" to xorg.conf? and if I have to how much?
jnoah1984: z3ro: did your question about the Ubuntu fglrx driver get answered? If not, the answer is yes. There is a tarball as well if you want to use it to make a kernel for yourself to try. (Requires {as far as I can tell} gcc3.4 and it won't build with gcc4.xx)
jnoah1984: z3ro: linky to tarball http://archive.ubuntu.com/ubuntu/pool/restricted/f/fglrx-installer/
logari81: Checking for texture_from_pixmap: not present. what does this mean on X1600 after migrating from fglrx to radeon, Xserver 1.5.2 ?
airlied: logari81: wrong mesa or mesa not loading correctly.
adamk_: logari81, It means you're drivers are not working properly...
adamk_: Or installed correctly.
adamk_: logari81, Go to http://pastebin.ca/ and paste in the ouput of 'glxinfo'
logari81: I have already advised the user to reinstall mesa packages, try to get his glxinfo
logari81: * I will try
spstarr_work: airlied: any bits to test today?
spstarr_work: nothing on koji, then no :)
logari81: for the moment I have this one http://www.pastebin.ca/1245251
adamk_: logari81, Yeah, that's not right.
adamk_: The opengl vendor should be "DRI r300 Project"
logari81: adamk: aha
logari81: and the solution?
adamk: logari81, Install the drivers correctly
adamk: It's hard to give any more guidance without more information.
logari81: adamk: you mean the following packages libgl1-mesa-glx libgl1-mesa-dri ?
adamk: logari81, If we're talking about Ubuntu here then, yes, those are the correct packages, I believe. Only for Ubuntu 8.10 of course.
logari81: adamk: this is his full glxinfo http://www.pastebin.ca/1245253
logari81: yep I m talking about Ubuntu 8.10 of course
adamk: logari81, We'd need to see his /var/log/Xorg.0.log file now,too.
logari81: adamk: here it is http://www.pastebin.ca/1245271
logari81: sorry for the inconvenience, the lag is because I have to ask for this info first
logari81: after the upgrade from 8.04 there are many people having problems with fglrx, and try to migrate to radeon
nulleke: logari81: are you sure the fglrx isn't being used anymore ?
nulleke: [dri] radeon.o kernel module version is 8.54.3 but version 1.17.0 or newer is needed.
logari81: nulleke: oops, I see
logari81: could I check for a specific .so library to see if fglrx left something behind?
nulleke: try to see if the fglrx kernel module is not loaded with lsmod
logari81: nulleke: you are right
logari81: after correctly removing fglrx, everything is ok with the X1600, except this one:
logari81: (EE) RADEON(0): Unable to reserve offscreen area for back buffer, you might experience screen corruption
adamk: logari81, Do they experience any screen corruption?
logari81: adamk: nothing reported up to now
logari81: I assume it wokrs fine
gentoofu: logari81: try EXA
rmh3093: airlied agd5f glisse ping
rmh3093: tlp, i have a different version of that patch for your
agd5f: rmh3093: pong
rmh3093: agd5f, the kernel code needs this patch for drm to compile as a module
rmh3093: http://gitweb.zen-sources.org/?p=kernel/zen.git;a=blobdiff_plain;f=arch/x86/mm/pat.c;fp=arch/x86/mm/pat.c;h=9731aee75979abeab32662cfd68675bf9738c492;hp=eb1bf000d12e9b1aa1769284e263d43593095183;hb=aa71480e28ac9b34d9f2bd42dbf9edc1ee3af0f6;hpb=507d577701ca53b3752d52a005bbbbde6729cd58
airlied: rmh3093: is that not in my drm-rawhide tree?
rmh3093: airlied, no its not
airlied: wierd I'm building as a module, I wonder why it doesn't give out.
rmh3093: airlied, and i think this patch should let drm build with out agp
rmh3093: http://gitweb.zen-sources.org/?p=kernel/zen.git;a=blobdiff_plain;f=drivers/gpu/drm/radeon/radeon_buffer.c;fp=drivers/gpu/drm/radeon/radeon_buffer.c;h=2abf7ba928160bbd3348105e63a82d70b9fb4fc8;hp=f047b1aca3319e872a040d9e72d8d6f2e722f445;hb=507d577701ca53b3752d52a005bbbbde6729cd58;hpb=394936ec16fc96e58e9f68c999552ed530e56c87
jcristau: gitweb urls ftl..
airlied: rmh3093: we have a shorthand called __OS_HAS_AGP
airlied: or something like that.
rmh3093: i will try that out
rmh3093: airlied, when i use #ifdef __OS_HAS_AGP I get drm_agp_init_ttm undefined
rmh3093: i dont think that works
airlied: #if __OS_HAS_AGP
airlied: not ifdef.
rmh3093: ahh
rmh3093: yeah that works
rmh3093: airlied, but what happens if someone has agp but does not want to build agp support
luke-jr: confirmed my issue is video
luke-jr: on a hang, the FPS thing stops moving
luke-jr: also, if I SSH in, I cannot chvt
airlied: rmh3093: you have AGP and you want the kernel to magically dirver a gpu with no support?
rmh3093: airlied, what if the mobo has agp and pci/pcie
airlied: rmh3093: then you don't get the agp paths run, the code shouldn't rely on agp paths at all.
airlied: though I think that might not always be well tested config.
rmh3093: airlied, w/ regards to the pat issue, i am using .28-rc3 not .27-* like your tree, if that makes any difference
airlied: oh wow evince gotes a lot faster with an uncached page allocator
airlied: until I get a wierd oops.
airlied: hopes thats ftrace fault...
jnoah1984: airlied, glisse, or anyone who knows. Does the r350 hardware support Shader Model 3? Forgive me if this is a n00b question.
airlied: wonders what that is... GLSL?
airlied: it doesn't really, fglrx just does it in sw.
rmh3093: airlied, i am getting those freezes a lot today, always when opening new or minimized windows and usually when making lots of mouse motions
airlied: rmh3093: they are wierd. I can't make them happen when I want them :)
airlied: I know what they are but have no idea why they trigger.
airlied: I'm so far guessing some race condition on the TTM fence code and irq handler
airlied: we miss the race, 3 sec timeout.
rmh3093: i cant wait for this to be fixed ;) its my only major issue
airlied: rmh3093: try running evince and seeing how slow it is :)
rmh3093: emerges evince
airlied: but I have a fix for that its just reusing uncached pages properly.
luke-jr: a fix for me?
rmh3093: airlied, evince was fast as hell
airlied: my scrolling in it sucks :)
[TiZ]: Hey, uh... HyperZ. It's not appearing in driconf for my ATI Radeon Xpress 1150. I'm on Ubuntu Intrepid, using the drivers that came with it. Is Xpress 1150 supposed to have HyperZ?
airlied: I don't think we have any support for it
luke-jr: wtf is HyperZ?
[TiZ]: http://en.wikipedia.org/wiki/HyperZ. And I saw some blog entry while I was arbitrarily browsing, that one could enable HyperZ in driconf on cards from Radeon 7000 to 9700.
MostAwesomeDude: HyperZ is ridiculously fast Z buffer clearing. It's only supported on the r200 series though.
[TiZ]: Aw drat. I think Xpress 1150 is r400. I know it's definitely not r200.
luke-jr: [TiZ]: Xpress 1150 is not 7000 to 9700
chithead: xpress 1150 is derived from x300
[TiZ]: Then that's way ahead of that range.
[TiZ]: Thanks for clearing that up, guys. Great work on this driver, btw. It needs to be said. :)
MostAwesomeDude: At some point HiZ support should be done, but it's not high up on anybody's list.
jnoah1984: I'm building a kernel that will allow me to build the fglrx8.54.3 module right now. So a little later on and a restart I will be able to get run revenge in xserver 1.5
MostAwesomeDude: jnoah1984: I'm still havin' no luck with fglrx. Would you mind running a few dumps for me later?
jnoah1984: MostAweomeDude, did you build a kernel with gcc3.4?
jnoah1984: (sure)
jnoah1984: airlied, glisse, what are DDX, and bo/cs?
airlied: jnoah1984: DDX is the 2D driver, xf86-video-ati
airlied: bo is buffer object (which is new buffer manager code)
airlied: and cs is command submission
P5YCH0: 4850 stuttering games
P5YCH0: just got it
P5YCH0: wtf?
MostAwesomeDude: P5YCH0: No acceleration for the HD 4850 yet, sorry.
jnoah1984: airlied, thanks for the info
P5YCH0: NO WHAT?
P5YCH0: i'm wondering why am i getting stutters
P5YCH0: in games
P5YCH0: am i suppose to go to the s tore and return the product i purchased from ati and tell em
P5YCH0: i would like to use it but i cant because of ERRORS so there fore i am not going to?
P5YCH0: or is there a soultion
P5YCH0: hello?
P5YCH0: am i DEFIANT BEcause i am nO fanATIc?
P5YCH0: just ignore the problems huh
P5YCH0: u fuckin NOOB
P5YCH0: how baout I TROLL YOUR ASS
P5YCH0: of the net
P5YCH0: u fuckin bitch with a operator status
P5YCH0: fuckin Dick sniffing
P5YCH0: noob
P5YCH0: some fuckin help chan
P5YCH0: noobs
airlied: I love the internet.
MostAwesomeDude: Kinda surprised he left peaceably.a
MostAwesomeDude: Well, for certain values of "peaceably." :3
airlied: its was mainly his abuse of capitals I kicked him for.
airlied: people on the Internet need to learn how to write sentences.
MostAwesomeDude: I never noticed "fanATIc" before. Huh.
robokopp: neat :)
rmh3093: airlied, my mouse + gnome taskbar + click = stall
rmh3093: about 40%
rmh3093: of the time
rmh3093: lol
rmh3093: it cant believe its so hard for you to trigger
jnoah1984: hey, trying to build 8.54.3 as soon as I restart, brb
airlied: rmh3093: what hw you on?
airlied: I've gotten one this morning :)
rmh3093: m56
rmh3093: airlied, i enabled gnome composite-manager in gconf
rmh3093: im not using compiz
rmh3093: if that is useful
airlied: ah maybe metacity composintg makes it easier to get.
rmh3093: maybe
jnoah1984: lol sad. I have to rebuild a few packages first... Once they are done I will try fglrx 8.54.3 and run revenge.
airlied: &
luke-jr: so anyhow
luke-jr: whoever was claiming my lockups were not video related
luke-jr: with DRI disabled, I have not had any more lockups…
luke-jr: but this is painful to use :/