Ronis_BR: man, with radeon, half-life in wine is just unplayable :(
Nightwulf|work: hi all
mjt: um. confused again. radeon vs radeonfb for a console: how they "relate" to each other?
edwin: you can only use one
edwin: need to disable the other one
mjt: it appears that loading radeonfb after radeon is loaded has no effect
mjt: didn't try the opposite
edwin: in fact if you load radeon.ko, and fbcon.ko you get a graphical console with KMS
mjt: but basically, radeonfb is useless if radeon is here, rigth?
mjt: but radeon console is slooow :)
mjt: and radeonfb at least had a way to specify video mode, while radeon does not
edwin: doesn't fbcon take some params?
airlied: yeah radeonfb is deprecatde
airlied: mjt: radeon does
airlied: mjt: video=
airlied: on the commandline
DanaG: hmm, I hadn't expected that.
mjt: $ ls /sys/module/radeon/parameters/
mjt: agpmode benchmark dynclks modeset no_wb test vramlimit
mjt: audio connector_table gartsize new_pll r4xx_atom tv
DanaG: I was used to the syntax video=uvesafb:mode_option=
DanaG: but saw no comparable parameter for radeon.
mjt: there's no such parameter :)
DanaG: so video=radeon:mode=
mjt: DanaG: it's kernel vs module parameter
mjt: or am i talking about something different?
airlied: its not a module parameter
DanaG: ah, an unexpected change in syntax.
mjt: one of our machines can't use radeon module because the monitor (oldish CRT) does not support the mode it is switching to
airlied: hmm video= as always eixsted
mjt: so i have to specify video mode.. but i didn't know how
mjt: DanaG: it were vga= probably, no?
mjt: um. still confused... :)
mjt: actually my main question was how to stop two screen clearing that are happening during boot: first whhen radeon module gets loaded (it switches to vgacon and _tiny_ font), and next when loadfont startup script kicks in and loads larger font.
mjt: maybe a distribution question really (startup script ordering)
airlied: mjt: it switches *from* vgacon
airlied: to fbcon
airlied: so it has to clear the screen
mjt: yeah, but I'd rather have it choose right font too :)
airlied: okay thats an fbcon thing
airlied: not a radeon thing
mjt: yeha... and there's no way apparently
mjt: at least not in module params
airlied: mjt: you can probably set some config options
mjt: digging there :)
mjt: fbcon accepts no parameters at all
MrCooper: as you just learned above, not everything is a module parameter
mjt: "The framebuffer console has several, largely unknown, boot options."
MrCooper: these command line options predate the ability to pass module parameters on the command line by a long shot
mjt: by the way, does `kernel module.parameter=value' works for _modules_ too?
mjt: (to mean `module parameter=value')
mjt: i remember there was some talk about that a while ago but don't remember if it were implemented.
airlied: mjt: yup
airlied: with a new enojugh modprobe
mjt: so it's done 100% in userspace
mjt: good way! ;)
airlied: yeah it was written for kms, since we wanted to load modules in initrd but pass them option
mjt: actually i implemented something very similar a few years back for my initramfs
mjt: there was a script running early that scanned all foo.bar=baz kernel options and turned them into `option foo bar=baz' in /etc/modprobe.d
mjt: it also handled blacklist=foo and noload=foo
mjt: i think i'm still using it
apexo: airlied: had a chance to look at fdo bug 27452 again? I attached the EDID as you requested
airlied: apexo: sorry been out sick all day
apexo: airlied: don't excude for being ill ... I mean ... you probably didn't do that by intention :)
dileX: d-r-t has a lot of EDID fixes
apexo: dileX: it's running 2.6.34-rc4, which (AFAIK) includes all of d-r-t
twnqx: including the pm2 patches?
dileX: apexo: I extracted a diff against 2.6.34-rc5 - its a bit bigger than 700k :-)
dileX: ShortLog: http://pastebin.ca/1869372
dileX: twnqx: pm2 is not included
marienz: glisse: my r300 + nforce2 agp combo locked up again, but I didn't have netconsole running when it did, so it *might* have been something else
glisse: marienz: but it seems to have lasted longer than without the patch right ?
marienz: glisse: I think so, yes. But that's not backed with actual statistics :)
glisse: MrCooper: i send a new agp patch
glisse: it should be good on uninorth
glisse: would be nice if you can test it when time permit
glisse: also should i recend the Xserver exa patch with your ack added ?
marienz: I moved the receiving end of netconsole to a different system, and just realised the previous log might've been incomplete because of the receiving end being wireless
MrCooper: glisse: yeah will test it as time permits, and please do resend the patch with keithp in the list of recipients, or he'll ignore it
MrCooper: glisse: took a quick look at the patch, it doesn't seem to set .needs_scratch_page for pre-U3
glisse: i guess i once again mixed tree
MrCooper: glisse: also for some drivers it just adds .needs_scratch_page with no other changes
glisse: MrCooper: some driver doesn't needs change
glisse: because they use the generic function
glisse: which has the proper code for using scratch page already
rah: glisse: have these lockups been fixed?
glisse: function that need tweaking are remove_memory/create_gatt_table/insert_memory
glisse: rah: which lockup ?
rah: glisse: GPU lockups that slow down X
glisse: MrCooper: send updated patch
glisse: a GPU lockup does slow down X
glisse: it kill X
glisse: well render it unusable
rah: yes, that's what I mean
glisse: well i believe the agp patch i just send will help improving the situation
glisse: will likely not fix all of them
berniyh: hi, one question regarding the kernel drm driver
berniyh: if one would built this driver directly in the kernel, is there something else that has to be built in?
berniyh: how does it handle the firmware in that case?
yoshi314: berniyh: you can also build firmware into the driver
yoshi314: there is an option for that
berniyh: is that CONFIG_FIRMWARE_IN_KERNEL?
yoshi314: not sure, i don't have a configurable kernel source dir around
yoshi314: i assume it is the one you ened
adamk: And CONFIG_EXTRA_FIRMWARE_DIR
berniyh: adamk: I think that's the option where you tell it which firmwares should be built in
berniyh: I guess you need both
yoshi314: i think this one will include firmware in initramfs
yoshi314: it's different from in-kernel firmware
berniyh: I don't use initramfs
yoshi314: there is an option that replaces firmware requests with actual firmware
adamk: If you are building radeon into the kernel, you need those two options.
adamk: Otherwise the firmware is unavailable to the kernel.
berniyh: yes, I know
berniyh: is there a way to tell if kms works?
adamk: Well, the monitor resolution will change when the radeon DRM loads.
berniyh: dmesg doesn't mention it
chithead: berniyh: dmesg and Xorg.0.log should mention it
adamk_: Yeah, dmesg should definitely mention it.
chithead: dmesg will contain radeondrmfb
adamk_: If you're not sure, pastebin the 'dmesg'
marienz: dmesg won't actually contain the string "kms" (or "KMS"), at least not here
adamk_: But it will say it's using kernel modesetting, iirc.
berniyh: marienz: searched for modeset
marienz: it'll mention "kernel modesetting" though.
marienz: just saying that if you're like me and grep -i for kms instead of actually skimming for radeon-related messages you might miss it :)
chithead: let the logs speak for themselves
berniyh: sec, let me try the firmware thing first
berniyh: ok, everything works now as it should
berniyh: and X reports that kms is enabled
berniyh: thanks for the support, although actually explaining the problem brought me the solution already :)
apexo: dileX: okay ... now compiling -rc5+drm-radeon-testing
Ronis_BR: mas, I'm getting a problem with radeon
Ronis_BR: lots of OpenGL apps. a veeeery slow (Warcraft III, Half-Life, Enemy Territory, etc). Am I missing something?
adamk_: Ronis_BR: All games with wine?
berniyh: ok, the radeong driver crashes, but iirc that's unstable atm
Ronis_BR: adamk_: no, ET is native
adamk_: Ronis_BR: Pastebin the output of 'glxinfo'
Ronis_BR: adamk_: btw, all SDL/OpenGL applications run like it is render by software
Ronis_BR: adamk_: http://dpaste.com/185744/
adamk_: Is this a 64-bit distribution?
adamk_: Do you have 32-bit versions of Mesa (including the DRI driver) installed?
Ronis_BR: adamk_: don't know, how can I look
Ronis_BR: adamk_: I just compile mesa from git
adamk_: Check a 32-bit version of glxinfo to see if you have acceleration :-)
adamk_: Then you don't have the 32-bit version installed unless you installed it.
adamk_: ET and wine are both 32-bit applications and require 32-bit libraries.
adamk_: Without the 32-bit version of Mesa, your games are falling back to indirect rendering.
Ronis_BR: adamk_: goood point
Ronis_BR: adamk_: I'll look at gentoo how can I install them
Ronis_BR: adamk_: wait a minute, and thanks!
Ronis_BR: adamk_: do I need 7.9-devel 32bit version?
apexo: dileX: ... no change
adamk_: Ronis_BR: Yep.
dileX: apexo: the test was worth it, anyway
Ronis_BR: adamk_: what about 7.8?
adamk_: Ronis_BR: That would probably work. I don't believe the 64-bit and 32-bit versions need to be the exact same.
Ronis_BR: adamk_: ok
Ronis_BR: adamk_: how can I take information from a lib, like it's version
adamk_: I really don't know that.
Ronis_BR: adamk_: my old version of mesa 32 bits was based on 7.5
adamk_: Heh... That definitely wouldn't work.
Ronis_BR: amarsh04: man, THANKS!
Ronis_BR: amarsh04: sorry
Ronis_BR: adamk_: man, THANKS!
Ronis_BR: adamk_: ET is running better, muuuuch better, than when I did with fglrx
Ronis_BR: adamk_: I'll try warcraft
Ronis_BR: adamk_: with fglrx, I just can't play with compositing on, now it is very smooth
maligor: is there some known issue with the xv? mplayer is giving me 'too slow/dropped frames' on just normal SD content (2.6.38rc4, X 1.7 with a reasonably recent ati driver)
maligor: pretty random tho
maligor: and this is on a Intel E6600, so I doubt it's the cpu
maligor: and on a hd 3870
maligor: darned rare and it rather more reminds me of audio issues since it rather reminds me of audio out of sync more than video, but only started happening after switching to radeon
danvet: glisse, just noticed your agp-scratch-page patch
danvet: you might want to drop the intel part for now 'cause I'm doing a rather big reorg there atm (partly merged to drm-next already)
Ronis_BR: adamk_: yeeah, now everything is fine :)
glisse: danvet: sorry too important to be drop
glisse: it fix serious issue for us
danvet: well, as is it's gonna conflict
glisse: it should be fearly easy to rebase on top of my patch as i doesn't change much thing
danvet: and you're also changing the gtt driver, which is rather dubious (that's the mess I'm trying to fix)
glisse: i am only requesting scratch page for all bridge
glisse: this is small changeset
glisse: MrCooper: btw sorry to forget doing half the code
MrCooper: no worries
danvet: glisse, the problem is that your changes to intel are just plain bogus
glisse: MrCooper: what sign of do you use ?
glisse: danvet: in what way ?
danvet: you're mucking around in the gtt driver which ended up in intel-agp.c purely as a historical accident
glisse: what function do you call gtt driver exactly ?
MrCooper: glisse: Signed-off-by: Michel Dänzer
danvet: ie drop all changes to the intel_*_creat_gatt_table driver
glisse: also don't forget that intel igp are not the sole user of this
danvet: only retain the needs_scratch_page = true change
glisse: danvet: not enough
danvet: glisse, why?
glisse: because we need to initialize gtt table with the scratch page value
danvet: yep, I've got that
glisse: danvet: really it should be very easy to rebase your work on top of it
glisse: git is wonderfull for such things
danvet: glisse, please take a lock at drm-next where my stuff has already landed
danvet: intel-gtt.c contains the gtt driver (_only_ used by the igd)
danvet: intel-agp.c contains the agp driver for _real_ agp ports
danvet: if I'd rebase your patch on top of -next, it would muck around in intel-gtt.c which is definitely wrong
glisse: danvet: url please
Ronis_BR: adamk_: yeah, this really should be on some tutorial
glisse: danvet: ok i saw your change
glisse: let me rebase
adamk_: Ronis_BR: Theoretically, it's the distributions job to handle this for end users :-)
Ronis_BR: adamk_: but radeon is experimental :) so it isn't installed with 3d support etc
Ronis_BR: adamk_: gentoo has the package, but it is very HARD masked :D
adamk_: Errr. radeon itself is not experimental.
Ronis_BR: adamk_: after installing, everything goes fine, ET is working 100%
Ronis_BR: adamk_: for R700 is needs mesa 7.9-git
adamk_: And, I guess the general belief is that people who are compiling the driver themselves should know that they need the 32-bit version for 32-bit apps :-)
Ronis_BR: adamk_: I didn't, until you told me :D
AstralStorm: hello there
Ronis_BR: adamk_: but, anyway, thanks! you helped a lot, I was just starting to install fglrx again (urgh..)
adamk_: No problem. Glad to be of help.
danvet: glisse, ok. I'll be afk for the next two hours anyway.
AstralStorm: I don't know what's so hard about installing fglrx
AstralStorm: maybe getting the 32-bit version installed, but I digress
AstralStorm: (and that you need a patch for 2.6.33 and up)
AstralStorm: (and that it probably fails vs 1.8)
AstralStorm: *xorg 1.8
adamk_: Which is what he is using.
Ronis_BR: AstralStorm: lets start
Ronis_BR: AstralStorm: you can't open two X, you can't have KMS, you can't use XORG 1.8.0, you sometimes stuck with old kernels because it doesn't compile, you have to enable a deprecated option in kernel
AstralStorm: yes and yes
Ronis_BR: AstralStorm: ah, radeon performs better with daily use (compositing) than fglrx
Ronis_BR: AstralStorm: and for 2D accel, radeon is better everywhere (with my tests)
AstralStorm: except it doesn't with 2.6.34, funny thing that
AstralStorm: I wonder if it was some bug in 2.6.33
Ronis_BR: AstralStorm: too bad radeon still has problem with some games
Ronis_BR: AstralStorm: what doesn't with 2.6.34 kernel?
AstralStorm: the composite is fast
AstralStorm: unlike with 2.6.33
AstralStorm: (with fglrx)
AstralStorm: I've no idea why
Ronis_BR: AstralStorm: I'm using 184.108.40.206 with radeon and everything is fine
AstralStorm: yes, yes
Ronis_BR: AstralStorm: maybe I'll install 2.6.34 to check
AstralStorm: radeon is fine either way
AstralStorm: but I get to use fglrx because it does OpenGL 2.1
AstralStorm: and radeon doesn't (on r6xx)
Ronis_BR: ah, I get it
AstralStorm: as for composition, extra funny part is that dropping cairo with gl acceleration makes it "damn fast"
AstralStorm: either way
Ronis_BR: is there some schedule to where radeon will become to provide ogl 2.1?
AstralStorm: not sure it'll work as advertised with radeon
AstralStorm: none I know of
AstralStorm: right now the focus seems to be power management
Ronis_BR: well, anyway, this guys are doing a great job
Ronis_BR: KMS is amayzing
AstralStorm: yeah, need more of them
AstralStorm: KMS is mostly useless (from user point of view) but yes, looks nice ;p
Ronis_BR: and radeon is very good IMO, because it is much more clean than fglrx
AstralStorm: fglrx is not even a real driver, it's a way to load a binary blob and uses another binary blob to communicate with it
Ronis_BR: O_O, I didn't know that
AstralStorm: it consists of some kernel blob and libGL implementation that sends commands to it
Tommeh: AstralStorm: isn't KMS required for 'new things' - like Gallium?
AstralStorm: not much else I can know - I know this by mmiotracing
AstralStorm: Tommeh: it's tangential
AstralStorm: gallium could work w/o KMS, just not as nicely
Tommeh: Gotcha :)
AstralStorm: different, more complex backends would have to be written
Ronis_BR: is Gallium ready for R700?
adamk_: Not even close.
AstralStorm: what do you mean?
Tommeh: So it's *almost* required for new things.. Given that getting support for something like Galllium would be even harder without KMS
AstralStorm: I mean, it's ready for implementing an R700 backend ;p
AstralStorm: but there's none yet
Ronis_BR: last time I checked (last year) it was at the beggining
AstralStorm: it can draw a triangle now, almost
Tommeh: Hooray r600g
AstralStorm: hmm, guys, any way to turn implementing more of r600g into an engineer degree thesis?
Ronis_BR: what will be the biggest advantage of gallium?
AstralStorm: Ronis_BR: portability and ease of extending
AstralStorm: see, gallium is kind of interpreter
Ronis_BR: well, I have to ge
Ronis_BR: thanks everyone
AstralStorm: it interprets opengl into card assembly and state changes
maligor: wasn't it waiting for some changes in gallium
AstralStorm: it's waiting for more development love
maligor: so that's why it isn't merged yet?
AstralStorm: no, it's just... not working
AstralStorm: drawing *one* triangle *wrong* is not my idea of "works"
AstralStorm: of course it's a large step for the state tracker
maligor: I didn't say anything about 'working' in terms of usability
AstralStorm: probably just missing implementation of all the instructions that are necessary
AstralStorm: there's no sense to merge it now
maligor: just that it was waiting for some other change in gallium before merging it
AstralStorm: no, it's not waiting for anything
AstralStorm: except more development on itself
AstralStorm: feel free to improve it
maligor: I'm aware it's there
AstralStorm: as per glisse's blog, it's been done in march, that wrong triangle part ;p
AstralStorm: http://jglisse.livejournal.com/ - here it is, in case you've missed it
MostAwesomeDude: glisse reports that he's got gears going and he's close to OA.
MostAwesomeDude: Also, we won't ever do non-DRI2/KMS Gallium.
adamk_: really hopes someone gets KMS going on FreeBSD soon.
adamk_: I understand what a gsoc student has applied to work on that, so hopefully there will be some advancement with that.
AstralStorm: MostAwesomeDude: I know
AstralStorm: MostAwesomeDude: gears going = great. what about random shaders?
AstralStorm: I bet not due to missing commands
AstralStorm: esp. samplers
MostAwesomeDude: Dunno. I was going to sit down and start working on optimized r600 shaders sometime, but for now, I have more interesting things grabbing my attention.
speps: hi guys a question. What's the best configuration at the actual state for the r300 boards gallium mesa integration?I noticed a lot of worsenings in latest releases. The last good working i had was with mesa 7.6.1. In this time 4 me 7.8.1 is the worst. What about that? Thanks
MostAwesomeDude: Use git if possible.
TCW: I thought galiam is _completeley_ still experimental and radeon not ported yet to use galium?
TCW: gallium even
soreau: TCW: Gallium works pretty well from my recent experiences
TCW: soreau, never seen it in debian, that's why I may think it is still not in a working order :)
adamk_: r300g is quite impressive.
soreau: TCW: Debian probably wont package it for another 5 years
TCW: adamk_, impressive compared to what?
adamk_: Impressive in how far it's come :-)
TCW: soreau, :p
AstralStorm: compared to mesa driver, it's better, but not impressively so (r300g I mean)
adamk_: I was able to play openarena and nexuiz with it quite well. I don't have any benchmarks to compare it to the classic driver.
AstralStorm: just eyeball it already
AstralStorm: it's some noticeable % faster on average
adamk_: Yeah, nothing jumped out at me, performance wise, but it's come quite far in the past few months.
AstralStorm: that's why I want r600g so badly
soreau: write it!
AstralStorm: or at least that OpenGL 2.1 stuff
AstralStorm: soreau: I wish I had enough quality time to spare
soreau: Im impressed by the fact that r300g can run some programs where classic chokes
TCW: in general... as almost no games work with wine on radeon cards I don't mind 3D performance very much... it should run compiz smoothly, that's all I need it for
AstralStorm: true, because gallium compiler is quite a piece of work
soreau: In other instances, classic has better performance but gallium is catching up quick
AstralStorm: TCW: compiz should work well
AstralStorm: and games will work in Wine, as long as they need only OpenGL 2.0
soreau: TCW: You definitely dont need gallium to run compiz smoothly
TCW: AstralStorm, does it with the classic mesa stuff too
adamk_: compiz is one of the few applications that gave me problems with r300g, in fact.
AstralStorm: I don't know which card you have, TCW
adamk_: doom3 also failed miserably, but works fine on classic.
soreau: I never had much of a problem with compiz on gallium, except in its infancy
TCW: AstralStorm, several... r3xx, rv5xx, rv6xx
soreau: cairo-dock used to exhibit issues but now runs better than classic (some icons are invisible with some themes using classic)
AstralStorm: TCW: so, r3xx and rv5xx should be fine either way, opengl 2.1 should work there
AstralStorm: rv6xx, not so much I think (classic or gallium)
TCW: But I only use a rv5xx at the moment... the boxes with r300 and r600 are disassembled :)
AstralStorm: rv5xx is r4xx, right?
soreau: less cdock icons are invisible using gallium but I also suspect cdock glx-usage fail
TCW: AstralStorm, rv5xx shoudl work with wine?
AstralStorm: TCW: I don't have the card, which driver does it use? r4xx or r5xx?
AstralStorm: (r4xx is r3xx driver I think)
TCW: AstralStorm, I've seen r300_dri in the logs... apart from that tell me how to look and I cvan tell you :)
MostAwesomeDude: Yes, r500s work with Wine.
AstralStorm: so it's r300, should work with Wine
AstralStorm: at least up to OpenGL 2.1
soreau: r3-5xx use the r300 driver
soreau: >=r6xx use r600
AstralStorm: which is a bit behind in features :(
soreau: of course r8xx is its own case
AstralStorm: catalyst 10.4 has broken GL compatibility, hehehe
TCW: AstralStorm, MostAwesomeDude, last tested almost a year ago with a very old game (No One Lives Forever), it gave me white + dark textures, no real color
AstralStorm: this sounds like an unsupported texture format
adamk_: MostAwesomeDude: If I try to start vmware with 3D acceleration using r300g, I get: vmware-vmx: shader/slang/slang_compile.c:665: parse_layout_qualifiers: Assertion `0 && "Bad layout qualifier"' failed.
TCW: AstralStorm, you ask me? _NO_ idea :)
AstralStorm: easy to check though
adamk_: MostAwesomeDude: IS there any way to get you (or any of the developers) more debugging information?
MostAwesomeDude: adamk_: That would be a GLSL compiler bug.
AstralStorm: LIBGL_DEBUG=1 and go
TCW: AstralStorm, tell me then
TCW: AstralStorm, run the game with that variable set?
MostAwesomeDude: adamk_: You're definitely going to want to email the mailing list; I don't think there's any other way to get Vinson's attention.
AstralStorm: I think yeah. not sure if you need mesa built with --enable-debug or such
adamk_: MostAwesomeDude: So it's not r300g specific? I got it with a few games in wine, too.
adamk_: MostAwesomeDude: mesa3d-dev ?
MostAwesomeDude: adamk_: Yeah, or dri-devel. Remember that mesa3d-dev is no longer an SF list. :3
MostAwesomeDude: It probably shouldn't be dying like that, though.
TCW: libgl1-mesa-dri-dbg - Debugging symbols for the Mesa DRI modules
TCW: libgl1-mesa-glx-dbg - Debugging symbols for the Mesa GLX runtime
TCW: libgl1-mesa-swx11-dbg - A free implementation of the OpenGL API -- debugging symbols <- AstralStorm, one of those?
adamk_: I haven't been subscribed to either list for a while :-)
adamk_: I guess you'd recommend dri-devel, then?
AstralStorm: TCW: the packages are likely outdated, which version of mesa is that?
AstralStorm: no really, you should try the latest development tree, it's moving quick
TCW: 7.8.1-1 in debian experimental
TCW: 7.7.1 in sid
speps: what about glsl?i tested some shaders in souerbraten with last mesa 7.8.1 and i get a lot of corruptions, it's still quite worse than 7.6.1 on my r300
TCW: AstralStorm, I am a "distro guy", git / svn / whatever only in emergencies :)
TCW: And not beeing able to play NOLF is not an emergency ;)
TCW: crashing X would qualify there :)
AstralStorm: 7.8.1 might be fine, it's fairly new
AstralStorm: 7.7, definitely old
AstralStorm: except this bug:
TCW: AstralStorm, so what would I need? Only mesa / dri / glx stuff that new or all X / graphic driver as new too?
AstralStorm: "r300: set proper vertex index limits also in non indexed mode
AstralStorm: Fixes #27521, broken menus in UT2004 and broken water refraction in Sauerbraten.'
AstralStorm: fairly critical
AstralStorm: mesa, libdrm (not necessarily) and the driver (xf86-video-ati)
AstralStorm: libdrm you have might be new enough
TCW: 6.13.0 is the newest the distro has to offer for xserver-xorg-video-radeon
Wizzup: That is quite recent
AstralStorm: yeah, it is
AstralStorm: it should run mesa 7.8 branch fine
TCW: it is? soreau, ha! See? Debian is _recent_! :p
AstralStorm: possibly latest too
AstralStorm: TCW: is that sid?
TCW: soreau, oh oh... it is getting even better... it is LATEST!! :o
AstralStorm: latest *release* which isn't latest enough for radeon's mesa
TCW: AstralStorm, details are not important here :)
AstralStorm: someone should push for 7.8.2 release soon
AstralStorm: those r300 bugs are critical
TCW: So I would only need to find those damn CD images of that game again...
soreau: TCW: FWIW, you can install gallium to a nonstandard prefix and try it on a per-app basis without disturbing your system components that are already installed
TCW: Oh damn it... it got that late?! Sorry, guys, bbl
AstralStorm: yeah, with LD_LIBRARY_PATH or LD_PRELOAD
AstralStorm: just ./configure --prefix=
AstralStorm: e.g. ./configure --prefix=~/testingmesa --other-options
AstralStorm: (a lot of these)
MostAwesomeDude: speps: Are you really using Gallium?
AstralStorm: MostAwesomeDude: tpyo ;)
AstralStorm: soreau: whatever MostAwesomeDude said
soreau: is confuzzled
AstralStorm: so, are you really using Gallium?
soreau: No, MAD was talking to speps (see srollback)
AstralStorm: oh hell
AstralStorm: it scrolled of 3 screens
soreau: From the sound of it, speps is still using classin mesa
MostAwesomeDude: Yeah, Gallium performance and quality has only gone up since 7.7, and 7.6 didn't even have a working r300g.
AstralStorm: also "worsening" doesn't sound like a scientific term
AstralStorm: there is a nasty bug in 7.8.x though
AstralStorm: fixed in 7.8 branch now
soreau: It a user term, used and defined by the user, for the user ;)
AstralStorm: worsening sounds like performance problems
AstralStorm: or at least something gradual
speps: MostAwesomeDude: compiled mesa with --enable-gallium-radeon
MostAwesomeDude: speps: But you're still loading the classic DRI?
adamk_: speps: Check the output of 'glxinfo' to see if you're using the gallium driver.
speps: did i miss something
adamk_: Well what's the output of 'glxinfo | grep renderer'?
speps: OpenGL renderer string: Mesa DRI R300 (RV530 71C5) 20090101 TCL
speps: maybe i miss something
adamk_: You you aren't using gallium.
speps: compiled mesa with that
speps: what else i have to do?
soreau: X has hardcoded r300_dri.so as *the* dri driver
soreau: gallium is called radeong_dri.so
adamk_: The gallium r300 driver was compiled to lib/gallium/radeong_dri.so . YOu need to rename that to r300_dri.so
soreau: you do the math ;)
adamk_: And then you can use LIBGL_DRIVERS_DIR to specify the path to the r300 gallium driver when running 3D applications.
soreau: adamk_ did all the maths!
adamk_: I would not recommend replacing your system's copy of the r300_dri.so driver with the gallium one unless you really know what you're doing.
speps: yeah thanks adamk, i've not noticed a difference in the build script so i did it compiled in the old system
speps: now i try again doing my build
mirror176: adamk_, gallium drivers for freebsd need kms first?
adamk_: mirror176: Yes.
adamk_: mirror176: All gallium drivers need KMS.
Dr_Jakob: well mm..
adamk_: Or, at least the radeon ones do, right? :-)
soreau: nouveau does too
soreau: I believe gallium by definition requires a memory manager which cant happen without KMS IIRC
Dr_Jakob: sure it can, intel did it.
MostAwesomeDude: It could definitely be done without KMS and GEM. I just didn't do it because I'm not a masochist.
Dr_Jakob: That too.
MostAwesomeDude: Dr_Jakob: Stop hitting yourself. :3
Dr_Jakob: Hehe :)
adamk_: There are also other advantages to KMS and GEM, such as DRI2 and accelerated blit.
Dr_Jakob: I wonder just how much work...
Dr_Jakob: 1, create DRI1 winsys. 2, strip out some functionality from the mesa/st. 3, PROFIT.
Dr_Jakob: FBOs, genmipmaplevels.
soreau: sounds like 3) HEADACHE ;)
Dr_Jakob: And do all surface_fill and surface_copy in software.
Dr_Jakob: but thinking about it, its not _that_ much.
adamk_: Make it so!
Dr_Jakob: ctx->base.FBO_EXT = FALSE;
adamk_: What'd everyone think of my Picard impression?
Dr_Jakob: well the DRI1 winsys might be a bit of a pain.
Dr_Jakob: adamk_: http://irc.walkyrie.se/facepalm/01.jpg
adamk_: Wrong series, but great picture :-)
Dr_Jakob: adamk_: http://irc.walkyrie.se/facepalm/03.jpg double!
adamk_: Ooohh.. Now there we go.
maligor: No triple?
Dr_Jakob: maligor: I'm sure there is a shop of it.
adamk_: Well I have to get going, but it's been fun :-)
Dr_Jakob: See Ya!
Dr_Jakob: MostAwesomeDude: +g!!
MostAwesomeDude: Dr_Jakob: Yes, it was necessary.
speps: adamk_: ok i did all the stuff again, ready to check if it works, before rebooting do i need more to get Gallium work?
marienz: glisse: and there it went again, still with [drm:r300_ga_reset] *ERROR* VAP & CP still busy (RBBM_STATUS=0x8400C100)
dafox: Hi, I have a few questions, would someone be willing to perhaps answer one or two? First off, is there an easy way to follow the development of the in-kernel drm driver? Something like a git-repository from which I can build the kernel module? I couldn't really find any info on that.
dafox: I've read the 'RadeonBuildHowto', but I'm not sure how up-to-date that is, it mentions that the in-kernel drm will be merged to 2.6.32
speps: adamk: extremely slow now. glxinfo confirm gallium on but glxgears about 4-5 frames sec. What's wrong with that?
Ronis_BR: AstralStorm: hello fellow
Ronis_BR: AstralStorm: I think Gallium shouldn't exist
Ronis_BR: AstralStorm: think, every new card should have a new part on it
dafox: MostAwesomeDude: you know like you might know the answer to my question?
AstralStorm: Ronis_BR: huh?
AstralStorm: and every card needs a rewritten from scratch opengl implementation?
AstralStorm: that's... not a real target
Ronis_BR: AstralStorm: no, but you sair Gallium is just an interface
Ronis_BR: AstralStorm: why don't put the interface at video driver
AstralStorm: gallium is an interface between OPENGL and the low level parts of the card
Ronis_BR: AstralStorm: and what is radeon driver?
AstralStorm: (well, almost, DRI is a step below)
MostAwesomeDude: dafox: airlied's drm-2.6 tree on kernel.org is the best spot.
AstralStorm: by "radeon" you mean legacy Mesa?
AstralStorm: similar, but written in a non-reusable form
Ronis_BR: AstralStorm: no, by radeon I mean xf86-video-ati
AstralStorm: this one is an X driver, it submits commands from X server to the card
AstralStorm: straight to DRI
maligor: you think every driver should be written from scratch to bind to opengl?
maligor: that'd be immense amount work
AstralStorm: it is ;p
dafox: MostAwesomeDude: thanks, so that is still recent? Is that a whole kernel tree or just the radeon module though? (I'd prefer just a single module)
AstralStorm: gallium abstracts a part of it, so each driver only needs to write a compiler for a special language
MostAwesomeDude: dafox: Well, that will always be recent. And it's the entire tree, the modules are no longer buildable out-of-tree.
Ronis_BR: AstralStorm: ah
Ronis_BR: AstralStorm: thanks :)
AstralStorm: and state tracker
MostAwesomeDude: It's easier when you realize that cards don't actually *implement* GL or D3D.
AstralStorm: nobody has to reimplement, say, texture caching
MostAwesomeDude: They implement a pipeline which can be programmed to do GL or D3D rendering.
AstralStorm: (actually I've lied)
dafox: MostAwesomeDude: ok, thanks, I'll go check it out then
AstralStorm: yeah, think of a card like a bare CPU + RAM
maligor: AstralStorm, does it run linux?
AstralStorm: nah, it's specialized
AstralStorm: although it could decode video
maligor: highly serious question there
AstralStorm: no, important opcodes are still missing
AstralStorm: and you have to set up PCIe before using the card
AstralStorm: (and CPU and actual RAM)
AstralStorm: and it'd suck at a control workload like one a typical cpu has to run
AstralStorm: they're not geared for that
maligor: that's not really much of a requirement in generic terms, mostly done by BIOS or bootloader for generic cpu's
AstralStorm: afair there's no jump instruction, for example
AstralStorm: maligor: "mostly done" means nothing at all is done until you write it ;p
AstralStorm: see where coreboot is
mirror176: gpgpu isnt good for general low thread count tasks. they are great at massive parallel tasks because 512i is more than the <12 cores most people run
mirror176: each of the individual threads are still processed slow though =)
maligor: AstralStorm, like the JUMP Instruction in the R600 ISA?
AstralStorm: maligor: see the range of its argument
AstralStorm: and yes, that's for all this GPGPU rage
AstralStorm: it's not fast
AstralStorm: those GPU cores don't have advanced branch prediction
AstralStorm: and likely have small cache
AstralStorm: (if any)
mirror176: its just does far too many things at once to be called slow
mirror176: ...wish i could play with it here
AstralStorm: yeah, it's great for massively parallel operations
AstralStorm: unless memory load cost is too high
mirror176: true of all computer systems ive seen though ^_^
AstralStorm: (PCIe <-> RAM is slower than CPU <-> RAM)
mirror176: move once, operate a lot, move back...thats how it benefits well
AstralStorm: or working on stuff you're going to display
AstralStorm: like, video or 3D graphics ;p
dafox: ok, next question (this one is for everyone who has r300g): does compiz really work with r300g? As in, does it work with direct rendering? Because when I start compiz I have to enable "indirect rendering" or it doesn't work. (screen does not update, and after half a minute or so compiz will segfault) It does work with indirect rendering, but I guess that in that case performance is not optimal (it's still about the same as with the 'classic' driv
dafox: er though)
AstralStorm: it should, but there's some bug apparently
soreau: dafox: Compiz works with direct rendering even with classic mesa
soreau: You just need dri2
AstralStorm: yeah, need KMS enabled
dafox: soreau: that's what I said, it works with classic, but with r300g I need to *disable* direct rendering
dafox: (I'm now running compiz on the classic driver with direct rendering)
dafox: AstralStorm: and KMS is also enabled, ofcourse
soreau: dafox: Worksforme
dafox: soreau: so it's a bug then
soreau: How are you starting compiz with gallium exactly?
Ke: I thought compiz was so 2006
AstralStorm: dafox: pastebin Xorg.0.log then
AstralStorm: Ke: no, it's actually in wide use thanks to Ubuntu :/
AstralStorm: and is in constant development
dafox: soreau: I symlink /usr/lib/dri/r300_dri.so to the gallium dri (radeong_dri.so) and run compiz with "compiz --replace --sm-disable --ignore-desktop-hints ccp"
soreau: dafox: Can you pastebin the output of 'LIBGL_DEBUG=verbose glxinfo' with the symlink installed?
dafox: AstralStorm: X is already started at that point
dafox: soreau: sure, give me a minute
AstralStorm: dafox: you need to start X with the right DRI
AstralStorm: or it'll fail
AstralStorm: unless you're already doing this
dafox: AstralStorm: (II) RADEON(0): [DRI2] Setup complete
dafox: AstralStorm: so I guess dri2 is on
soreau: AstralStorm: You don't need to restart X to use gallium
dafox: soreau: http://pastebin.com/M5YfAFe7
soreau: However, I would strongly recommend against symlinking directly in the main prefix
soreau: dafox: So what happens when you try to start compiz?
dafox: soreau: but if it's just temporary (and I know how to put it back from console) it's ok, right
soreau: dafox: I am not sure. From my experiences, messing with r300_dri.so that X is currently using is a bad idea
AstralStorm: try LIBGL_DEBUG=1 start-your-compiz 2>&1 > some-file.log
AstralStorm: soreau: thought so :>
soreau: I would create the symlink in a different prefix, then point LIBGL_DRIVERS_DIR to it
dafox: grr pastebin froze firefox
AstralStorm: humm, install wgetpaste or curlpaste
dafox: and I'm back
dafox: soreau, AstralStorm: I think my computer's dying because firefox is eating all memory... pastebin wtf
AstralStorm: killall -KILL firefox-bin
mjt: there are other pastebin services. eg paste.debian.net
AstralStorm: wgetpaste ftw
AstralStorm: curlpaste even more so
AstralStorm: those are command line paste apps
soreau: dafox: Scratch firefox and use curl. compiz-command | curl -F 'sprunge=<-' http://sprunge.us
AstralStorm: yeah, that works too :)
soreau: add a 2>&1 somewhere in there too
AstralStorm: better, LIBGL_DEBUG=1 compiz-command 2>&1 | theabove
dafox: soreau: done?
dafox: soreau: but I didn't get an url?
soreau: I guess it's waiting for the process to return :P
dafox: AstralStorm: do I need to configure wgetpastesomehow?
soreau: do metacity --replace and it should give a url
dafox: it fails with 'Apparently nothing was received. Perhaps the connection failed.
soreau: probably timed out
dafox: soreau: I already had the output in a file
dafox: soreau: like this: cat Desktop/compiz_gallium | curl -F 'sprunge=<-' http://sprunge.us
soreau: dafox: Then use cat thatfile | curl blah blah
chithead: dafox: wgetpaste uses dpaste.com by default, which is... meh. try wgetpaste -s ca
dafox: I don't see why I'm having so much trouble pastebinning this ...
soreau: me neither..
soreau: btw, which distro is this dafox ?
dafox: your thing keeps giving me nothing, I even copy-pasted the example url from the sprunge.us site
dafox: dafox is on Gentoo
dafox: hmm is there like a size limit on those pastebins
dafox: cause it's 2.4Mb large :p
dafox: it's full of hex output
dafox: and such
dafox: one per line
AstralStorm: dafox: no
soreau: Try starting it with GALLIUM_ABORT_ON_ASSERT=false ;)
soreau: Now I remember just recently, gallium fails to start compiz
AstralStorm: soreau: hurr, why did you lie then? ;)
soreau: AstralStorm: I didn't
soreau: it worked fine up until a few weeks ago
dafox: soreau: you kinda implied it was working for you atm
soreau: dafox: Sorry. Does it work with setting that env var though?
dafox: no it crashed
AstralStorm: it should've crashed
AstralStorm: I mean compiz
AstralStorm: but it should print some things too
soreau: just tried
soreau: r300_blit.c:129:r300_surface_copy: Assertion `dst->texture->format == src->texture->format' failed.
soreau: debug_get_bool_option: GALLIUM_ABORT_ON_ASSERT = TRUE
soreau: That is the error compiz gives with gallium
MostAwesomeDude: One sec, cookin' patch.
dafox: I got a nice crash at first, then I tried again and now it keeps failing the same as before
soreau: GALLIUM_ABORT_ON_ASSERT=0 works, but 1) Causes some visual errors 2) you should never have to set this at all
dafox: soreau: got it reproduced
soreau: dafox: IIRC, hex dump means the kernel revoked a rendering context or something to that effect
soreau: well compiz is crashing but seems you don't have debugging symbols
dafox: soreau: but that only seems to happen when compiz was last started with the classic driver
dafox: trying to start it again (second time) with r300g it does the same (print lots of hex codes)
soreau: dafox: You mean replacing compiz w/classic with compiz w/gallium?
MostAwesomeDude: Could you get the kernel messages when that happens? There's *always* stuff in dmesg.
dafox: soreau: yes, compiz is running with classic dri, then run that command but with the new dri
dafox: MostAwesomeDude: I get a lot of relocation errors, but I get those all the time (I'm actively ignoring them since I don't know what they mean, and compiz does work)
AstralStorm: so gallium corrupted the pipeline. cool
dafox: MostAwesomeDude: there are a lot more of them than usual though, one per second or so
AstralStorm: probably due to abort
soreau: dafox: Can you try restoring r300_dri.so, symlink or cp radeong_dri.so /some/nonstandard/location/r300_dri.so then start with LIBGL_DRIVERS_DIR=/some/nonstandard/location/ ?
dafox: soreau: with GALLIUM_ABORT_ON_ASSERT=false?
soreau: dafox: no
dafox: soreau: LIBGL_DEBUG=1?
soreau: I'm not sure if this will even make a difference, but I don't like mucking around in standard prefix with files potentially in use
adamk_: MostAwesomeDude: Hey, Vinson is a vmware employee? Cool, maybe that will improve the chance of this GLSL compiler bug fixed.
dafox: soreau: it's the same, first time a crash, second time all hex output
soreau: dafox: ok
soreau: you have a different problem than I have though
soreau: dafox: Which model card is your again?
MostAwesomeDude: dafox: No, that's not it. You'll get very verbose complaint.
dafox: radeon 9600 mobility M10
soreau: has rv350 9600
dafox: MostAwesomeDude: what's not it?
soreau: dafox: The dmesg messages you see
dafox: soreau: that's the same, right? I have a laptop card though, you have a desktop?
soreau: Yea, this is agp card
dafox: BUG: scheduling while atomic: compiz/12099/0x10000002
dafox: that sounds nasty
soreau: dafox: Where does that message come from?
dafox: I just peeked
dafox: first time I've seen that
dafox: dmesg | tail -100 http://dpaste.com/185881/
MostAwesomeDude: soreau: Just pushed a patch to mesa/mesa; pull and build SVP. Shouldn't need to make clean.
soreau: MostAwesomeDude: shader vertex prog? oO
MostAwesomeDude: Ugh, bugs. That's no good.
MostAwesomeDude: soreau: Hm?
MostAwesomeDude: Oh, Sil Vous Plait. :3
soreau: okay *googles*
adamk_: Please respond :-)
adamk_: In french.
soreau: Or 'if it pleases you' ?
MostAwesomeDude: Well, without the Respondez- in front, it's just "If you would."
MostAwesomeDude: Would you kindly... :3
soreau: ah ok
dileX: MostAwesomeDude: most awesome french word/abbreviation was k7 - short for cassette
MostAwesomeDude: dileX: That's pretty good.
dileX: MostAwesomeDude: took some time to reveal in the music store - next thing hard to understand was that XY per cent songs in the french charts has to be in FR. long live academie francaise!
adamk_: I heard something similar about radio stations in Canada. A certain percentage of songs played have to be from Canadian performers.
soreau: MostAwesomeDude: I can't really tell what's going on now. It starts and doesn't give any crash information but it behaves as if it did crash because it ceases to run
MostAwesomeDude: soreau: Hm. If you built debug stuff, it should spit out debug info.
MostAwesomeDude: soreau: Do you have a second comp? Is gdb an option? Probably not...
soreau: MostAwesomeDude: Oh yes, I have other pc's on the network, I can gbd or valgrind ofr whatever
soreau: MostAwesomeDude: I don't see anything out of the ordinary in the debug output http://pastebin.org/162909
soreau: MostAwesomeDude: So get a gdb bt?
MostAwesomeDude: soreau: Could you set a breakpoint at r300_blit.c:r300_surface_copy ?
MostAwesomeDude: Er, no, that's bad.
MostAwesomeDude: r300_blit.c:130 is gonna be better.
soreau: MostAwesomeDude: here's gdb trace, looks like it's segfaulting http://pastebin.org/162927
soreau: and I don't know how to set break points so you'd have to school me on that
glisse: AstralStorm: gallium won't suddenly bring you thousand of fps ... it just make our code looks nicer ...
AstralStorm: I know that's the whole reason
AstralStorm: and the fact that implementing new OpenGL features will be that much easier
soreau: glisse: I think AstralStorm doesn't care what it looks like under the hood as long as gl2.1 works
glisse: soreau: he can have gl 2.1 today with software :)
AstralStorm: well, I do
glisse: so i think he cares :)
AstralStorm: because if it looks nice, I might get to improve it later
AstralStorm: I do care that it works correctly and then fast
AstralStorm: but software is too slow obviously ;p
soreau: I got curious and got the fgl_glxgears binary.. runs on nvidia but on radeon it gives "Error: couldn't get fbconfig"
soreau: MostAwesomeDude: Seems all gl programs segfault now with whatever change you made
soreau: did a full clean build and it's different
soreau: think I have some info
soreau: r300: Implementation error: Format mismatch in r300_surface_copy
soreau: : src: PIPE_FORMAT_B8G8R8A8_UNORM dst: PIPE_FORMAT_B8G8R8X8_UNORM
soreau: r300_blit.c:134:r300_surface_copy: Assertion `0' failed.
soreau: debug_get_bool_option: GALLIUM_ABORT_ON_ASSERT = TRUE
soreau: MostAwesomeDude: glxgears runs and compiz gives some relevant output ^^ now that I did a clean build
adamk_: Has anyone else here tried doom3 with r300g?
MostAwesomeDude: soreau: Ah, hey, that's familiar.
soreau: adamk: yea, why?
adamk: How'd it work for you?
soreau: runs best with classic from my tests so far
adamk: OK, yeah, but I had some major texture issues with r300g, in addition to being considerably slower.
soreau: fun times if you install st3c texture lib ;)
adamk: I have it.
soreau: adamk: Uninstall it
soreau: that is causing your testure problems
adamk: Gotcha :-)
maligor: slower = more time to aim at the zombies
soreau: causes the same type of issue on etqw
soreau: the planet displayed has all kinds of crazy textures
soreau: MostAwesomeDude: Did you have any idea about that output?
speps: hey guys i noticed a lot of weird artifacts with kms and gallium enabled. First of all cannot run glxgear quite faster than 4-5 frame for second if there is no composite manager on. Cannot run any opengl app with or without composite. Ncurses is very slow with compiz and when i enable compiz i get WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an
speps: application bug! What's the matter?
adamk_: Are you sure everything is setup properly? Using the gallium driver, what is the renderer string from glxinfo?
soreau: speps: 1) Artifacts where? 2) Can you pastebin the output of 'LIBGL_DEBUG=verbose glxinfo' when glxgears is running slow? 3) .. 4) The warning message is harmless
MostAwesomeDude: soreau: Yeah, we talked in #dri-devel a bit. Basically, we're gonna look and see why the TFP path does that. I'll ping you when I've got some more patches.
soreau: MostAwesomeDude: Most awesome, thanks :)
speps: adamk_: OpenGL renderer string: Gallium 0.4 on RV530 , soreau: http://pastebin.com/6qKGNM9y
soreau: Any reason you're not using mesa git?
soreau: other than that it looks ok
soreau: Which resolution are you running btw?
speps: soreau: 1280x800
soreau: speps: I have the same chip as you and gallium works fine
soreau: the only immediate difference I can see is you're not using mesa git
FIReun: should update
speps: what's your complete configuration?
soreau: (Well.. works fine sans compiz for the moment)
soreau: speps: I have it working on gentoo and arch
speps: ok i'm on arch 64
speps: why do you think glxgears goes 4-5 frame 4 second without compositing and goes well with compositing?
soreau: no idea
soreau: The only time I've seen gears <100fps was when Virtual >4080x4080
speps: soreau: are you using aur packages, or you have done your own like me?
soreau: speps: I used aur for all their aur mesa packages except gallium. For gallium, I grab my own copy of mesa, build it manually into /opt/xorg then set 'LIBGL_DRIVERS_DIR=/opt/xorg/lib/dri app' so I can run app on a per-app basis
speps: soreau: what do use with gallium and what without?
soreau: speps: That's specific to the application and your experiences with it. If it works better with one or the other, use that dri driver
soreau: speps: Though I can say that classic mesa pretty much beats gallium across the board for all tests, except for applications that can't even run with classic in the first place
soreau: That is, from my tests I did last week
soreau: thus, I install it so classic is default and can run any application with gallium I want to test
speps: i see so you use mesa-git from aur and you done gallium packages apart for testing. Have you also other like xorg-server or else from git?
speps: soreau: maybe there is also some other reason, since mesa 7.8.1 is about 2 weeks ago, you tested git about a week ago, maybe there is not so much difference
soreau: speps: The only other -git packages I installed with aur were the minor deps for libdrm, ddx and mesa. I didn't have to update xorg-server
soreau: however, I am using community-testing and testing repos globally
speps: soreau: however i get glxgears like 1 second speedy and 2 seconds all hangs cannot move mouse.
speps: soreau: now another weird think i noticed
speps: i was trying tracking calls with strace
soreau: speps: anything interesting in terminal output or dmesg?
speps: well if i start glxgears with strace glxgears it goes fast
speps: mouse does not hangs
speps: soreau: really weird, starting glxgears without compositing hangs all and goes about 4-5 but if i start with strace glxgears it goes about 300 fps
speps: and i get never errors dmesg or xorg or other
soreau: though GINAB, I get ~700FPS on my rv350 here
soreau: with both classic and gallium
UnNamed: what about other apps?
soreau: they work fine for the most part
speps: testing compiz i notice also that it hangs at the ends of some animations, for example when Alt tabbing at the end of the windows scrolling moviments it hangs for 1 second. It does not happens when doing expose or other
soreau: speps: You obviously have a sour version of gallium or faulty installation. I'd recommend trying mesa from git
speps: i'll give that a try
speps: can you pastebin your mesa-gallium PKGBUILD, i wanna be sure i'll start from your same configuration to check where the issue is
soreau: What mesa-gallium PKGBUILD?
speps: soreau: you said you done your own ad-hoc gallium mesa in /opt/xorg order to make an application use classic and another use gallium did you do invasive installation instead of a package?
soreau: If that's what you want to call it..
soreau: I just call it a manual install
speps: eheheh just different way to name it
speps: soreau: so what do you need in order to use gallium, just the radeong_dri.so or something else?
soreau: speps: That's pretty much it, though you might want swrastg_dri.so too..
soreau: speps: This is more or less what I use to install gallium: make clean && ./autogen.sh --prefix=/opt/xorg --with-dri-drivers="r300 radeon swrast" --enable-gallium-radeon --enable-gallium-swrast --disable-gallium-intel --with-state-trackers=dri,glx,xorg --disable-egl --enable-debug && make && sudo rm -rf /opt/xorg/lib/dri/; sudo make install && sudo rm -rf /opt/xorg/lib/dri/r300_dri.so && sudo cp /opt/xorg/lib/dri/radeong_dri.so /opt/xorg/lib/dri/r300_d
soreau: ri.so && sudo cp /opt/xorg/lib/xorg/modules/drivers/radeong_drv.so /usr/lib/xorg/modules/drivers && LIBGL_DEBUG=verbose LIBGL_DRIVERS_DIR=/opt/xorg/lib/dri glxinfo|egrep "renderer|nGL" && ls /opt/xorg/lib/dri
soreau: eeps :P
soreau: well you get the point ;)
speps: damn maybe i found the issue i forgot --enable-gallium-swrast during compilation
evil_core: S -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS radeon_drm.c -o radeon_drm.o
evil_core: radeon_drm.c:188: error: expected ‘}’ before ‘;’ token
evil_core: git looks like master mesa is broken
Dr_Jakob: evil_core: update
Dr_Jakob: sorry about that...
evil_core: /usr/bin/install: cannot create regular file `/opt/xorg/include/GL/gl.h': File exists
evil_core: Dr_Jakob: _np ;)
evil_core: its strange, because 32bit verion installed, but 64bit not with that error
oga: airlied: any comments on those patches I posted?
airlied: oga: oh I need to take another look, Alex is off this week I think
airlied: oga: did you test server recycle with the map fixes?
oga: pretty sure I did
oga: what precisely defines a recycle, and i'll check
airlied: oga: killing the last client
airlied: so that X restarts instead of exiting
oga: i've never been sure if that happens with display managers anymore.
oga: but if killing hte WM works, pretty sure I have.
oga: I will retest tomorrow (in zaphod mode) just to be sure
airlied: well yeah killing all clients
airlied: though they look good so I'll push em
oga: zaphod still has a bug on this machine (4870), screen 0 looks stretched.
oga: almost as if screen0 is tring to fit over both monitors. screen 1 is fine.
oga: identical monitors. Alex and I are both stumped
oga: thanks for the review
prahal: hi I have a raeon hd3200 that works well in kms mode except for the backlight controls that freeze the box (be it via the Fn keys or the /sys entries)
prahal: is this a kown issue ?
prahal: I found similar reports about intel drivers . Could it be in the common part of the kms code ? or does this clearly indicate a bios bug (in non kms mode the brightness controls works well though)
Vash63: Hey, I'm on a 5870 with DisplayPort and DVI, 2.6.34-rc4 and the latest 'radeon' from git, Xorg loads radeon successfully but then radeon fails to find any screens.
zhasha: I tried the F13 beta livecd and https://bugs.freedesktop.org/show_bug.cgi?id=25386 is still very much at large
zhasha: it's not only limited to S-Video anymore either as it was at the beginning of F12. VGA out doesn't work either
zhasha: and whatever is being sent out that S-Video port, it's not S-Video
prahal: ok my issue is fixed in 2.6.34-rc5 . sorry for the noise
Vash63: If I made the radeon driver in kernel modularized is it supposed to create a drivers/gpu/drm/drm.ko? It only made a drivers/gpu/drm.o and 'make modules_install' is bitching about it.
Vash63: Well integrated the firmware in following the wiki... KMS is working fine in console but the Xorg driver isn't loading. Nice high res terms on both my DisplayPort and my DVI-D monitors though.
Vash63: http://paste.pocoo.org/show/204323/ Not much interesting that I didn't say earlier but here's the log anyway. I'll bbiab, will be idling. Just says no devices detected or screens found...
airlied: Vash63: try with no xorg.conf
Vash63: Yay, that worked.
Vash63: Now input isn't working but that problem doesn't belong here >_>
Vash63: Just migrated to 1.8.
Vash63: Are weird color and redraw issues expected behavior at this point for Evergreen KMS?
Vash63: My DisplayPort monitor looks fine minus some poor redraws but the DVI one's colors are all messed up.
Vash63: Maybe I should take a picture. Two monitors side by side in clone mode.