happycube: humm... glCreateShader in the prog/glsl examples are NULL
happycube: any ideas?
dmb: sadcube :(
Nightwulf|work: hi all
happycube: figured it out - glew doesn't enable it. good luck getting a fragment program to actually run tho ;)
happycube: trying to run mandlebrot on r300g was... interesting! it glitched x.
happycube: [r300compiler error: Don't know how to handle inputs 0xc000] on progs/glsl/toyball - looks like otherwise it'd try to run it
Zajec: airlied: THANKS :D
Zajec: airlied: i've posted trivial "[PATCH] fix typo in define: engine -> memory" on dri-devel on 4.11, just wanted to ask if you noticed that
Zajec: glisse: ping on http://bugs.freedesktop.org/show_bug.cgi?id=24837
taiu: hmm, looks like kms likes straight DVI connection more :) with dvi-vga most of the time i got correct mode but black output
taiu: now i'v got 3 reboots with dvi only and picture present
zhasha: happycube: what are you doing?
glisse: Zajec: yeah will take a look
airlied: Zajec: yeah I'll put that in, I just added your patch to find out my engine clock ;-)
airlied: glisse: fixed fedora bug in X server hopefully
airlied: glisse: am going to work on memory sizing next week
airlied: I will make my 32MB card work perfect ;-)
taiu: Zajec: nice, engine clock: 750000 Hz
taiu: units seem to be off though
airlied: 750Mhz seems right
glisse: airlied: for exa i believe we should never put pixmap in vram
taiu: jeah so it's in kHz
glisse: do like what nouveau is doing no pixmap in vram on small vram gpu
airlied: glisse: yeah that was my plan, darktama stole it ;-)
glisse: i wanted to benchmark that haven't had time yet
airlied: glisse: for useful VRAM cards putting pixmap in VRAM is fine
glisse: nouveau kids are pesky ;)
airlied: for AGP we need to make evict to evict to GTT and not system RAM
glisse: on r6xx/r7xx i am not sure we should put things in vram
airlied: glisse: we have to put some pixmaps in there
airlied: otherwise DRI2/Xv can't work
glisse: we are hitting so much fallback that it seems we waste huge amount of time in migration
airlied: where are we hitting that?
glisse: why dri2 can't work ?
airlied: on low mem ys, but with mixed pixmaps we should be okay
airlied: glisse: dri2 just uses pixmaps
glisse: yeah what i am saying is do all the pixmaps in gart
glisse: never move them to vram
glisse: just lie to exa
glisse: so dri2 will work
airlied: you want to do dri2 from gart?
glisse: try firefox, well i am using cairo trace to look at fallback
airlied: erally I think we shuold try and ellimate the sw fallback
airlied: or at least make it into a composite operation
glisse: for dri2 it makes sense to have dri2 pixmap in vram
glisse: i am thinking here as a temporary solution
airlied: its prety much all the same interface
airlied: we use EXA to do dri2 buffer copies
glisse: until we accelerate things better
airlied: better off just fixing EXA really
airlied: or at least identifying where it gets things really wrong
glisse: it seems that we would need to accelerate a lot more case
airlied: firefox sucks because it does a lot of GetIamge
airlied: and you can't help that
glisse: iirc there is a lot of gradient rendering which end in fbComposite op
airlied: composite should be fine, if src is in GART, dst is in VRAM
airlied: my old codebase did all that ;-)
airlied: if we migrate src to VRAM it'll suck
glisse: well all i am saying is that today we migrate too much things in vram
airlied: unless something else put i t there in a previous operationsame for mask
glisse: ttm is faulty too, due to its priority stuff
airlied: I'm more worried about migration out of VRAM
airlied: putting thins into VRAM is fast
airlied: I expect getimage is what kills us with firefox, stupid crappy scrlling
glisse: according to cairo perf trace it's fbComposite fallback
glisse: well sysprof + cairo perf trace
airlied: so that mixed pixmaps, so its proably not migration
airlied: its just sw rendering
glisse: well there is a lot of migration due to fallback
airlied: okay we should do some traces and post them
glisse: so my thinking was if can avoid migration we might have a temporary solution to improve perf
glisse: bugs keep me distracted
airlied: we can avoid all migration but it'll be sw ;-)
glisse: yeah, my op is that exa die and everyone use caire-glitz or somethings like that ;)
airlied: yeah bugs are more important now ;(
airlied: cairo-drm ;-)
glisse: haven't looked at cairo drm but i would rather have one driver in one place, like a gallium driver :)
glisse: just less things to debug :)
airlied: cairo-gallium then ;-)
glisse: yeah i was wondering if cairo->openvg->gallium
glisse: was a good idea
airlied: nah skip openvg
airlied: go straight to gallium
glisse: but cairo state tracker sounds doable
airlied: someeone even half started one
glisse: oh ?
glisse: who :)
airlied: I tihnk ickle did a qucikc one before joining Intel
airlied: there is cairo-gallium.c file ;-)
glisse: in cairo repo ?
airlied: no idea what it does or doesn't do
airlied: the perf diff at the moment between intel cairo-drm and cairo-gl is very substantial
glisse: btw for t60 suspend/resume i wondering if the master abort bit being set does play a role
glisse: i need to check pci spec
glisse: but i think we should reset the master abort things
editka_: has anyone succes with running world of warcraft on wine with radeon driver,
airlied: hmm sounds like something we shouldn't have to caer about
glisse: i got another patch for t60 after discussing with agd5f i will post it
glisse: editka_: people did in the past
twnqx: i have issues with my T500 if that helps
glisse: dunno what is today state
twnqx: like, i tell it to unload the radeon driver
twnqx: didn't properly resume otherwise last time i tried
editka_: so if someone got it working in the past how it is possible that today it is not working? is this how driver development just works?
twnqx: one month back displayport worked, two weeks ago it didn't, now it does again :P
editka_: and how long aprox. it will take to radeon get to some stable state?
editka_: or nobody knows this?
Zajec: taiu: ups, thanks for testing
twnqx: generally devlopment works like a) set target for features, b) implement, c) remove bugs, d) goto a)
editka_: oki and in which state we are now? :-)
editka_: between b and c ? :-)
twnqx: that's my impression :
Zajec: glisse: if you have suggestions to english in debugfs ("driver's copy of the CP_RB_?PTR") argue with agd5f ;)
editka_: is this due to DRI2 / KMS implementation being worked?
Zajec: glisse: my gramma is not perfect, asked on irc, agd5f replied :)
glisse: agd5f: is far better at english than me :)
Zajec: i've some problem googling for kernel timers
Zajec: what should I use?
glisse: google string: "linux device driver site:lwn.net"
glisse: there is a section on timer in it iirc
dileX: how do I see if PM stuff is active?
Zajec: dileX: PM? power management?
Zajec: dileX: in kernel?
Zajec: dileX: there isn't PM yet
dileX: Zajec: power-mngt for my RV5151
Zajec: dileX: yup, as i said, no yet
Zajec: glisse: oh, nice, i didn't think about LDD
dileX: Zajec: you will provide the radeon-pm support in kernel?
Zajec: dileX: hopefully
dileX: Zajec: I am in spirit with you! go go go!
airlied: Zajec: have you seen mjg59 pm patch for radeon?
airlied: it might be a better place to start as it did dynamic pm on a dsektop
airlied: it needs forward porting to latest radeon kms code, it was written against F11 kernel
GNU_D: Hi, I got nightmare problems with KMS on Radeon 9200SE ;(.
GNU_D: I tried to disable KMS with nomodeset, then I don't have any 3d acceleration and glxgears suspends the whole monitor, the keyboard is locked, looks like the kernel is down too, when I try with radeon.modeset=0 still the same. But when I try with nothing i.e with KMS support, I got software renderer and poor speed, plus the fonts are blured.
Zajec: airlied: thanks, it looks little hackish but nice reference
Zajec: airlied: i think with this patch it may happen i'll stick with downclocked GPU after enabling second monitor
Zajec: airlied: also, it "believes" every commands will be executer in some strictly-set time
airlied: the only bit that was raelly breoken in it was how to calculate the min memory bw
Zajec: airlied: yeah, plus that part :)
Zajec: airlied: but as i said, very nice reference :)
airlied: but the rest works quite well
airlied: the other issue was how much of a reclocking you can do in vblank
airlied: without artifacts
Zajec: leaving now, will back to that later
airlied: using atom was a too painful
airlied: so we just did r500 hacks
airlied: zzzz &
glisse: agd5f: i think i have bug that need the oposite of 592bcac52f113a95923a8f1cb8427e7552d5670b
agd5f: glisse: the problem is, there is no ref divider on atom. we were just getting garbage
Kano: hi, is AMD Geode LX Video using radeon driver?
leio: Kano: No
Kano: what driver is it
leio: Kano: That uses xf86-video-geode
Kano: made by ati too?
leio: Kano: no, Geode is a CPU architecture dating back to many previous companies, current owner and maker of the LX improvements is AMD
Kano: it does not seem to be packaged in debian
leio: Development of it has been discontinued and the people that worked on that platform let go, so the driver is now completely community maintained
leio: it definitely is, I know the debian packager personally
leio: xorg driver packages are named with a different prefix in debian, all of them
leio: instead of xf86-video-
Kano: hmm it is
Kano: but the all package does not instlal it
leio: appears to be the package name under debian
Kano: yes, but xserver-xorg-video-all does not depend on it
leio: no idea about that personally
Kano: well i preinstall -all but that driver was not installed
lordheavy: with kernel from git (today) and xf86-video-ati and xserver 1.7.1 i've got xserver freeze (kms seem to work but wrong in x):
lordheavy: (II) RADEON(0): Setting screen physical size to 381 x 238 => x freeze !
twnqx: good that my gernel is of yesterday :S
twnqx: what card?
lordheavy: hd 4200
lordheavy: xf86-video-ati is from git too
lordheavy: will restart to get log
lordheavy: Xorg.0.log : http://pastebin.com/m1bb50056
lordheavy: kernel log : http://pastebin.com/m15f9bad8
kdekorte: lordheavy, is this an AGP card?
lordheavy: integrated in the motherboard chipset am3 so pci express
kdekorte: lordheavy, does adding nomodeset to the kernel line make the machine boot?
lordheavy: the machine boot :-) but failed when launching Xorg (the screen freeze, then loose sync)
kdekorte: it does that with nomodeset as well?
lordheavy: not tested with nomodeset
lordheavy: i restart to test
lordheavy: ok no problem with nomodeset
lordheavy: OpenGL vendor string: Advanced Micro Devices, Inc.
lordheavy: OpenGL renderer string: Mesa DRI R600 (RS880 9710) 20090101 TCL
lordheavy: OpenGL version string: 1.4 Mesa 7.6
kdekorte: probably a kernel drm bug then, did you just upgrade the kernel and it quit working?
lordheavy: i've just build the kernel 2.6 from git to test kms/X accel, previously i was with 2.6.31 but kms failed to init
wirry: 31 didnt support kms on r6xx/r7xx
kdekorte: have you tried using the drm-next kernel , follow the howto in the subject
lordheavy: not yet tested but will do now :-)
kdekorte: 2.6.32-rcX should have enough KMS stuff in it, but drm-next is usually a little newer
kdekorte: if it doesn't work, then open a bug at freedesktop.org
kdekorte: you can also pull drm-next into the git kernel if you want to save some download time
lordheavy: ok will do that
kdekorte: believe that is in the howto as well
glisse: agd5f: setting a mode on svidoe output will force it as connected ?
agd5f: glisse: you can force a mode on any ouput
agd5f: you still have to forcibly enable it if it's not considered connected
marvin24: I get this http://pastebin.com/m63f6350 from time to time - latest kernel+KMS on rs690
marvin24: should I care?
twnqx: slab corruption isn't good :P
glisse: marvin24: yup doesn't looks good
glisse: it's likely a bug on our side
marvin24: there are also a lot of memleaks reported (maybe false positves). I think some developers should compile their kernel with memleak detection & slap debuging enabled
glisse: i usualy have that on
glisse: thought it was be a while since i booted such kernel
dileX: dmesg: reserve_ram_pages_type failed 0x5e77000-0x5e78000, track 0x8, req 0x8 ?
dileX: hmm, errmsg comes from
dileX: hmm, any correlation between radeon and pat?
icewaterman: how can i find if my system supports opengl 1.5?
icewaterman: OpenGL vendor string: DRI R300 Project
icewaterman: OpenGL renderer string: Mesa DRI R300 (RV530 71C2) 20090101 TCL
icewaterman: OpenGL version string: 1.5 Mesa 7.6
icewaterman: this is what glxinfo says, but i do not know if that is software mesa or hardware radeon
wirry: its hardware
icewaterman: oh, nice
icewaterman: i wonder why max payne doesnt work in wine though
icewaterman: could be a wine bug
icewaterman: because on ubuntu 8.10 it worked just fine
icewaterman: wirry: both are really slow
wirry: ubuntu 8.10 was with fglrx?
icewaterman: 2 always was via wine on my box, but 1 was quiete fast.
icewaterman: wirry: nope
icewaterman: it was the radeon driver all along
icewaterman: wirry: iirc ubuntu 8.10 was 32-bit here, atm i am using 64-bit version
icewaterman: maybe it has something to do with that
wirry: i dont think so..maybe 1 or 2 frames but not more
icewaterman: wirry: ok, frames are now ~3-4fps and were 30-50+ before
icewaterman: so more like factor 10
wirry: thats definitly not the jump from 32 to 64bit
icewaterman: wirry: the problems appeared with 9.04 i hoped they would be fixed in 9.10 but obviously i was wrong
kdekorte: icewaterman, do you have 32bit versions of the mesa dri drivers installed
kdekorte: lack of them is what makes 32bit apps (like wine) slow
wirry: err...yeah...wine is always 32bit...i keep on forgetting that :/
wirry: or better the application you run with wine
agd5f: icewaterman: OpenGL version string: 1.5 Mesa 7.6 <--- 1.5 means GL 1.5
kdekorte: I have a fedora 32/64 bit setup and can tell you that lack of 32bit dri makes the 32bit apps (like google earth) run dog slow cause it is all in software
icewaterman: agd5f: thx
wirry: is going to try google earth
kdekorte: wirry on r6xx you might need to start googleearth with vsync_mode=0
wirry: im on r7xx
kdekorte: same thing
icewaterman: kdekorte: thats weired, because counterstrike (1.5) works just fine with wine
icewaterman: so i doubt its mesa to blame, thoug i will look into the matter
wirry: but i only got squares where text should be
kdekorte: r6xx and r7xx is the same driver, so you need vsync_mode=0
wirry: i forgot how i fixed this on my intel-laptop
icewaterman: what is the usual name for mesa library?
wirry: no i dont need vsync_mode=0
wirry: and it works well on 64bit here
icewaterman: kdekorte: i have this one: libGLU.so.1
kdekorte: yeah, I'm using the latest drivers and without vsync_mode=0 it is really choppy
kdekorte: icewaterman, yeah that is the mesa part, but you need a 32bit r300_dri.so
wirry: hmm..2 days old
kdekorte: wirry let me retest
icewaterman: kdekorte: that one i've got
kdekorte: wirry your right, you don't need it anymore
wirry: and i dont have a 32bit r600_dri.so
wirry: and google earth still runs wine - havnt tried any wine-stuff yet
kdekorte: wirry, didn't know they made a 64bit google earth... mine is 32bit
wirry: GE is still 32bit, but it has to use the 32bit r600_dri.so
lordheavy: anyway to check if i got the drm-next modules loaded (instead of kernel-git drivers) ?
kdekorte: ugh... just rebuilt mesa (32bit mode) and now googleearths clouds looks like crap
icewaterman: wirry: i am using an r300 based card
kdekorte: on r6xx
wirry: yeah, i got that, be kdekorte said GE runs slow on pure (execpt for GE) 64bit-systems - which i cant confirm
kdekorte: if you have GE install you have a lot of 32bit stuff installed
kdekorte: just do an ldd on googleearth-bin
lordheavy: ok found with modinfo :-) it give the path of the module
icewaterman: any idea how to make wine a little more verboseß
kdekorte: talk to the wine people
icewaterman: kdekorte: k
wirry: http://dpaste.com/117134/ <-- not so much actually
DanaG: weird... some recent R600 mesa (non-KMS) seems to cause xorg to exit, even on mere glxgears.
lordheavy: kdekorte : it's working with drm-next, but not with git kernel, does i open a bug report ?
stikonas: if it is working with drm-next there would be no reason to open a bug report
stikonas: it means that this is already fixed
nanonyme: Am I using xrandr somehow wrong or why does it say "xrandr: Need crtc to set gamma on" when I try to do xrandr --output dvi-0 --gamma 1:1:1?
nanonyme: (probably am)
nanonyme: Yeah, requires capitals.
nanonyme: Nice, that appears to reset gamma after it getting botched with r/s on rv670 with KMS.
spstarr: airlied: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=4d357abb895ec51f1cbdebb1fbbf4d4576900a2e
nanonyme: (which I recall airlied blaming on gnome screensaver)
spstarr: airlied: this might be why KMS locks up for me?
spstarr: <- W500
airlied: spstarr: our w500 wouldn't even boot
airlied: spstarr: lockups later are probably a different commit
spstarr: which model is your w500?
spstarr: Product Name: 4058CTO
spstarr: Version: ThinkPad W500
airlied: don't have access to it now
spstarr: builds drm-next + kernel.org git
glisse: airlied: the bugs list is shrinking :)
airlied: glisse: \o/ I woke up to no pings this morning
airlied: which was good since saturday ;-)
spstarr: PM for atomic bios
glisse: yeah, well still couple of interesting bug, for instance dual screen issue on r700 hw
glisse: well more stuff to keep me busy, but i think i will have time to hack on ttm stuff
spstarr: oh, these are hooks only
twnqx: airlied: does that mean pm is supported, or that the infrastructure for pm is there now?
Luzipher: glisse: what's the issue with dual screen on r700 ?
glisse: Luzipher: it seems on some configuration second screen stay in vblank mode
glisse: sounds weird, sometimes switching btw connector makes things work
Luzipher: hmm, ok ... never had that issue ... i guess there is a bug report ?
Luzipher: oh, thanks :) I was searching already ;)
glisse: first one is wrong
glisse: airlied: https://bugzilla.redhat.com/show_bug.cgi?id=531174
glisse: i don't understand what is the bug their
glisse: it was about the ncurse install screen not using fullscreen but the fb is reporting to set a mode which match native lvds resolution
glisse: thus i think if he want to complain about ncurse dialog not filling the screen, drv-ati shouldn't be help responsible
airlied: glisse: my r700 works fine
airlied: quite annoying
glisse: airlied: mine seems to work too, ...
airlied: I thought some of Alex fixes might help
airlied: there was fdo bug as well
glisse: maybe it's i2c bogus monitor which goes into sleep mode after i2c acitivities
glisse: anyway enough bug diving for me
twnqx: airlied: does that mean pm is supported, or that the infrastructure for pm is there now?
airlied: is the fdo bug
twnqx: just so i can sleep :>
airlied: twnqx: no it means you can read memory/ngine clock from debugfs
twnqx: so no need to upgrade
twnqx: btw, can it be that the system bios modifies clocks from SMI mode?
glisse: airlied: interesting
airlied: yeah its wierd disabling VGA2 can screw things
airlied: so alex fixes didn't seem to help
twnqx: after i unplugged my laptop from power for a moment my system feels pretty sluggy :X
twnqx: and it somehow limits the cpu clock to 800mhz while on battery
glisse: yeah i think we need to go through VGA reg list see if there is somethings obvious
twnqx: anyway, good night :)
glisse: yeah me too
agd5f: what's weird is that we have disabled vga control for years in ums
Ralesk: I just compiled myself a 184.108.40.206 kernel, and I'm getting a nice native resolution console on my 1680x1050 screen, but can't do DRI with my radeon9600 in X. any idea?
soreau: Can you pastebin your X log?
Ralesk: I'll try, moment
mzz: "LIBGL_DEBUG=verbose glxinfo" may also be interesting
chithead: for kms you need xf86-video-ati from git
mzz: but yes, Xorg.0.log first
chithead: if it complains about drm version, then your xf86-video-ati is too old
Ralesk: lines 381-384 :/
mzz: not sure what that one is, but guessing dmesg may have clues
mzz: also make sure you're on git xf86-video-ati
Ralesk: definitely am not, it's a 6.12.4 IIRC
mzz: that won't work, although I was expecting a more obvious error message
chithead: (II) Module radeon: vendor="X.Org Foundation" compiled for 1.7.1, module version = 6.12.4
chithead: definitely too old for kms
mzz: (is it expected behavior that it still *starts* in this mode, even though there's no drm?)
Ralesk: what to do? (particularly interested from the viewpoint of a distro, me being the X packager among other things, and intel and nvidia(closed)-beta both work decently... -- we want to ship a setup that the users don't need to tweak)
chithead: ship a git snapshot like fedora does
chithead: or bug airlied into tagging a kms capable release
Ralesk: mmhm. any commit-id you'd recommend checking out?
Ralesk: (I wish git had at least the option of an incremental revision id like hg does, wouldn't mess with version schemes c.c)
mzz: Ralesk: it usually makes sense to use the date in your distro version number
Ralesk: true. It's more of a laziness (and script cleanliness) matter :) with SVN and Hg we can say the $UB_VERSION is 0.2.3~r12345, and then setup the acquire script to download the right revision, etc. Once. From then on, we can just bump the version variable and everything keeps working. With the hash IDs there's no such linearity unfortunately :)
mzz: still should be possible to script around that (having your scripts figure out the nearest revid from a sufficiently specific timestamp or the timestamp to use in the new version from a revid)
Ralesk: I'll think about that :)
Ralesk: anyway, can you give me an URL ± git revid to build?
mzz: sorry, I'm not the right person to ask about that
Ralesk: ah, yay for cgit's snapshots :) building master now
Ralesk: hmm, well, the master complains about similar things too...
Ralesk: EXA is just as slow, XAA is faster but with plasma delays :/
Ralesk: ah, good job, didn't notice there was a kms-support branch
chithead: the branch is dead, don't use it
Ralesk: seems quite old though, 4 months :/
Ralesk: eh, yes :)
Ralesk: failed to load kernel module radeon... hmm
chithead: dmesg will maybe tell why
Ralesk: nothing related there, unfortunately
chithead: try to load the module manually before starting x
Ralesk: ahhh, I messed up something in my kernel install :)
Ralesk: been way too long ago since I compiled my own kernel, heh :)
qknight_: i have a question i think i can't find any info on on the net
qknight_: which card of these two is better in regards to 3d performance: ATI Mobility Radeon HD 3650 vs NVIDIA GeForce 9400M graphics
Ralesk: well, now that my modules dir is in place, I get Module radeon not found. Hmm.
Ralesk: there we go, missed that config option
rwilco: there seem to be some regressions with the latest drm-next. [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
rwilco: anyone know anything about this?
rwilco: sorry, my mistake. seems fbcon wasnt being loaded
Ralesk: chithead → radeon is in, things are disgracefully slow
chithead: maybe you are missing firmware, see channel topic
cxo: rwilco, i wonder why DRM cant just request fbcon as a module dependency
chithead: in principle, fbcon is not needed for modesetting
rwilco: cxo, it believe it did before the latest commit
rwilco: i never had to load fbcon manually before compiling the latest commit in drm-next
rwilco: chithead: i understand what you're saying but is there any real scenario where you'd want modesetting without fbcon
chithead: maybe you don't want console at all, or you want vga text console
cxo: has a piece of cheese cake he wishes to donate to the person working on r700 code
Vash63: Just mail it.
Vash63: Cheesecake is totally mail-friendly.
|wilco|: so you.. uh. .uuencode it?
qknight_: how can i find out if the 'ATI Mobility Radeon HD 3650' is supported by the radeon driver? and what state the support is in
biotube: qknight_: it's supported
qknight_: biotube: 3d as well?
biotube: in dev versions
qknight_: do you have a souce you could direct me to?
biotube: see the topic
chithead: qknight_: you need kernel 2.6.32_rc1 and check out mesa from git master for 3d on that card
qknight_: so if i buy this laptop i won't end up with having a laptop with bad graphics cards (as i had been with the X300 for years)
biotube: you'll be without power management for a while
qknight_: so is this 'actually' a good idea to buy a laptop with this card (the laptop i plan to buy has a Intel Graphics Media Accelerator X4500MHD as well)
qknight_: so maybe i can live with no ati support for a while
qknight_: biotube: ok, no power management but maybe in 6months?
biotube: I don't know any timeline
chithead: eh, switchable graphics
qknight_: is that bad?
chithead: switching has to be done in the bios, x.org/linux does not support that yet
chithead: other than that is will work
qknight_: thanks for your feedback!
qknight_: i will think about that then
qknight_: on the other hand, will the fgrlx driver have power management and 3d for this card?
biotube: but it's got its own problems
biotube: on my 3450, TTY switching hung the computer
biotube: I don't know
qknight_: thanks again
cxo: qknight_, you can never go wrong with a ThinkPad
spstarr: likes his ThinkPads
chi: thinkpad <3
chi: is sporting a T30 untill his x200 arives
chi: arrives too
soreau: guesses etqw needs npot texture support
soreau: probably needs gl2.1 altogether
spstarr: chi: just note the newer thinkpads have no recordable PCM out
spstarr: (you can use jackd to get around this however)
cxo: this business of being able to switch into a tty seamlessly is really nice
cxo: keep it up guys
spstarr: it's shine hasn't worn off has it, cxo
cxo: when you've been deprived all your life from such simple things, even the slightest improvements are quite refreshing
spstarr: i just finished building drm-next + kernel.org, libdrm git master, mesa master, radeon ddx master
spstarr: ready to test dri changes later today
spstarr: i am curious if KMS hangs or not on the r6xx
cxo: doesnt hang on r800
cxo: whats drm-next?
spstarr: the latest changes in kernel drm
spstarr: including radeon, intel and drm/ttm
cxo: so drm in the freedesktop git is only userspace?
spstarr: drm is kernelspace
spstarr: dri is userspace driver that interfaces with the drm
cxo: yeah i know that, but where is the kernel drm module housed then?
cxo: in kernel.org git?
spstarr: drm-next is airlied's git branch
spstarr: that merges into kerne git master when Linus pulls it
cxo: can you just build drm module only, or do you need to patch that into vanilla source and then rebuild?
spstarr: in this case, the whole kernel
cxo: will stick to smooth jazz for now, kernels can always be built tomorrow
spstarr: failed worse
spstarr: DRM loaded firmware, then it hung bootup.. although i could type in the console, it failed to continue
spstarr: it also showed wrong memory info?
spstarr: VRAM = 256MB, GTT = 512MB?
spstarr: this card has 512MB VRAM i thought
spstarr: [drm] Detected VRAM RAM=256M, BAR=256M
spstarr: [drm] radeon: 256M of VRAM memory ready
cxo: isnt half used for textures and the other half used for something else
spstarr: [drm] radeon: 512M of GTT memory ready.
spstarr: [drm] Loading RV635 CP Microcode
spstarr: it loads firmware then it hangs with KMS on
spstarr: cxo: I remember airlied or agd5f mentioning that drm does not handle more than 256MB yet?
spstarr: for vram size
spstarr: logs bug on fdo