mancha: i've installed a legacy gtk+2 for a closed source binary that won't run with recent gtks. i force the binary to use the legacy gtk+2 and this is fine in ums but in kms all the menu icons are gone (just have some colored squares instead)
bonbons: are there know suspend issues with radeon (linux-2.6.34-rc5-git5) in KMS mode (suspend from linux console, e.g. no X)?
evil_core: how can I mirror all DRI docs to got them offline them?
evil_core: I am moving, and will not got internet connection, maybe will try to play with radeon if bored ;)
evil_core: wget -p -r -l 5 -k -N --no-remove-listing "http://dri.freedesktop.org/wiki/Development"
evil_core: this downloads only one file :/
adamk: Is it just me, or is git on freedesktop running incredibly slow?
adamk: Bah... Looks like it's just me. Pulling it on my computer at work gets me 243 KB/s, compared to 2 KB/s at home.
Janhouse: is it possible to use that direct2d acceleration with opensource radeon drivers?
adamk: What direct2d acceleration are you referring to?
Ke: I think not until gallium3d
Ke: adamk: win32 compatible
Ke: adamk: afaik amd binary drivers support that api
Janhouse: I am using RS690M [Radeon X1200
Janhouse: oh, I c
adamk: I don't know. Sounds like AMD's attempt to speed up 2D acceleration in X, which has always sucked.
Janhouse: well my card sucks with 3d
maligor: maybe they're moving from XAA
adamk: Janhouse: Direct2D doesn't sound like it has anything to do with 3D, so I'm not sure how that's relevent.
Janhouse: If I don't increase min cpu freq to 1.6ghz I get lags with compiz enabled
Janhouse: adamk, probably
Janhouse: anyway, I am now trying to use Ubuntu without compiz and all the nice features
Janhouse: at least Flash has no more problems
maligor: since when?
maligor: flash always has problems
Janhouse: maligor, I could not normally play youtube videos because it didn't respond to mouse clicks properly.
Janhouse: I had to press on the video with mouse and then use SPACE on keyboard
Ke: now you can play most youtube videos with html5
Janhouse: without compiz no problems at all...
Janhouse: Anyway, flash is used almost everywhere
Janhouse: not just youtube
adamk: Adobe, in their infinite stupidity, prevents flash from using acceleration if you're not using an nvidia card with the nvidia drivers, last I heard.
maligor: most issues with flash are because the plugin is rubbish
Ke: Janhouse: I seem to be doing just fine without
Janhouse: without flash?>
Janhouse: I have 2 computers
Janhouse: one with nvidia and one with radeon
Ke: Janhouse: yup
Ke: but offtopic
Janhouse: the one with nvidia never have any problems
adamk: Again, Adobe only lets flash use acceleration with the nvidia drivers. That's their own stupid decision.
Janhouse: maybe they trust only nvida because they have normal drivers for linux? :D
cafaro: Hi, I'm trying to get Ubuntu 9.10 working with my HD3650, but I have to enable KMS first, when i enter: sudo modprobe radeon modeset=1, I get: *ERROR* failed to initialize radeon disabling IOCTL, any ideas?
Thunderbird: the way they designed flash is a bad decision .. (the gpu -> cpu back copying); though hopefully they have fixed their design now
Ke: 9.10 sounds a bit old for KMS
adamk: It was supposedly possible to get KMS going on 9.10 with AMD cards, but it was unsupported.
adamk: And not something I'd spend any time trying to get working, frankly.
adamk: At least not without using a much newer kernel.
cafaro: should i upgrade the kernel? or modify xorg.conf manually?
Ke: cafaro: upgrade to 10.04
cafaro: I also tried adding radeon.modeset=1 and removing splash from GRUB_CMDLINE_LINUX_DEFAULT, but all I get is a small white ubuntu logo, and a black screen afterwards
adamk: Your xorg.conf isn't going to cause or fix that error when you modprobe radeon.
adamk: So, yeah, either use a newer kernel or try 10.04.
adamk: There are PPAs with newer kernels.
adamk: And even the xorg-edgers PPA to get 3D going
cafaro: I just noticed the xorg.conf is missing?
adamk: Are you even reading what I said? :-)
cafaro: yes I did
adamk: Your xorg.conf isn't going to cause or fix that error.
adamk: xorg.conf is completely optional these days.
cafaro: I think i will try out fglrx because according to https://help.ubuntu.com/community/RadeonDriver#2D modesetting only , my card only has 2d accel with this driver
adamk: Yes, as I said xorg-edgers will get 3D going with a newer kernel.
maxi_jac: I'm using r300g on 2 cards, an RV350 and an RV570, both seem at least OpenGL 2.0 compliant (source : wikipedia ^^) but I can run HoN (needs OGL 2.0 and GLSL 1.2) on only the RV570. It reports a missing ARB_vertex_buffer_object extension. Is it normal it works with RV570 but not with RV350 ?
chithead: doesn't hon need opengl 2.1?
maxi_jac: looks like it does not : http://www.heroesofnewerth.com/specs_pop.html
maxi_jac: or they made a mistake ?
airlied: maxi_jac: got the latest r300g?
airlied: can you pastebin glxinfo from the rv350?
maxi_jac: glxinfo on the RV350 reports OGL 2.1 and GLSL 1.20
mancha: airlied glad i caught you. got a problem, super summarized: closed source binary needs older gtk+2 so i installed a legacy alongside my normal gtk+2, i force the app to use the legacy libs. in UMS all is well, in KMS all the menu icons are colored blocks.
mancha: any idea? :)
Thunderbird: typically opengl 2.0 drivers do offer VBOs (and even earlier versions); I don't remember by head which version merged ARB_vertex_buffer_object into occur
Thunderbird: 2.1 added PBOs, so likely 2.0 (or even earlier) added VBOs to core
Thunderbird: if your driver advertises opengl 2.1 and doesn't support this extension then it is bad
Thunderbird: it seems they were added in OpenGL 1.5
Thunderbird: just check your glxinfo output to see if it indeed lacks the extension if it does then the driver is not really 2.1 capable at this point
maxi_jac: my glxinfo on RV350 http://pastebin.com/BfEdwQa6
maxi_jac: looks like the extension is reported here ?
adamk: GL_ARB_vertext_buffer_object is definitely listed.
airlied: maxi_jac: wierd, sound like some interaction with pixman or EXA
airlied: and pbo
airlied: maxi_jac: some issue with 32/64 bit?
adamk: maxi_jac: So you're not using a 64-bit distribution?
adamk: Hmmm... You could try running HoN with LIBGL_DEBUG set to verbose to see if there's some error.
airlied: it might be a shader issue that only happens on r300
mancha: airlied this is on r200, by the way.
maxi_jac: ok... there's no issue at all in fact... it's working...
maxi_jac: problem was I was using a relative path for LIBGL_DRIVERS_PATH and it worked for glxinfo but not for hon.
maxi_jac: Why ? I think hon.sh starting script must redefine cwd or something like that
maxi_jac: anyways, it works now
adamk: Yeah, seems likely.
adamk: How well does it work, though?
maxi_jac: laggy xD, I've just went to main menu
maxi_jac: I'll try to launch a game
maxi_jac: (yeap, hon.sh does a cd )
airlied: mancha: do adding ExaNoComposite to xorg.conf make it go away?
maxi_jac: thanks for having been interested in my "probem" that is not one :p
mancha: airlied, i will try, i don't have an xorg.conf since i let HAL do all the configgin, but lemme check
maxi_jac: Oh and by the way, if my RV350 is really OpenGL 2.0, glxinfo should not report 2.1 right ?
adamk: maxi_jac: r300-r500 hardware is, technically, not opengl 2 compliant. However, the driver is able to support the one missing hardware feature with good performance.
adamk: maxi_jac: So it reports 2.1 just as fglrx does.
maxi_jac: oh ok, so missing features from 2.1 are done in software ?
adamk: That is correct. The only one that's missing as to do with NPOT textures, as I recall.
adamk: MostAwesomeDude could confirm this.
maxi_jac: ok :)
mancha: hrmm, how do i add just that one option on a HAL aware X?
airlied: mancha: with an xorg.conf ith just a Device section
maxi_jac: I think I won't even launch a game since it's swapping like hell :D (old laptop, I tried hon just to see if it could launch )
bridgman: Ke; ping
mancha: airlied, tried that and it didn't like it
mancha: i.e. just a 3-line Device block
airlied: mancha: andd Driver "radeon" line
airlied: and maybe Identiifer "Videocard0"
Ke: bridgman: ?
mancha: ok, let me play with the bare minimum needed to let me use a hybrid approach
mancha: this'll add and not replace right?
mancha: airlied, nope, that didn't fix it. though it did make things slower (rendering)
mancha: brb, confirming ums works again.
Jonimus: mancha: could the older gtk need an older libpng or somesuch and thus cause the breakage?
che: just tried the unigine heaven 2.0 demo. it is missing the following extensions: MESA_EXTENSION_OVERRIDE='+GL_ARB_map_buffer_range +GL_ARB_vertex_array_object +GL_ARB_half_float_vertex +GL_ARB_half_float_pixel +GL_EXT_texture_swizzle +GL_ARB_framebuffer_object +GL_EXT_framebuffer_blit +GL_EXT_framebuffer_multisample'
che: of course it imploded after trying to start it with the overrides
Oipo: I get a segmentation fault when running any 32-bit executable using opengl. Backtrace of glxinfo-32 here: http://pastebin.org/178417
Oipo: I had it working earlier today, but then it started doing this. Any idea what may cause this?
airlied: mancha: try ExaNoSolid, ExaNoCopy also
evil_core: airlie do you work on some interesting branches for r500? (except d-r-t and master mesa)?
airlied: mancha: check xorg log to make sure they are taking effect
airlied: evil_core: no everything I work on is merged
mancha: airlied, confirmed only happens with kms and the exa option didn'[t help
evil_core: airlied: and openarena/q3a based games didnt et strange/nonsmooth frames flow, especially in UXGA?
bridgman: Oipo; usually this means you don't have a 32-bit build of mesa etc...
Oipo: bridgman, but I just build it, and am using the built libgl and r600_dri.so. Carefully noted that the -m32 switch has been used whilst compiling.
bridgman: did you rebuild mesa between working and not-working ?
Oipo: Yes. make clean && config
evil_core: Oipo: maybe make distclean
Oipo: Tried that somewhere in the last three rebuilds(have rebuild a few times since it changed to non-working), no change.
bridgman: also wondering if paths etc are correct, ie if it's trying to run the 64 bit mesa with 32-bit app or something
bridgman: haven't played with 32-on-64 much
Oipo: 'libGL: OpenDriver: trying /usr/lib32/dri/r600_dri.so"
evil_core: Oipo: anyway I recommend using separate dirs for both, you can use git clone with some args to got most things shared(and you will save 50% of hdd space in seconbd repo_
evil_core: and still EXA is mainly developed? I heard about glucose many years ago and that EXA will be soon deprecated
Oipo: evil_core, I'm pretty sure it wouldn't change my current situation. I have been quite careful in compiling the 32-bit libraries. I've already been busy with this for several hours, which is why I came here.
evil_core: Oipo: I can upload mine scripts for building and running apps if you want
Oipo: evil_core, No thanks. I have my own already, which I am only circumventing because the 32 bit build didn't work.
evil_core: Oipo: did you pointed 'file' at them?
evil_core: I got also many errors in the past
Oipo: evil_core, Hmm? Did I point 'file' at them? What do you mean with that?
evil_core: you must make sure your MEsa is built with your custom drm i ncustom prefix, etc
evil_core: otherwise it will be unstable
evil_core: did you checked*
evil_core: it will say if something is 32 or 64bit
Oipo: evil_core, I have indeed. It is telling me it is an ELF32 shared object.
evil_core: sometimes -m32 is not enough for configure
bridgman: evil_core; I suspect glucose (EXA-ish over OpenGL) has been more or less obsoleted by the possibility of EXA over Gallium3d
bridgman: or possibly OpenVG over Gallium3D
evil_core: EXA sucks a bit, by default it reserves 50% of VRAM
evil_core: the nexst 40% in typica setup will be consumed by compiz for hi-end cards ;)
bridgman: I don't think there's anything in EXA spec about reserving vram - are you talking about a specific implementation ?
evil_core: there is 50% by default in xserver
evil_core: or maybe I am missunderstainding that option
evil_core: Option "FBTexPercent" "90"
airlied: evil_core: UMS only
airlied: evil_core: I wonder if OA is using some of the sync extensions
airlied: and we are getting them wrong
evil_core: airlied: ok, thanx, I am using it still, but I was hearing there I should migrate to KMS because UMS is obsoleted and no longer supported ;)
airlied: it is pretty much, I think that OA lag is a recent regressio
evil_core: its not recent, at least 2 months and probably longer
airlied: I'm guessing since some of the sync/dri2 stuff went in maybe
evil_core: btw, are you playing with Mesa too?
evil_core: I got annoying behaviour of libGL fallbacking to swrast with glide wrapper in UMS
evil_core: long ago
evil_core: but few days found solution, deleting swrast provides smooth playback of them :)
airlied: evil_core: are you using r300g in kms?
evil_core: I goyt also script and testing it also
Oipo: Hmm. Is there a reason why I have to comment out "ifeq ($(RADEON_LDFLAGS),)" and its corresponding endif in Makefiles for mesa?
evil_core: not such big lags as with classic
evil_core: but as smaller room is in q3a, then bigger lags
evil_core: its perfectly smooth in biggest area
evil_core: and nearer the wall it starts lagging
airlied: Oipo: because you screwed up something
evil_core: only in Gallium
airlied: evil_core: I'll try and play later not sure whats going on there
evil_core: but about swrast
Oipo: airlied, I did a clean clone of mesa, configured it and am trying to compile. Is the problem in the configuration options, or a missing environment variable, or...?
evil_core: $ ls -l /opt/xorg/lib/dri/noswrast/
evil_core: total 0
evil_core: lrwxrwxrwx 1 root root 14 Apr 23 14:35 r300_dri.so -> ../r300_dri.so*
evil_core: lrwxrwxrwx 1 root root 17 Apr 23 14:35 radeong_dri.so -> ../radeong_dri.so*
airlied: Oipo: misising libdrm_radeon or something
evil_core: $ cat ~/bin/noswrast_exec
evil_core: export LD_LIBRARY_PATH="/opt/xorg/lib64:/opt/xorg/lib:$LD_LIBRARY_PATH"
evil_core: export LIBGL_DRIVERS_PATH="/opt/xorg/lib64/dri/noswrast:/opt/xorg/lib/dri/noswrast"
evil_core: "$prog" "$@"
evil_core: its noswrast hack and wrapper to it ;)
airlied: some 32/64 issue
evil_core: and now every Glide game works under UMS :D
evil_core: it works because there no symlink to swrast
evil_core: Glide wrapper loads r400 at first, but later wine got some error initializing gfx subsystem and while reinitialization it fallbacks to swrast
evil_core: oh, I remember
evil_core: its not ability to reserve GART memory
evil_core: I can run it and show output
agd5f: I don't think EXANoSolid and Copy are valid since they are required. I think you have to manually add a return false in the driver hooks
evil_core: libGL: radeonCreateScreen: drmMap failed for GART texture area
evil_core: libGL error: Calling driver entry point failedlibGL error: reverting to software direct rendering
evil_core: lits the error and fallbac kto swrast
evil_core: somebod told me its normal for UMS that dont work
evil_core: but this game worked on nvidia, r200 and mach64 before Gallium ever existed under wine
evil_core: so IMHO its Mesa bug and regression
evil_core: in previous week Ignition started working also under KMS, but after minute or two, all scree nartifacted sometimes interlaced with last time good game view
Oipo: airlied, thanks. That was exactly what made my entire 32-bit stack go boom.
adamk: FYI, here's a level of MarbleBlast with the r300 driver: http://184.108.40.206/r300-marbleblast.jpg
adamk: That's what it should look like. This is what it looks like with the r600 driver: http://220.127.116.11/r600-marbleblast.jpg
adamk: Any thoughts?
oga: wg agd5f
evil_core: adamk: welcome to free drivers hell ;)
bridgman: adamk; what are the differences you're pointing out ? mostly textures less visible or is the different viewpoint also part of the problem ?
bridgman: colours are lighter - is that from the different viewpoint or actually displaying wrong on 600 ?
bridgman: sorry to ask an hour late but downloads aren't real fast at chez bridgman ;)
adamk: bridgman: Has nothing to do with the viewpoint, just the color/textures.
adamk: Gotta go, bbl :-)
bridgman: ok, tx
mtkoan: I tried putting fglrx on my slackware box, and it broke things. running slackware-current with linux 18.104.22.168. had mesa dri working with the radeon driver before fglrx-- which didn't work properly so I uninstalled it.
mtkoan: but then things wren't working, complaining about missing libatiuki.so.1. reinsatlled mesa, libdrm, and xf86-video-ati, and that fixed that, but now glinfo is giving errors like: