Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-19

Search This Log:

EruditeHermit: what happened to engadget
flyback: mishehu, of tracker fame?
cxo: does a late night pull
cxo: git pull that is :)
amarks: and may it bring you peace and joy
cxo: is so full of peace right now... gets drowsy... goes to bed
gabrimonfa: Hi all, I have an error compiling fresh git copy of radeon driver on a amd64 system
gabrimonfa: drmmode_display.c:82: error: expected declaration specifiers or ‘...’ before ‘drmModeModeInfo’
gabrimonfa: no problem during configure. Default path. KMS: yes
spreeuw: use only dridrivers swrast,rx00
spreeuw: unless that file is something shared by all drivers you may get past the error
MrCooper: that's the X driver tree, not Mesa
MrCooper: looks like it's not picking up xf86drmMode.h, or maybe a stale one
gabrimonfa: @MrCooper. You're great! I forgot I've played around with drm in the past in order to have modesetting with r600. Removed that all compile again! @spreeuw: thanks a lot also to you
Niek-work: Hi there. I believe I just installed radeonhd drivers. After a restart, I'm not noticing any significant changes. How can I doublecheck if I'm using radeon or radeonhd? (lspci -v?)
yangman: Niek-work: check your X log. /var/log/Xorg.0.log
yangman: Niek-work: and you shouldn't notice any changes. if whatever the default is works for you, there's really no reason to switch
Niek-work: yangman: oh okay, I was hoping the radeonhd ones would let me enable compiz.
yangman: compiz requires 3D, which is provided by mesa. what X driver you use is mostly irrelevant
Niek-work: Seems to have loaded I think.. http://pastebin.ca/1677600
Niek-work: Oh I see. I thought the driver took care of that.
yangman: see http://yangman.ca/blog/2009/10/15/linux-graphics-driver-stack-explained/ for a fairly high-level overview of how the different parts interact in graphics
Niek-work: Cool thanks. :) I'll sneak a read. (i'm "working" afterall)
hifi: umm, does radeonhd and radeon share the same mesa and drm stuff?
yangman: hifi: yes
hifi: why was radeonhd needed again?
yangman: long story
yangman: (by which I mean we don't really like talking about it)
yangman: lets just go with "it was a good idea at the time"
hifi: radeonhd will be discontinued?
MostAwesomeDude: crosses fingers
Niek-work: yangman: Interesting read. Should be topic'd. :)
Niek-work: Thanks for that.
yangman: :)
yangman: MostAwesomeDude: hah
lordheavy: wow with radeon-text-rexrite; branch master vs 7_7; openarena benchmark jump from 23 fps to 63 fps :-) nice !
hifi: !
hifi: must test
hifi: lordheavy: pardon, where is that branch located?
hifi: oh, osiris is writing that
hifi: and I already tested that
lordheavy: mesa_7_7_branch
hifi: ah, he merged it
Zajec2: agd5f: ping
lordheavy: no more texture corruption in nexuiz :-)
glisse: Zajec2: he is likely asleep
Zajec2: glisse: have to learn your timezone guys :)
Zajec2: before agd5f awakes, maybe some could try to understand my crashes? http://estudent.put.poznan.pl/rafal.milecki/kernel/
Zajec2: 4 crashes from standard KMS
Zajec2: 2 from modified when I tried to make atom atomic
glisse: all this is with your patch to reclock stuff ?
Zajec2: glisse: yup
Zajec2: mod_timer
glisse: disable atombios debug it swallow the kernel oops message
Zajec2: using netconsole
Zajec2: i thought it's some operation in atombios that causes it... so that's why i enabled
Zajec2: will try disable as u say
Zajec2: ok, going school now, have kernel compiled without debug
Zajec2: will test when back
Zajec2: glisse: i modified two SDEBUG in atom.c to direct
Zajec2: printk(KERN_DEBUG ">> execute %04X (len %d, WS %d, PS %d)\n", base, len, ws, ps);
Zajec2: shoud give idea about eventual parallel calling of execute_table
Guest58606: Oh please make radeon opensource drivers better.
Guest58606: Human eye is used to ~25 fps
Guest58606: Compiz benchmark shows I have only ~23 fps :D
Guest58606: all animations look a bit lagged
Guest58606: ok, now only 17 fps
Guest58606: using expo gives ~16fps :)
spreeuw: what game?
Julia_: no game
Julia_: gnome desktop
spreeuw: dont use composite if it bothers you
Julia_: well, I need compiz
Julia_: it bothers me that I have ~20 fps with only compiz on.
Julia_: it can't be that everyone has problems this problem with so low fps.
BCMM: i am experiencing a regression between kernels 2.6.32-rc6 and 2.6.32-rc7 when using xf86-video-ati
BCMM: openGL apps crash X (even glxgears), and i cannot switch VTs without KMS
BCMM: where should i report this?
Julia_: sometimes when there is high CPU activity, FPS increases
Julia_: weird
Julia_: I am now installing updates and when CPU graph spikes to 100% I get more then 30 fps
Julia_: this is so weird
lordheavy: BCMM same problem here, resolved with mesa from git (or next mesa 7.6.1)
BCMM: using mesa from git
BCMM: i rebuilt it just a few minutes ago and still got it
bridgman: Julia, that doesn't sound like a driver issue unless you're running sw rendering
bridgman: more likely your CPU power saving is kicking in or something
Julia_: so what should I do?
BCMM: lordheavy: i rebuilt libdrm, mesa and xf86-video-ati, and then rebuilt xorg against the new mesa, before thinking about reporting the problem
BCMM: which bugzilla should i post to?
bridgman: start by giving us more info, I guess; on a low end HD3xxx I can run fullscreen video smoothly under compiz and I think that's the norm
Julia_: videos run just fine
bridgman: how can they at 20 fps refresh ?
Julia_: when I have only firefox or skype opened I get low fps
lordheavy: BCMM got something useful in logs ?
Julia_: when I watch movies there are no problems
bridgman: there's a command to read the instantaneous cpu speed but I don't remember what it is - anyone ?
BCMM: lordheavy: [from dmesg] [drm:r600_cs_packet_next_reloc_nomm] *ERROR* No packet3 for relocation for packet at 47.
BCMM: and a bunch more like that
bridgman: maybe just cpuinfo or sth
BCMM: don't wanna flood here
BCMM: but i can pastebin it
Julia_: I am running dvd video and I get ~30 fps
spreeuw: Julia_: try disabling software fallbacks
Julia_: how? where?
spreeuw: or lowering some quality settings of composite if this is supported
Julia_: btw this is laptop I am using
spreeuw: disable some effects or so
spreeuw: Julia_: driconf
Julia_: Could not detect any configurable direct-rendering capable devices. DRIconf will be started in expert mode.
lordheavy: BCMM i guess a bug report can be useful
BCMM: lordheavy: bug report where? freedesktop or kernel.org?
lordheavy: freedesktop
adamk_: Julia_, You ran that as your normal user?
Julia_: sudo
adamk_: Why? :-) No one said to use sudo...
taiu: Julia_: what's glxinfo |grep render
Julia_: direct rendering: Yes
Julia_: OpenGL renderer string: Software Rasterizer
taiu: Julia_: well you don't have accelerated 3d at all
taiu: Julia_: paste your xorg.log to some pastebin
Julia_: sucks...
Julia_: xorg.0.log?
adamk_: As well as the *full* output of 'glxinfo'
taiu: jep
adamk_: BTW, does 'driconf' work without sudo?
Julia_: adamk, here you go http://pastebin.com/d7a29d159
Julia_: Here is glxinfo: http://pastebin.com/d6356122f
adamk_: DRI is enabled in the Xserver, but your GL libraries are screwing something up.
Julia_: possible solutions?
taiu: Julia_: do the last one again with: LIBGL_DEBUG=verbose glxinfo
adamk_: Run 'LIBGL_DEBUG=verbose glxinfo'
adamk_: And pastebin the full output.
taiu: probably permissions on /dev/dri ...
Julia_: here
Julia_: http://pastebin.com/d3e37186c
spreeuw: 20fps is quite good in that case
adamk_: Julia_, That was the full output? There should have been debug information at the top. You didn't redirect the output, did you, or use | to pipe it somewhere?
spreeuw: before I ditched composite 2 years ago it was alot slower
Julia_: I wrote "LIBGL_DEBUG=verbose glxinfo > Desktop/fullth"
Julia_: an then I copy/pasted output in pastebin
Julia_: it is all there is
Julia_: should I use sudo?
adamk_: No, but you shouldn't redirect the output either.
adamk_: Just run it in a terminal and select it all. :-)
Julia_: ok :D
Julia_: there
Julia_: http://pastebin.com/d48ad6de1
Julia_: this one has 10 more lines
spreeuw: libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: radeon_bo_is_referenced_by_cs)
adamk_: I'm pretty sure you need to update libdrm.
spreeuw: didnt someone report the same thing above?
adamk_: http://www.phoronix.com/forums/showthread.php?p=100524
adamk_: Someone on phoronix reported that with r600, and agd5f said to update libdrm.
adamk_: Make sure it's compiled with KMS support.
Julia_: umm
Julia_: what?
hifi: isn't that caused by osiris' patch
adamk_: Julia_, How did you install your drivers? Did you compile them yourself, or are these a set of drivers from your distribution?
Julia_: these are from launchpad ppa. I am using Ubuntu Karmic
Julia_: I had problems with watching videos some time ago
Julia_: and good guys from here told me to try those packages
Julia_: it worked for videos and I didn
adamk_: Yeah, well those packages somehow screwed things up :-)
Julia_: and I didn't get any glitches. only thing that now I have bad fps :D
Julia_: ok
Julia_: so..
adamk_: Right, because you don't have 3D acceleration.
adamk_: At all :-)
Julia_: :D
Julia_: ok what should I do ?
adamk_: If agd5f's post is correct, you need to update your libdrm. I would start by making sure you are using the libdrm from that ppa repo.
Julia_: 2.4.15+gut20091116.c20706ff-0ubuntu0tormod~karmic
Julia_: I use that one
Julia_: *2.4.15+git...
Julia_: that is libdrm-radeon1 package
Julia_: and same libdrm2
Julia_: wait. I will restart my pc.
adamk_: Unfortunately, I really don't know much about the PPA repos or what they contain.
Julia_: hihi
Julia_: now my gnome session crashes :D
Julia_: after weekly upgrade I log in, get connected to internet and my gnome crashes. I think it is because of notify-osd
Julia_: damn.
Julia_: Well I knew that I should do clean install some day. I think this day has come :D
TBBle: Should I expect 6.12.3 to build against xserver 1.7? I'm getting a failure with X11/extensions/dpms.h:40 which I suspect isn't limited to the driver, based on google, but I can't seem to actually solve by simply including extra headers.
TBBle: Ah, got it. dpms.h => dpmsconst.h for server-side building.
lordheavy: adamk, julia : got the same problem; mesa need to be rebuild against the new libdrm
lordheavy: adamk_
lordheavy: julia_ :-)
Zajec2: glisse: !!
Zajec: glisse: i got it :D
Zajec: glisse: that was so obvious
Zajec: just think about "[ 64.828119] BUG: scheduling while atomic: swapper/0/0x00000103"
Zajec: function called from timer is supposed to be atomic (that's timer assumption I believe)
Zajec: but in this function we call atombios_execute_table which uses scheduling!
Zajec: :)
Niek-work: One more question. If radeon and radeonhd differ so little why is it that nomodeset needs to be added if you want to use radeonhd?
Zajec: Niek-work: radeonhd doesn't support KMS
Zajec: no reason fro that as this would be identical to support in radeon driver
Niek-work: Hm so in theory, I would be able to have the same performance capabilities switching back to radeon and have KMS.
Niek-work: (for you KMS probably means something different, for me it means shiny boot screen :P)
glisse: Niek-work: kms is much more than that basicly it moves all the radeon code into the kernel
glisse: there isn't much left in radeon beside exa when kms is activated
Zajec: glisse: could we modify atom parser to don't use schedule?
glisse: no
Zajec: glisse: or should I sth different than timer_list?
Zajec: ok, i'll try to google how to make timer not atomic
glisse: Zajec: we should use workqueue like mjg59 patches were doing iirc
papillon81: MrCooper: you said you committed changes for big-endian machines to the KMS code. where did you put these? Mesa or kernel git ?
MrCooper: pretty sure I said Mesa
MrCooper: I fixed the kernel a while ago
papillon81: MrCooper: good :-)
MrCooper: the dmesg you showed looks like it should work, albeit only with PCI GART instead of AGP, which hurts performance a lot
MrCooper: try passing radeon.agpmode=1 on the kernel command line
papillon81: MrCooper: will do
Zajec: glisse: mjg59 used IRQs which we don't have yet
glisse: Zajec: no i think there was a workqueue, irq were use to know if engine was idle iirc
Zajec: glisse: it used irq handling to schedule reclocking, the idea was to avoid blinking on memory reclocking
Zajec: glisse: but for engine reclocking we don't have to watch VBLANK, so i don't want to schedule engine reclocking from irq interrupt handler
Zajec: glisse: and problem is/will probably more general
Zajec: glisse: agd5f hit the same crash when using timer for HDMI
glisse: what crash ?
Zajec: glisse: err, sorry, bug
Zajec: glisse: bug/oops/.... don't know terminology sorry
Zajec: i mean "BUG: scheduling while atomic"
Zajec: Christian used timer for HDMI in his patch and agd5f testing that hit the same BUG (scheduling while...)
glisse: HDMI ? audio you mean ?
Zajec: yup
glisse: well i will need to review atomparser iirc there is a good reason for it not being atomic and beside it's way too big to become such
Zajec: it's just something unexpected for me that kernel wants me to be atomic in my own timer's handler
Zajec: glisse: in atom.c we use schedule for delay only
glisse: look at workqueue they are likely more suited for what you want to do
Zajec: delay as atombios's command
Zajec: glisse: but i need timer... something that will fire regularry
Zajec: in workqueue i can not give idle time AFAIR
glisse: you can give experiration time iirc
Zajec: will check LDD again for some other timer-related "things" maybe
Zajec: do i?
Zajec: will check
Julia_: so I am now on clean Ubuntu Karmic
Julia_: Installed compiz settings manager to enable benchmark plugin
Julia_: what do I have to paste to pastebin for you to check if my 3d acceleration is working?
spreeuw: glxinfo
Julia_: 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]
glisse: glxinfo | grep render
papillon81: MrCooper: some problems after boot. DE is started, but then this crash happens: http://pastebin.com/d13eb38c0
papillon81: well, no crash
glisse: papillon81: gpu lockup
Julia_: firefox is kind of slow...
tormod: Julia_, firefox does not use 3D
Julia_: http://pastebin.com/m44f13e0
Julia_: :D
Julia_: said that because I had to wait while it starts up.
Julia_: :D
Julia_: anyway there is output :)
Julia_: direct rendering: Yes
Julia_: OpenGL renderer string: Mesa DRI R300 (RS690 791F) 20090101 x86/MMX+/3DNow!+/SSE2 NO-TCL
Julia_: and still only ~20 fps
glisse: Julia_: we are significantly slower that the closed source driver
Julia_: I know but is there really no way to make compiz faster?
Zajec: Julia_: show "xrandr | head -n 1"
Julia_: Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 1680 x 1680
Zajec: it's ok
glisse: you got a pretty big screen for such gpu
Zajec: or not... ;)
Julia_: Screen is not big. I have small pixels :D
Zajec: does Ubuntu Karmic mean 9.04? 9.10?
lordheavy: 9.10
Julia_: 9.10
Julia_: at least I have 3d acceleration out of the box with Karmic :)
Julia_: It makes me happy :)
Zajec: ups, distrowatch doesn't show Mesa version for distro
glisse: i get lost too with ubuntu name, version number is lot easier
Zajec: Julia_: what is your Mesa package version?
Zajec: I'm afraid it will be 7.6 so no much place for implevements
Julia_: one moment
Zajec: if I get it correctly 7.6 should be better than 7.5 due to rewrite of radeon
papillon81: had to go through a hassle with karmic and nvidia, as there was only a black screen after booting the install/live cd and after installing karmic as well. dunno why the do not use nouveau initially
Zajec: but if you already have 7.6 no much more we can do for now I am afraid
Julia_: what is the name of mesa package?
Julia_: umm
Julia_: 7.6.0
Zajec: uhm :(
papillon81: Zajec: but generally, there is room for speedups?
Zajec: papillon81: don't know much about that
Zajec: for sure there is something we can do, just compare with fglrx
Zajec: it does some things better
Zajec: i thought we will be like fglrx after introducint MM (TTM/GEM/...)
Zajec: but it doesn't seem so
Zajec: don't know what is now a bottleneck
papillon81: well, as long as it is going forward like it does currently...
glisse: Zajec: memory manager is the bottleneck
papillon81: IMHO the 2d stuff is faster with KMS and radeon compared to fglrx
glisse: then for 3d there is the lack of plageflipping & hyperz
Julia_: ok, thank you for help
Julia_: :)
Julia_: I guess I will somehow live with my low fps :D
Zajec: did you notice Phoronix didn't notice GLSL?:)
logari81: Zajec: you are too fast for them to follow
Ronis_BR: hi all
Ronis_BR: i'm getting conflicts when I try to merge drm-next into kernel 2.6.31
quintela: if xrandr tells that maximum Screen 0 is 3968x1920 is there a way to convince it that I want 4096x1152?
Ronis_BR: can anyone help me?
quintela: this is a hardware limit, or a software one that can be changed?
mishehu: flyback: indeed, it is I.
mjr: it might be a matter of setting the Virtual framebuffer resolution in xorg.conf
flyback: cool
flyback: ltns
flyback: I am fishhead/i8086
flyback: or what's left of him :/
quintela: mjr: that was for me?
mjr: quintela, yeah
mjr: I'm not sure why the limit would be something strange as 3968 currently though
rxt0: May I ask, which parts of R500 cannot be open-sourced due to patents?
stikonas: what do you mean by open-sourced? Available documentation?
Ronis_BR: I'm following the guide exactly
rxt0: exactly
Ronis_BR: and I'm having many conflicts
stikonas: there will be more and mode conflicts as 2.6.31 and drm-next diverge
chithead: rxt0: some parts cannot be opened (such as tv-out copy protection and uvd) others will not be open sourced (such as firmware)
stikonas: there is nothing you can do about that
Ronis_BR: stikonas: so, what can I do? :)
stikonas: resolve them by hand
stikonas: or use a newer kernel
Ronis_BR: O_
Ronis_BR: O_o
stikonas: 2.6.32 is quite stable
rxt0: stikonas: But IIRC, R500 doesn't have UVD
Ronis_BR: tuxonice isn't available
chithead: rxt0: there exists at least one r500 with uvd, namely mobility radeon hd 2300
rxt0: Right, but what about typical R500's? I know they contain some type of hw acceleration of video decoding
chithead: non-uvd radeons contain some mpeg-2 acceleration hardware, but this is not so interesting nowadays
rxt0: Are there docs about it? and what about CrossFire?
chithead: all amd docs are released here http://www.x.org/docs/AMD/
Ronis_BR: I just doesn't understand why ATI doesn't open fglrx source code ...
adamk_: Ronis_BR, Probably IP issues.
Ronis_BR: adamk_: IP?
rxt0: There is a lot of discussion about that on Phoronix forums, is mainly due to DRM stuff
adamk_: Intellectual Property.
glisse: it's likely that they don't own the ip of some part of fglrx
quintela: error setting MTRR (base = 0xe0000000, size = 0x10000000, type = 1) Invalid argument
Ronis_BR: rxt0: hum
quintela: any clue?
glisse: not mentioning that going through fglrx source would be a pain for their lawyer
Ronis_BR: glisse: make sense
Ronis_BR: :D
quintela: mjr: you are my hero, that small change fixed it
quintela: happy now with this dual head setup
quintela: thanks very much people
mjr: yeah; that virtual framebuffer size is one of the few things that can't yet dynamically be changed, sadly
glisse: mjr: with kms you can
MostAwesomeDude: r500 doesn't have on-board dedicated video decoding.
quintela: mjr: I agree that 2048x1152 monitors are not common yet :p
MostAwesomeDude: It's all done in shaders.
mjr: glisse, good
rxt0: does x1600 have the power of decoding 1080p with shaders?
MostAwesomeDude: 1080p *what*?
MostAwesomeDude: x.264? Maybe. Depends on how much performance we can squeeze out of the chipset.
MostAwesomeDude: MPEG-2? Sure.
quicksilver: MostAwesomeDude: depends how much assist you count on the CPU for, too
quicksilver: there's more than one way to write an x.264 decoder.
quicksilver: none of them easy IMO, but it's not my field.
MostAwesomeDude: quicksilver: Actually, the only hard part is getting distros to pick it up.
quicksilver: I stand corrected.
quicksilver: It's really easy, just not for me :)
Zajec: has two news :) bad and good
Zajec: 1) i've dynamic downclocking working
Zajec: 2) it causes corruptions and locks ups :)
Zajec: corruptions when using heavily Xv
Zajec: locks up when reading debugfs in a loop
agd5f: Zajec: sounds like you don't quite have it working then ;)
mishehu: yeah, "not crashing/locking/corrupting" seems to be part of the definition of "working"
Zajec: agd5f: compare it to locking up on every reclocking attemp... and you will really believe it's working ;)
Zajec: agd5f: lock up is general issue I believe
Zajec: KMS doesn't like reading debugfs in a loop
Zajec: don't know what about corruptions with Xv :|
Zajec: hopefully it's just engine that is not idle
TCW: KMS does mind a debugfs run? We are talking about the extN-debugfs-tool?
Zajec: TCW: ?
Zajec: while [ 1 ]; do
Zajec: cat /debugfs/dri/0/radeon_pm_info
Zajec: done
Zajec: this locks up after some seconds
TCW: Zajec, I know debugfs as a tool to debug ext2-4 filesystems... so I guess you are talking about something else :)
Zajec: TCW: debugfs is just file system, every kernel part can use it to export some info
Zajec: TCW: radeon does it as well
TCW: $ apropos debugfs
TCW: debugfs (8) - ext2/ext3/ext4 file system debugger
Zajec: oh
Zajec: interesting ;)
TCW: yeah :)
Zajec: huh, i didn't know that one :)
TCW: Zajec, a tool one needs to... debug extN filesystems :)
Zajec: agd5f: did you read today' archive about mod_timer?
Zajec: agd5f: i finally found out why mod_timer locks up machine
Zajec: agd5f: probably same problem you got with HDMI testing
agd5f: Zajec: what was it?
Zajec: agd5f: there is DELAY command in atombios
Zajec: agd5f: when atom parser find that command it schedules itself
Zajec: and nothing in function from mod_timer can schedule
Zajec: it's atomic
TCW: Zajec, rather low-level but can get very useful in severe filesystem-corruptions
agd5f: Zajec: ah
tball: Hello guys
tball: How is powermanagement with kms going?
kdekorte: tball, being worked on, but still buggy Zajec is doing it
tball: kdekorte, Is it buggy because Zajec is doing it? ;)
tball: jff, know what you mean
biotube: it wouldn't exist if he weren't working on it, so yes it is buggy because of him
tball: Is it more advanced powermanagement than the simple powermanagement included in radeon / radeonhd?
kdekorte: He said this morning it wasn't hard locking the machine any more, but there was screen corruption. So that means he is probably slowing it down too much
tball: I.E. dynamic powermanagement
cxo: Whats tnl?
adamk_: http://en.wikipedia.org/wiki/Transform,_clipping,_and_lighting
adamk_: Sometimes TNL, T&L, or TCL
MostAwesomeDude: In Mesa, the TNL pipeline is a way for fixed-function drivers to do TCL fallbacks. It's icky.
adamk_: Ahhh, I didn't realize there was a Mesa specific definition of TNL :-)
MostAwesomeDude: Well, Mesa's got a tnl library.
MostAwesomeDude: Usually, we use the term TCL for the hardware: fixed pipeline on old cards, and the vertex shader pipeline on new cards.
adamk_: So does this new GLSL support in Mesa help gallium3d drivers at all?
MostAwesomeDude: Kinda. It speeds up the GLSL->TGSI loading process.
MostAwesomeDude: But those are usually one-time costs anyway.
cxo: wants to code drivers too
eosie: they go for it
eosie: *then go for it
cxo: I've written basic drivers before and I can basically anything in C and ASM. But I cringe at the thought of learning all this GL stuff and graphics architecture... too lazy to learn... too pumped to code
cxo: So if there's any boiler plate code, interfaces, wrappers, etc.. stuff to do, I'd like to do it
MostAwesomeDude: Nope.
MostAwesomeDude: Not really.
MostAwesomeDude: This is the nightmare mode of driver-writing. Very little interface needs to be written, just a lot of code to drive a lot of HW.
cxo: Yeah, so you need to stare a data sheets all day
eosie: cxo: provided you know GL, you can start learning Mesa internals now, 3D drivers are not different from GL or D3D (of course it's better to know both, because the pipe driver interface looks more like D3D)
cxo: feels the pain
simplexe1: Nov 19 21:28:44 arch kernel: [drm:radeon_cp_indirect] *ERROR* sending pending buffer ХХ
simplexe1: wtf?
gimzo: osiris_: where did you push your blit stuff? I don't see any difference on master?
hifi: r300-blit is in his own repo
gimzo: so where do I find it ?
hifi: http://cgit.freedesktop.org/~osiris/mesa/
gimzo: thanks
hifi: radeon-texwrite-clean was pushed to mesa 7_7 branch
gimzo: but not to master?
hifi: I think not
gimzo: ok, thanks
osiris_: gimzo: mesa_7_7_branch will probably be merged soon to master
cxo: i thought master is always the dev version and releases are just tagged from that?
spreeuw: it is, but people dont always share their work to the same copy of master
eosie: new features go to master, bug fixes go to mesa_x_y_branch and are later merged to master, it's logical
gimzo: osiris_: i get "warning: remote HEAD refers to nonexistent ref, unable to checkout."
spreeuw: but peoples private git copies dont always have all work from other people right?
eosie: right
gimzo: I think I'll wait for the merge
osiris_: gimzo: after git clone, just do git checkout -t origin/ -b
gimzo: ok, thanks
whitecat: hello*
whitecat: Since Fedora 12 release, many people (me include) are answering (at least in French fedora forum) how the "mesa-dri-experimental" works with "radeon".
whitecat: Is "mesa-dri-experimental" a package that enable some features disables by default in "radeon" ? Or thats working in other way ?
agd5f: whitecat: it's updated 3d drivers. nothing to do with the 2d driver
whitecat: hum, radeon is ONLY a 2D driver ?
twnqx: no
whitecat: so the package "mesa-dri-experimental" provide by fedora 12 is an update to the 3D engine of radeon ?
whitecat: *provided
chithead: mesa-dri-experimental contains additional 3d drivers for radeon hd 2400 and later cards
eosie: whitecat: radeon is a 2D and Xv driver, the 3D driver is always part of mesa-dri
whitecat: eosie: ok! I didn't know that. (I'm not X11 dev ;-) just user )
Tanktalus: hopes the failure-to-repaint-properly problem in xorg 1.7.1 gets fixed soon :-(
whitecat: thank you for your answers
cin|bleh: hi are there some bugs reported with igp chips in the past few days ?
cin|bleh: i installed new drivers and now i just get a black screen with a white strip ::/
cin|bleh: since version 6.12.99.git20091014-1 my radeon igp 330m nice work guys :/
cin|bleh: is not working :O this suxx
MostAwesomeDude: Have you tried going back to the previous version?
MostAwesomeDude: Are you using KMS?
cin|bleh: no i dont
cin|bleh: i tried to use a previous version the stock version from archlinux iso works
kdekorte: I have a question about the radeon driver with EXA. Are any of the primitives accelerated like line, point, rectangle? Or is that something that is not needed anymore?
MostAwesomeDude: kdekorte: EXA only has five ops.
cin|bleh: after arch installation i updated to this one 6.12.99.git20091014-1 and it stopped working
MostAwesomeDude: Solid, Copy, Composite, DFS, UTS. Only Solid and Copy are required.
MostAwesomeDude: Internally, nearly none of the primitives are fully accelerated, but that's alright, because nobody uses them.
kdekorte: MostAwesomeDude, so there is no way to use the video cards primitive acceleration if they exist?
MostAwesomeDude: kdekorte: Well, one could always plug in their own routines at the GC level.
MostAwesomeDude: But no, not really. Why?
kdekorte: Just looking at gtkperf and the circle test is really slow, so wondering if there was a way to use the r600s opengl circle/sphere code to do it
kdekorte: Also rounded elements are becoming more popular and if vectors are used to draw them, the arc could possibly be accelerated
MostAwesomeDude: Yes and no.
MostAwesomeDude: Yes, in theory. No, it'd be way too much code and I'd ask you to do it in xorg st instead of in radeon DDX.
kdekorte: I guess it requires the user interface code to call the X primitives to draw the arcs and lines for them to even be accelerated
MostAwesomeDude: Also when drawing X primitives, there are a *lot* of rules as to how it should look.
MostAwesomeDude: And you really don't wanna mess that up.
kdekorte: if everything is kept in say "cairo" it never gets to to card
spreeuw: scrolling around a bit in celestia, cool stuff
MostAwesomeDude: Well, that'd be a job for cairo-gallium or whatnot.
kdekorte: MostAwesomeDude, thanks for the tutorial.. it was helpful
MostAwesomeDude: kdekorte: No problem, ask whenever you've got questions.
MostAwesomeDude: I enjoy answering people that have sent in patches. :3
spreeuw: awesome, demo in celestia
spreeuw: on HD
unimatrix: i've just updated the radeon driver (from xorg-edgers launchpad ppa) and now every 3D/2D accelerated app is really slow and eats up all of my CPU
unimatrix: what could be the cause?
unimatrix: (compiz seems to be working fine though)
unimatrix: except the blur plugin which just crashed my X
soreau: unimatrix: The blur plugin needs things the driver does not provide yet, accelerated fbos
soreau: at least the alpha blur feature
soreau: So far as it running slow, do you see anything fun in syslog ?
soreau: unimatrix: fwiw, some effects like transparent cube are much more cpu intensive
Ghworg: unimatrix: What does "glxinfo | grep render" say?
Ronis_BR: hi all
Ronis_BR: the method present in how to to download the lastest drm-next isn't working
Ronis_BR: can anyone help me ?
soreau: Ronis_BR: What is the problem?
Ronis_BR: soreau: many conflicts...
Ronis_BR: soreau: maybe we can't use 2.6.31 anymore
soreau: right, not without messing with resolving conflicts
Ronis_BR: so how can I use 2.6.32 to get it?
soreau: The wiki needs to be updated badly
Ronis_BR: the latest one I think
Ronis_BR: nrn
soreau: You should try pulling drm-next on top of linus-tree
Ronis_BR: brb
airlied: kdekorte: notghing uses circles though, lines however could probaly be sped up as I think openoffice uses them
spstarr: who is Maciej?
spstarr: you on IRC?
osiris_: it's me
spstarr: osiris_: pingy
osiris_: pongy
spstarr: osiris_: ya, im testing daily mesa bits from 7.7
spstarr: im in the intel GPU at the moment but can reboot into the amd one
osiris_: no hurry
spstarr: osiris_: I have noticed problems using VBOs also
spstarr: but that maybe something else
spstarr: secondlife spits out
spstarr: nician_Markham_Stouffville_Toronto_121.htm
spstarr: er
spstarr: INFO: mapBuffer: GL_ARRAY_BUFFER_ARB size is 343480
spstarr: llrender/llvertexbuffer.cpp(821) : error
spstarr: ERROR: mapBuffer: glMapBuffer returned NULL (no vertex data)
spstarr: only when trying to enable Vertex Buffer Objs
Ronis_BR_: soreau: so, can you tell me what to do?
Ronis_BR_: to have the newest drm-next?
mattst88: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
mattst88: from there, pick which branch you want to track with:
mattst88: git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
mattst88: Ronis_BR: ^
soreau: We really need those instructions in the wiki :P
mattst88: Ronis_BR: did you see what I typed?
soreau: looks in airlieds general direction
Ronis_BR: mattst88: I want drm-next
Ronis_BR: mattst88: but drm-next doesn't work with linux.2.6.31.y :)
mattst88: dear lord. no point in trying to help some people.
spstarr: osiris_: I will be able to test any commits you make today/tonight
twnqx: Ronis_BR: works perfectly.
Ronis_BR: twnqx: no, I have tried today, toooo many conflicts
soreau: mattst88 :/
twnqx: one conflict year, two days back
twnqx: here*
soreau: Ronis_BR: Did you get the message mattst88 typed out for you?
Ronis_BR: soreau: yes
soreau: Did you read it? :/
Ronis_BR: soreau: yes...
Ronis_BR: soreau: I just didn't understand :D
soreau: Is there something you misunderstood about it?
Ronis_BR: soreau: i clone drm-2.6.git
soreau: ah ok
Ronis_BR: then ...
twnqx: who the hell understands git anyway >_>
Ronis_BR: how do I patch the kernel
mattst88: patch it with what?
Ronis_BR: I need one to be patched and installed right
Ronis_BR: mattst88: drm-next
soreau: Ronis_BR: From that cloned directory, run this: git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
chithead: Ronis_BR: cd /usr/src/linux; patch -p1 < /path/to/patch (try with --dry-run first)
mattst88: the second command does that. git checkout
Ronis_BR: chithead: I don't have the patch :D
soreau: Ronis_BR: You can use 'git branch -a' to see all the branches
mattst88: substitute drm-radeon-testing for drm-next or whatever you want.
soreau: right
Ronis_BR: mattst88: drm-2.6 has a full kernel copy so
Ronis_BR: mattst88: I'm asking because I need to add others patches, like tuxonice
twnqx: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git <-- what does that pull, actually?
mattst88: yes... that's how this works.
soreau: twnqx: Pretty obvious?
twnqx: not to me
mattst88: twnqx: it pulls dave airlie's kernel development tree and its branches.
mattst88: then you switch between the branches with git checkout.
gimzo: osiris_: I don't see any difference in today's master vs r300-blt: http://global.phoronix-test-suite.com/?k=profile&u=gimzo-6954-21052-18527
twnqx: could be anything from a pure drm module to a full kernel with 100G irrelevant old versions
mattst88: there's 'linux/kernel' in the path.
twnqx: yeah, but it's just a path.
mattst88: and I'm telling you what it is.
twnqx: anyway, if it's more than the few 100kb it's more than just a pain for anyone on a slow link
mattst88: it's large.
Ronis_BR: I thought there is a way to clone kernel 2.6.32 and just add patches I want
twnqx: checking just mplayer out with git took me like 2h
Ronis_BR: like drm-next
Ronis_BR: tuxonice
Ronis_BR: fbcondecor
twnqx: is there a way of getting "just the latest version as a diff for a vanilla kernel"?
mattst88: I'm not sure.
osiris_: gimzo: you'll only see the difference if an app is using glCopyTex[Sub]Image or glBlitFramebuffer
twnqx: because the fact that git downloads all the stuff i'm sure i'll never need is one of the most annoying misfeatures :X
mattst88: I don't guess that's such a big problem for most people using the tree, since they're pulling it for development, and not to patch in tuxonice.
osiris_: spstarr: I can't reproduce the crash here
gimzo: osiris_: I thought everything uses blit ?
mattst88: twnqx: git is for development.
twnqx: i'm pulling it because it's the only way to run on my hardware :X
osiris_: gimzo: nope. I the app is using FBOs it probably doesn't use blit
twnqx: and even then i need to make a local copy to put patches in...
gimzo: pl
gimzo: *ok
Ronis_BR: mattst88: how can I take the lastest kernel tree?
Ronis_BR: mattst88: I'll try to patch it with tuxonice and drm-next
spstarr: osiris_: you have secondlife?
osiris_: spstarr: I've just installed it
mattst88: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
gimzo: osiris_: so what's coming up next ?
spstarr: osiris_: it really stresses the GPU
mattst88: from there, pick which branch you want to track with:
mattst88: git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
spstarr: osiris_: so many options to tweak
spstarr: osiris_: which GPU do you have?
Ronis_BR: mattst88: I mean, the 'official' kernel tree
osiris_: gimzo: I'm not working on anything else now
mattst88: I bet you can find it yourself easily.
spstarr: osiris_: im gonna boot into AMD gpu ... if you can point me to debugging methods i can give you info
osiris_: spstarr: what options do you use? my gpu is rv530
Ronis_BR: I don't think so :D
osiris_: spstarr: the code is shared by 3d drivers for all radeon gpus so it gpu shouldn't matter
spstarr: osiris_: rebooting un moment
osiris_: spstarr: try running the app with RADEON_DEBUG=tex env var
agd5f: you can add remotes to a tree once you've checked it out
agd5f: so if you check out dave
agd5f: 's tree, you can
agd5f: add other trees and when you fetch, it only pulls the differences
spstarr: ok
spstarr: osiris_: im not using KMS, are you?
spstarr: w/ KMS its impossible to use secondlife
spstarr: way to sluggish, i cant even move the avatar around
osiris_: spstarr: yes, I am
spstarr: hmmm
spstarr: osiris_: it didnt seem to crash w/ KMS on, but i couldn't use the game at all
spstarr: osiris_: this is with ForceLowPowerMode on also
osiris_: spstarr: could you provide me with the log for app started with RADEON_DEBUG=tex env var?
spstarr: I am aware that KMS with 3D is quite slow right now
spstarr: yes let me do so now
agd5f: twnqx, Ronis_BR: just clone one kernel tree (doesn't matter whose) then add the other ones as remotes
spstarr: osiris_: so just run secondlife but export this variable first?
agd5f: you'll only have to download the entire thing once.
twnqx: i have one here...
twnqx: but it's built according to the topic
osiris_: spstarr: yeap
spstarr: ah nice it spits it tou console
twnqx: so, no clue how to get that sorted out
spstarr: i will capture this all for you
spstarr: lemme turn on VBOs also
Ronis_BR: agd5f: I did it, with linux.2.6.31.y, but drm-next gaves my tons of conflicts
spstarr: VBOs on... starting
spstarr: osiris_: with KMS on is your framerates fast?
spstarr: or sluggish
agd5f: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git; cd drm-2.6; git add remote tuxonice ; git fetch tuxonice; git add remote linus ; git fetch linus
spstarr: ie, mostly unusable
osiris_: spstarr: yeah, mostly unusable
spstarr: ok, good
spstarr: osiris_: lemme bump video graphics up some notches
agd5f: then you can checkout/merge/whatever from/to any branch on any tree
spstarr: crashed
spstarr: ok got the output
spstarr: osiris_: pastrbin.. coming
spstarr: osiris_: http://pastebin.ca/1678414
spstarr: i trimmed the rest as I dont think you need to see from very beginning(?) only just befoe it crashes
spstarr: before
spstarr: if you want full, lemme reload it
osiris_: spstarr: yeah, full log please
spstarr: reloading
spstarr: the path for KMS is different vs non-kMS?
spstarr: crashed
spstarr: ok got it
spstarr: lemme upload the file
spstarr: osiris_: http://www.sh0n.net/spstarr/r6xx.dump
spstarr: ive seen this
spstarr: IRQ's not enabled, falling back to busy waits: 2 0
spstarr: but its never been an issue
osiris_: soreau: I don't see the failing assertion here
osiris_: spstarr^^^
spstarr: osiris_: it just crashes like that, any other debug env variables?
osiris_: spstarr: how did you got the log?
spstarr: ./secondlife >& dump
spstarr: everything from screen
spstarr: export RADEON_DEBUG=tex
spstarr: i can try to do this :
spstarr: export MALLOC_CHECK_=0 <-- unset this
spstarr: as SL crashes if i do not turn off malloc checking
spstarr: sec
osiris_: spstarr: try not to redirect the output to file, and post me as much as the console (konsole or gnome one) can remember
spstarr: ok
spstarr: sec lemme see if it crashing w/o malloc checks shows
spstarr: crashed
spstarr: nice
spstarr: Checking image level 0, face 0, mt 0x6e529b0 ... MIGRATING
spstarr: do-not-directly-run-secondlife-bin: radeon_mipmap_tree.c:422: migrate_image_to_miptree: Assertion `dstlvl->width == image->base.Width' failed.
spstarr: now i see assert
spstarr: ok sending log
spstarr: reload http://www.sh0n.net/spstarr/r6xx.dump
spstarr: seems turning off GNU libc checking masks the assert
spstarr: osiris_: if thats still no good, i will run again w/o redirect
osiris_: spstarr: that one is good
spstarr: excellent :)
osiris_: spstarr: what graphical options do you enable to trigger the assertion?
spstarr: im ready to test patches etc
spstarr: lemme tell you now:
spstarr: VBOs on, it falls back to 128MB texture memory (even if i try to set it to 256)
spstarr: Low graphics mode, check off custom button
spstarr: enable: Bump mapping and Shiny
spstarr: enable: Avatar impostors
spstarr: Draw distance: 64m
spstarr: Particle Count: 1024
spstarr: Post Process Quality: Low
spstarr: Objects: HIGH
spstarr: Flexiprims: mid
spstarr: Trees: mid
spstarr: Avatars: HIGH
spstarr: Terrain: low
spstarr: check off Nearby local lights
spstarr: Terrain details: low
osiris_: spstarr: add this line fprintf(stderr, "base level %d, mt level %d\n", mt->baseLevel, mtLevel);
osiris_: spstarr: to radeon_mipmap_tree.c
osiris_: at line 420
osiris_: spstarr: and create the log again
osiris_: spstarr: the file is in src/mesa/drivers/dri/radeon/
spstarr: building mesa.....
spstarr: i think i can just rebuild the dri DSO only then
spstarr: to speed things up
spstarr: osiris_: I dont need to restart X to reload the DRI?
osiris_: spstarr: nope
spstarr: ok, thought that was the case
spstarr: just above the assert() ok building
spstarr: i have to build it all, its compiling mesa now.
spstarr: i wiped the obj dir yesterday
spstarr: wont take long
osiris_: ok
spstarr: quad core :)
spstarr: r600_dri.so
spstarr: ok got it
flyback: bids on a licenced copy of office 2003 pro for his mom, (don't even mention star office, it's not going to happen)
stikonas: r600_context.c contains some windows like ending...
spstarr: osiris_: testing now
spstarr: crash got
spstarr: osiris_: http://www.sh0n.net/spstarr/r6xx.dump
osiris_: spstarr: last 200 lines should be enough
spstarr: doesn't show anything different other than matching the mt level
kdekorte: airlied, I was hoping that a single primitive like line was done, and that I could copy that and do 'arc' or 'box' but since none of them have I don't have a template to work from.
airlied: kdekorte: really nothing majorly uses them, it might be woeth investigating making sw fallbacks go faster
airlied: I'm not sure if we render to a temp and composite properly for all of them
spstarr: osiris_: anything else you wish me to debug?
osiris_: spstarr: no, I'm analyzing the log
spstarr: ok
airlied: agd5f: ping
agd5f: airlied: pong
airlied: agd5f: you remember rendering limits for r100?
airlied: we have a scissor overflow in textured video
airlied: it looks like the RE scissors only work up 2047 w/h
airlied: I just can't remember what the max colorbuf sizes were
agd5f: yeah 2047 I think
agd5f: you'd think 2048, but it's actually 2047
airlied: agd5f: http://fpaste.org/aBCw/
airlied: seems sane?
airlied: it lets me play movies up to 2048 instead of just to some wierd place
agd5f: yeah, looks good
agd5f: exa may need similar clipping
airlied: good point
airlied: though I think we sw fallback for those cases
airlied: before we get that far
osiris_: spstarr: there's one more info I need
osiris_: spstarr: add this line fprintf(stderr, "mt baseLevel %d, texObj baseLevel %d\n", mt->baseLevel, texObj->BaseLevel);
agd5f: yeah, should be caught by check* functions
osiris_: at line 310
osiris_: same file
spstarr: osiris_: aright, building
airlied: looks like r200 xv might need it as well
airlied: I think from reading exa it has same limits
agd5f: yeah, probably. Although I think it might be 2048
agd5f: looks like it's 2047 too
spstarr: building
airlied: agd5f: I'll provbably have to add overlay support to kms then ;-)
agd5f: airlied: ugh. why?
airlied: ah mostly joking, but I'm sure some customer will complaing
MostAwesomeDude: "It's a hardware quirk that wasn't exposed before because of architectural problems further up the graphics stack."
agd5f: I'm not even sure the overlay supports 2048
spstarr: waits
spstarr: osiris_: going to sleep soon?
osiris_: spstarr: yes
spstarr: kicks the computer
spstarr: ok its building gallium stuff so its done the dri bits
spstarr: testing
spstarr: osiris_: http://www.sh0n.net/spstarr/r6xx.dump
Ronis_BR: airlied: can you tell me which kernel version I have to use the current drm-next?
Ronis_BR: airlied: I tried linux.2.6.31.y with no success today :( I was fine one or two weeks ago
yangman: Ronis_BR: first release of 2.6.31 works with drm-next
Ronis_BR: I = it
Ronis_BR: yangman: I tried today
Ronis_BR: there is some conflicts
airlied: Ronis_BR: try using drm-radeon-testing instead
airlied: drm-next is now going back to being for non-radeon
Ronis_BR: airlied: ok! but is it contains the lastest changes?
airlied: yes, pretty much
Ronis_BR: airlied: you mean kernel 2.6.31 and drm-radeon-testing right
airlied: yes should work in theory.
Ronis_BR: :D
Ronis_BR: airlied: thanks man!
Ronis_BR: git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.31.y.git
Ronis_BR: so... 3 hours of wait :D
airlied: if you've got a clone already you can use --reference to reuse it
Ronis_BR: airlied: I erase it :(
Ronis_BR: airlied: thanks fellow!
osiris_: spstarr: that's it for today. I'll continue tomorrow
spstarr: osiris_: if you wanna go to sleep go for it
spstarr: hehe
spstarr: :)
spstarr: we can resume tomorrow, i'll be home
osiris_: ok
osiris_: bye
sid_shady1: Hi all, I wonder if anyone can summarise the current state of power management offered by the radeon driver? I currently run Ubuntu Hardy with catalyst 9.3 (on a mobility X1600), switching to low powerstate (aticonfig --set-powerstate=1) reduces power consumption on my laptop by more than 25%. I've tried Karmic with the default radeon driver available from the repos and my power consumption is much higher - like 10mW. Tried rovclock,
agd5f: sid_shady1: see the radeon man page
sid_shady1: DynamicClocks?
[Enrico]: sid_shady1: 10mW? this is almost none, i think you mean 10W
[Enrico]: sid_shady1: yeah DynamicClocks it is disabled by default. if it doesn't work you can try ForceLowPowerMode
sid_shady1: I seem remember reading that this option requires kernel support though? I did try it in Karmic but the log and power consumption indicated it hadn't been enabled.
sid_shady1: [Enrico]: yes you're right, i am probably confusing magnitude of amps and watts
[Enrico]: sid_shady1: well afaik i have no idea what's the state of DynamicClocks i can't use it since i'm on a r600 and there is no powersave for this card with radeon yet, so i just use ForceLowPowerMode. but i know that advanced power management can be done only with kms, but that code has to be written atm
[Enrico]: and anyway DynamicClocks will never arrive for my card, powersave for r600 and above cards will be done with kms directly
airlied: most r600 already do dynamic clcoks by default
airlied: not sure why ppl like havijng xorg.conf options
MostAwesomeDude: It makes them feel leet.
yangman: ^
MostAwesomeDude: I've seen so many people setting AGPMode and AGPFastWrite erroneously...
MostAwesomeDude: ...because they copied out of somebody's leet-hax xorg.conf.
airlied: all new config options should have leet names
MostAwesomeDude: It's too bad that we're not dickish enough to make unknown settings in xorg.conf (EE) instead of (WW).
lolren: hei
lolren: i have a question
lolren: :D
MostAwesomeDude: No need to ask to ask. Just ask. :3
lolren: by the way ... MostAwesomeDude .. i have seen u on the phoronix forums... i watch them daily
lolren: :D
lolren: (offtopic)i have an nvidia video card... i hate the drivers..... closed.... cant wait for nouveu.....
lolren: today i just borrowed from someone an ati x1050
lolren: rv370
lolren: if i recall
lolren: i instaled mandriva ( till now.... i was , and probably will be a ubuntu user)
lolren: and the xorg.conf says i have the "ati" driver instaled
lolren: that`s xorg-xfree-ati
lolren: something like that no?
biotube: "ati" refers to a metadriver
biotube: picks between the r128, mach64 and radeon
lolren: sorry .. my english is bad.... i`m from romania
lolren: aaa
lolren: and
lolren: that why i have 3d
lolren: at least kwin works
lolren: and wine...... counter strike...
lolren: hm....
lolren: so...
lolren: i cound be using tha radeon driver..
lolren: not the xorg-xfree-ati or whats is name
lolren: intereting
[Enrico]: sorry i lost mi connection heard nothing after most r600 already do dynamic clcoks by default
airlied: I just gave out about xorg.conf then ;-)
airlied: logs are on radeonhd.org ;-)
[Enrico]: rofl
biotube: lolren: that package probably includes all three subdrivers
biotube: they're pacakged together upsteam as well
lolren: wait.. and dont swear me:))
lolren: aaa
lolren: toghether with the distro
lolren: or with xorg?
biotube: I mean that radeon, mach64 and r128 are all in one package together
[Enrico]: airlied: thanks, i'm intrested in this couse my card always stay in the powerconsumption state. but my driver is so old, 1 week git old :P
chithead: xf86-video-r128 and xf86-video-mach64 have been split from xf86-video-ati some time ago (6.8 release)
biotube: chithead: it never occured to me to check
lolren: ahaaa
biotube: figured it'd be xf86-video-radeon if they were split
lolren: i understand now...
chithead: xf86-video-ati still contains the "ati" wrapper, which will load mach64, r128 or radeon driver for your card
lolren: so ...... xorg load me xf86-video-ati and ..
lolren: i understand... i think
lolren: my english is so bad... that`s why... i understand not very well
lolren: so ... i asked this question because i see all the tine so much fuss on phoronix forums about hardware acceleration on r300-r700
lolren: on oss drivers
lolren: and i was thinking if my oss (mandriva now) are using them
lolren: :D
flyback: bbl
biotube: the information needed to get the r600 and r700 chips was only recently released
biotube: r300-r500 are under active development under mesa's new driver infrastructure
spstarr: gallium :)
lolren: gallium3d:)
spstarr: but the r3xx-r5xx work for non-gallium also
spstarr: you can use 3D on them
spstarr: lolren: not just '3D'
spstarr: Gallium is not just for 3D
lolren: they use 3d pipes for 2d accel?
biotube: modern graphics cards use them for 2d period
lolren: and gallium 2 as i recall
spstarr: the r6xx+ 2D is using the 3D engine to draw 2D
lolren: only the r6**
lolren: ?
spstarr: i thought r6xx+ and up
spstarr: there is no more 2D engine anymore
cire: I am using drm, xf86-video-ati from master and drm-next kernel. I am very happy with 3D acceleration on my R600, but watching videos becomes annoying. Every 1 or 2 seconds it hangs for a short time (in kaffeine & vlc). I tried several video output drivers, but OpenGL for example doesn't work (looks like interlaced with green lines). Is this a known issue?
airlied: cire: we normally bame the sound drivers first ;-0
cire: airlied: this is not possible. When switching to another kernel without modesetting support, and thus disabling 3D, it is fluently.
cire: Perhaps it is kwin4's desktop effects making it slow...
spstarr: cire: KMS is slow with 3D right now
airlied: well we blame kwin second
cire: but when watching video, I don't use them.
airlied: okay so not that
cire: What is the recommended video driver for vlc for example?
cire: I mean
spstarr: i turn off KMS until its ready, airlied, the slowness for 3D with KMS is due to the paths not optimized yet?
cire: in vlc I can chose several output modules
spstarr: or something missing?
Ghworg: is watching video right now with r600 kms drm-next and it is working fine
biotube: vlc is unusable for me for other reason, but xine works fine both with xv and OGL
cire: XVideo Extension, X11 Video, Video memory Output and OpenGl
cire: are my options
Ghworg: mplayer with xv output works best, but gl output works too
[Enrico]: cire: i use kwin and radeon driver from git, videos are just perfect with Xvideo i watched a 720p mastroska film just yesterday
cire: I will test that
[Enrico]: using XVideo
[Enrico]: cire: and i use kwin :D
[Enrico]: with desktop effects enabled
cire: hmm
cire: then I don't know
biotube: cire: what version of mesa?
[Enrico]: cire: but i used mplayer based player
[Enrico]: cire: smplayer to be precise
cire: damn. This is weird... desktop effects are running, but "glxgears" gives me Speicherzugriffsfehler, which is segfault I think
cire: didn't recognize that earlier
[Enrico]: cire: glxinfo segfault too ?
eosie: MostAwesomeDude: is it possible to test r300g-swtcl with an on-board hwtcl?
biotube: cire: sound like you're using xrender for effects
cire: biotube: sorry, I meant glxinfo
cire: glxgears is just the same
cire: xrender?
[Enrico]: cire: there is something b0rked there
spstarr: boots ito intel gpu
cire: I also cannot open the kde effects configuration.
biotube: cire: kwin's other backend. don't know no omr about it
biotube: s/omr/more/
[Enrico]: cire: you said "I am using drm, xf86-video-ati from master and drm-next kernel" did you updated mesa too ?
cire: hmm
cire: something is relly messed up here
cire: s/relly/really
cire: yes
cire: right now I am compiling newest drm-next
cire: a lot of stuff changed, I think
[Enrico]: so mesa libdrm and video-ati from git and drm-next
[Enrico]: same as me
cire: yes
[Enrico]: cire: what OS ?
cire: sidux, which is debian sid with patches
[Enrico]: ok i know it. i'm on gentoo
cire: so you know these kinds of problems ;)
cire: I will re compile everything, and try it again afterwards.
[Enrico]: cire: never had problems with radeon driver (well i just switched to radeon one week ago, from a 1 year+ of fglrx eheheh)
cire: fglrx is crap... I rather missed 3D than using it
[Enrico]: i just can't wait for the final radeon release :D
cire: ;)
[Enrico]: cire: yeah radeon makes me a lot more happy, and i still have some 3d!!
cire: that's it
biotube: and it seems like OGL 2.0 is just around the corner
cire: cool
[Enrico]: cire: but well normally i prefer "released" stuff for this machine since i use it to work too, but well git radeon is just awesome :D
[Enrico]: biotube: very nice news :D
cire: I also didn't think it would run that good
Ghworg: Strange how unreleased development code is more stable than fglrx
[Enrico]: cire: i was knowing it does, but you know.... work machine.... git stuff, normally are not friends
cire: yeah, but I installed everything to /opt/xorg, so removing one entry in xorg.conf and I am backed up
[Enrico]: Ghworg: well fglrx was somewhat stable if i don't try to start a second X session, but it has a lot of non critical bug
[Enrico]: too much bugs
Ghworg: [Enrico]: fglrx can be stable if you avoid using it in certain ways, but that is not very stable in my book
[Enrico]: for example the freeze with some composite actions. radeon is just perfect with composite
biotube: not to mention crappy 2d
[Enrico]: oh yeah 2d is just crap on fglrx
Tenkawa: Anyone know which driver I should be researching for full X1200 support?
biotube: radeon
[Enrico]: even video has some (really small) artifacts, that's annoying
biotube: I don't think fglrx supports r500 anymore
[Enrico]: Tenkawa: there is only one: radeon you have no choice
[Enrico]: biotube: correct
Tenkawa: anything special on that one to get the 3d functionality working properly?
[Enrico]: Tenkawa: afaik it should just work out of the box
Tenkawa: hmmm
Tenkawa: guess I'll need to do some tweaking to get some things working in wine
Tenkawa: everything else seems ok
[Enrico]: Tenkawa: wine is not your friend
Tenkawa: I know
Tenkawa: but one app I want to use I dont have the option
[Enrico]: Tenkawa: which one just for curiosity ?
Tenkawa: it works 95% .. the only part I need is a 3d renderer in nwn toolset to work
Tenkawa: everything else in the app works great
[Enrico]: Tenkawa: do you mean the bioware game?
Tenkawa: yep
[Enrico]: Tenkawa: listen to me this is a suggestion: run windows games in windows :D
Tenkawa: haahaa
[Enrico]: wait it seems to be a linux native client for that!
Ghworg: wine is the lesser of evils
Tenkawa: well I use the Linux version of it to play... but to edit got only one option
[Enrico]: Tenkawa: so there is only half support for it in linux
Tenkawa: about 90% support
[Enrico]: better then 0 anyway :D
[Enrico]: Tenkawa: well does wine output gives you some clue about that ?
cire: KMS is slow with 3D atm? Should I disable it?
Tenkawa: [Enrico]: nah... 3d window part is just solid blackk
biotube: cire: if you want
Tenkawa: afk.. bbl
cire: what does slow mean? Does this affect kwin4 effects?
cire: I just like that "show all windows" thingy
biotube: cire: it means slower than nonKMS
Ghworg: cire: If it is too slow for what you want, yes. It's good enough for me to run kwin effects
cire: hmm, I used to have ~2300 fps in glxgears (I know it is not a bench)
cire: but atm I cannot run it ;)
[Enrico]: i didn't even noticed tha change from kms and non kms
biotube: I never bothered with UMS 3d
cire: okay, since nothing works but my desktop effects, I'll leave it on
Ghworg: KMS is about 20% slower for me in those things I've tested, hardly noticable
cire: okay, thatis not a problem
cire: I thought about 60% or sth
cire: just to be curious: why is that?
cire: (slow kms)
biotube: lack of optimization
[Enrico]: cire: it is highly experimental eheheh
cire: yes, I know that.
cire: But I thought it used to be faster
[Enrico]: cire: ti will be fast
cire: did they change a lot of stuff (refactoring or something like that) and have to fix a lot of stuff?
[Enrico]: cire: 1) make it working 2) make it working fast
cire: yeah
biotube: there's also the issue that the KMS code runs in the kernel
cire: That's the thing I am wondering about. I thought it was running, and instead of making it fast it got slower? ;)
[Enrico]: 3) rewrite the driver from scratch to follow the new xorg driver arch :P (just kidding :D )
cire: hrhr
cire: okay, no problem. drm-next is compiling, then I'll try again. right now I am afk for some minutes
cire: thanks for the information
[Enrico]: cire: well don't let yourself drop the hope. we will see what gallium3d can really do. the time will say but i think it will be at least a bit faster then without
[Enrico]: hopes a lot faster :D
cire: yeah... gallium was mentioned a lot in phoronix news, but I still don't know exactly ehat it is doing...
cire: s/ehat/what
[Enrico]: cire: new 3d driver architeture, and it uses kms and memory manager
cire: but, to be honest, graphics in linux makes me crazy. glx, xgl, mesa, drm, kms, gallium... I gave up to understand everything
biotube: well strike xgl from your mind
[Enrico]: rofl
[Enrico]: yeah xgl is no more :D
cire: that was 3D through X, right?
[Enrico]: cire: well xorg is just evolving quickly
[Enrico]: cire: no it was not
biotube: cire: other way around
cire: err... damn. I told you I gave up ;)
[Enrico]: eheheh
biotube: the current stack is this: http://yangman.ca/blog/2009/10/15/linux-graphics-driver-stack-explained/
cire: but good to know that some people still know what to do and with what libarry and so on. Especially the people here, wher some are developing drivers I need ;)
Ghworg: Most of us are just hangers-on, slavering over the latest code
cire: cool. I'll read the document you referred to. perhaps then there's more light in my mind.
Ghworg: slathering, hmm, spelling fail
[Enrico]: cire: kms replasces the DDX
cire: strange translation... you know what I eman
cire: okay
cire: kms was memory manager in kernel space. As far as I understood...
Ghworg: KMS is kernel mode setting, it requires a memory manager in the kernel but is seperate from it
biotube: the upcoming stack will be much simpler
biotube: X will translate 2d command into OGL commands
[Enrico]: cire: for example i'm not using kms atm, but i'm using the ttm (the memory manager)
biotube: gallium will render that along with any directly requested 3d commands
Ghworg: Things are always complicated when you are transitioning from one thing to another. Especially such major things as the graphics stack
biotube: and KMS will make the card do it all
cire: okay... I think I got it.
MightyMu: Ghworg: slavering was right
cire: so in the End, even 2D will be opengl?
biotube: yep
MightyMu: maybe not necessarily the right word, but spelled right. :)
MightyMu: actually, seems like the right word. You nailed it!
[Enrico]: hi MightyMu, are you enjoying radeon ? :D
Ghworg: MightyMu: Yay me :-)
biotube: cire: another benefit is that X will no longer even have to know about the underlying card
MightyMu: [Enrico]: I'm learning a lot. :)
MightyMu: I figure if I lurk long enough, I'll start to be able to wrap my head around all this black magic
[Enrico]: btw i don't know why but without kms on my r200 nexuiz is terribly slow, and i mean less then 1 FPS
[Enrico]: a lot lower
yangman: biotube: whoa now, lets not say things that aren't necessarily true :\
biotube: i did say 'have to know'
biotube: or is there more to the xorg st that I don't know about?
airlied: biotube: X doesn't know now
biotube: isn't DDX part of X?
airlied: about as much as mesa is part of X
airlied: X provides a driver interface, it never cared what filled it in
airlied: whether its -ati or the xorg st on a radeon gallium driver
biotube: ah
biotube: but the no-setUID thing is true?
airlied: biotube: thats true for any kms driver
airlied: its not output thats blocking non-suid, its input
biotube: okay
Ghworg: Theoretically could there be a xorg-video-gallium DDX that works on both radeon and intel, or anything else that has gallium?
airlied: Ghworg: not
airlied: well theoretically anything could happen
[Enrico]: rofl
airlied: but not really likely
Ghworg: Pity, that would be really cool
airlied: but there might be some hope as ppl have discussed some sort of library separation
airlied: but I think you still need something to know what hw to probe
dmb: airlied, is wayland getting ready to work on radeon hardware soon?
dmb: or still only intel?
airlied: dmb: no idea, its an intel run project now
airlied: so I doubt they'll be fixing it to run on anything else
dmb: airlied, oh, that sucks :(
dmb: airlied, why the change of heart?
airlied: not a change really, just the main developers moved to work for Intel
airlied: but wayland isn't really defined
airlied: its nothing more than a research project at the moment
Ghworg: Wayland is a dead end anyway. To make it useful enough for the masses you'd have to add in most of what X does anyway
airlied: it'll be 2 years before it'll be deployable
airlied: well it can run X inside it, but its a bit of a hack
[Enrico]: well i go to sleep
[Enrico]: gn people
dmb: (for wayland)
dmb: airlied, why is intel stealing all the x developers :(?
airlied: dmb: because they want to make Linux graphics on intel workl
EruditeHermit: airlied, hey
airlied: EruditeHermit: hey
EruditeHermit: still busy with RHEL stuff?
airlied: EruditeHermit: not really, I just need to page back in where we got to,.
airlied: EruditeHermit: bug num again, I lost my tabs ;-)
EruditeHermit: https://bugs.freedesktop.org/show_bug.cgi?id=23103
EruditeHermit: last thing I tried was a fix that you thought about after fixing a T60 thinkpad
EruditeHermit: but it didn't work
EruditeHermit: btw I wanted to ask you
EruditeHermit: drm-next seems to be 2.6.31-rc9 kernel
EruditeHermit: is that correct?
airlied: EruditeHermit: yes if you are running the tree direct
EruditeHermit: yeah I was
airlied: so let me get this straight, running LVDS, resume no backlight, can't see anything, resume with VGA plugged in, get wierd colors on VGA, still no LVDS?
EruditeHermit: airlied, yep
EruditeHermit: sorry got distracted
EruditeHermit: real live people arrived
cxo: crazy
cxo: what are they like?
airlied: EruditeHermit: hehe. I'm about to get distraced by lunch ;-)
cxo: Do they run the latest git as well?
EruditeHermit: airlied, to answer your question, you summarized the situation perfectly
airlied: is fixing r100 bugs for some reason
airlied: at least compiz runs on my crappy laptop again
dmb: airlied, what kind of laptop?
dmb: wait, r100?
airlied: T42
dmb: ah, good old thinkpads
dmb: airlied, you think its still worth buying thinkpads (from lenovo)?
dmb: looking for a very cheap laptop :)
dmb: thats not a netbook
airlied: I don't generally get to select my vendors ;-)
dmb: oh, not your personal...
airlied: even my personal hw is generally donated
dmb: oh
dmb: lucky :)
airlied: last thing I bought myself was a monitor about 4 years ago
biotube: a lot of my personal hardware is salvaged
airlied: and a Dell laptop about 6 years ago
dmb: oh
dmb: i feel like they used to make better quality stuff 6 years ago :)
airlied: that laptop is in a bad state now, I can sort of get it to switch on for an hour or two if I'm lucky
dmb: airlied, is it a 9400/e15/1705?
dmb: because i have the same kind of issue
dmb: with mine
airlied: dmb: nope some sort I6000
dmb: oh
dmb: i have a inspiron, likes to randomly power off
airlied: I think the PSU has some issues, and it has no battery
dmb: its not the power adapter
dmb: at least in my case
airlied: it also has a broke backlight so I have to stick my finger into the case to light the LVDS
dmb: going to open it up later and see if i can find any loose connectors i can solder back on
dmb: hahhahhah
dmb: some dells you can replace the backlight (if you are willing to)
airlied: the backlight is fine
airlied: its just the power cable to it is cracked I think
dmb: oh
dmb: well, duck tape then :)
EruditeHermit: airlied, my laptop is probably worse =p
EruditeHermit: I had to rebuild it from a friends laptop
flyback: I almost did a backlight
flyback: it was messy\
flyback: turned out the one I pulled from another screen on a dead laptop was not 100% compatible
flyback: why I couldn't get it to fit all back together
flyback: you need to buy gloves
flyback: latex or something thing
flyback: NON-POWERED
flyback: NO POWDER
flyback: NO POWDER
flyback: NO POWDER
flyback: because you wil be handling the raw lcd glass and backplate
flyback: fingerprints etc will leave you annoying for life
cxo: How many gits can a Git git
dmb: -1
EruditeHermit: O(N)
flyback: cxo you must be a stupid canuck
cxo: flyback, git off my lawn!
flyback: BITE MY "CANUCK"..............CANUCK!
hagabaka: :O
edt: mesa git seems broken here tonight with: Mesa DRI R600 (RS780 9614) 20090101 TCL DRI2 (info from glxinfo mesa 7.6). With 7.7 git I now get software rendering which is not working correctly leaving artifacts all over my screen. (DRI2 should be working and was with mesa 7.7 git built last weekend)
Ghworg: edt: Update libdrm and rebuild mesa against it
edt: that makes sense - I tend to forget libdrm; it normally does not change often...
biotube: where's the code that determines what goes in "OpenGL renderer string"?
biotube: I'm sick and tired of Wine saying AMD is an unknown vendor
biotube: specifically, I'm looking for what fills in the chipset
cxo: I think you could just easily LD_PRELOAD a small library to change that
cxo: I dont like AMD being the rendering string either
biotube: actually, I was looking to hack in support for it in Wine
biotube: thus I need to know which chipsets to look for where
cxo: I vote to call it MostAwesomeDevice
cxo: " Advanced Micro Devices, Inc." is so lame and so anti-open source
edt: rebuilding libdrm from git and then mesa from git still breaks X
edt: it works, with some taskbars crud, if I revert to mesa 7.6
edt: something added to mesa since saturday breaks mesa git here
cxo: i have a build from yesterday, and all works
edt: not here
cxo: hd4870, 64bit ubuntu
edt: rs780 (HD3300) gentoo 64bit
cxo: which version of X you got there?
edt: 1..7.1
edt: not from git
edt: the ddx is from git though (dri2/kms too)
cxo: i have a much older version (1.6.4)
cxo: i'm using 2.6.31rc7 with airlied's drm-radeon-testing branch
edt: the xserver has not changed though. mesa seems to be the one difference
cxo: you've obviously tried rebooting?
hnsr: using 1.7.1 without troubles here, gentoo as well
edt: you mean 32-rc7? I use 31.6 with drm-next from airlie
cxo: sorry 32rc7
edt: this is after a reboot tonight
edt: so yet reboot tried
cxo: you built drm, then mesa, and then rebooted?
edt: rebuilt libdrm and mesa restarted X (it failed), rebuild built mesa 7.6 started X (it worked)
cxo: interesting
cxo: i'm using 7.8-dev
edt: looks like lots of changes to r600 from Richard Li came in tonight. I am going to drop back to yesterday's git (827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8) and see what happens
cxo: why dont you just go with the latest?
edt: ok 7.7 git works if I go back to 827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8 - looks like todays changes break mesa here.
hnsr: haven't tried todays changes yet, going to now though
edt: git is master branch from git://anongit.freedesktop.org/mesa/mesa
EruditeHermit: airlied, back yet?
cxo: master is 7.8-dev i thinkk
airlied: EruditeHermit: yup mostly.
EruditeHermit: airlied, so any new ideas?
EruditeHermit: I wonder if we can sneak a fix if we find it into kernel 2.6.32 before it releases
airlied: EruditeHermit: uinliekly
EruditeHermit: =(
airlied: Linus didn't pull my other fixes.
EruditeHermit: ah
EruditeHermit: well lets hope Ubuntu uses 2.6.33 for 10.04
EruditeHermit: =p
airlied: fixes can go in stable anyways
cxo: wonders when Linux-3.0 will come out
EruditeHermit: probably not for a while
cxo: We've had 2.x forever
EruditeHermit: yeah but to go from 2.4 to 2.6 was a major major change
cxo: I guess replacing the entire graphics stack is worthy of 3.0
airlied: nothing is worth of 3.0
EruditeHermit: probably not
airlied: we didn't replace it either
EruditeHermit: from 2.4 to 2.6 they changed the module structure
EruditeHermit: I think
cxo: 2.4 to 2.6 was basically just dynamic dev nodes amongst nicer usb et friends
airlied: we've changed much more in 2.6.0->2.6.33 than 2.4.0->2.6.0
cxo: yeah
EruditeHermit: cxo, when they rerach 2.6.99 they'll do 2.8 =p
cxo: so replacing the entire gfx stack seems at least worthy of +0.2
edt: cxo and a new vm between 2.4 and 2.6 with lots of nice changtes
EruditeHermit: 2.6.100 would be cool though
EruditeHermit: numbers don't matter
EruditeHermit: its the features anyway
cxo: we'll be dead by then
EruditeHermit: probably not
EruditeHermit: each kernel takes max 3 months
EruditeHermit: 4-5 kernels a year
EruditeHermit: about 17 years or so
cxo: hmm you're right
airlied: EruditeHermit: so resume works in UMS for you?
EruditeHermit: airlied, yes
cxo: Just call it Linux 8.0 when we max out at 2.6.99999
airlied: ah we already got vbetool regs, /me reads them
biotube: cxo: keeping ahead of windows would be fun
biotube: although an obscure versioning system would be much more so
edt: airlied fyi mesa at 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks. Here going back to yesterday's 827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8 works again. glxinfo then reports: "OpenGL renderer string: Mesa DRI R600 (RS780 9614) 20090101 TCL DRI2" with head it uses a non working software renderer (lots of artifacts left on the background).
EruditeHermit: airlied, engadget changed their site and it no longer crashes me!
EruditeHermit: though what causes the bug still probably exists, I can't reproduce it regularly anymore
edt: we should tell Linus to up the version to 3.0 as a 40th Birthday present (dec 28 is his luckly day)
edt: s/tell/suggest to/
EruditeHermit: back in 15mins
airlied: edt: updated libdrm?
flyback: anything in radeon 7000 or 8000 that is seriously *CANUCKED* enough in 2d space not to use
airlied: edt: file a bug, I'm not in mesa land too much for r600
flyback: they are going to be driving a 800x480 screen via s-video or composite video at best
cxo: Like Sun's marketing, worked for them :)
cxo: But isn't Linus coming along in age as well
cxo: What will we do without RMS and Linus. I hope a new zealot will step into the position and continue to protect our kernel from corporate interests
airlied: weirdly this year we didn't talk about version number change at all
airlied: we have for the past 3 years, we must have decided its not worth it
flyback: personally I think we should just get it on with ww3
flyback: mankind is full of shit anyways
MightyMu: Swine flu will take care of that
MightyMu: have patience
flyback: good
edt: airlied tried the libdrm path - no affect. Flipping the reverting the to the earlier commit fixes things.
flyback: I was so pissed when the tornado missed me last year
flyback: I was furious
flyback: missed me by like 10 mins
MightyMu: A tornado in PA? Where?
flyback: beaver country
flyback: about hr from pittsburgh
MightyMu: Ahh
MightyMu: from Philly
flyback: we had a big one in 84-86
flyback: somewhere around there
flyback: my mom and little sister (almost 30 now) left a shopping center before it became a parking lot
MightyMu: yikes
flyback: wiped out one of the last drive ins
flyback: someone put up "now showing: gone with the wind"
flyback: you can still see the downtrees patch
MightyMu: lol
flyback: and a tornado about 10 yrs ago or less
flyback: tore out the oldest surviving iron trussle bridge thing
flyback: that was a big tourism thing
flyback: they finally had to close shop when they couldn't cross the bridge anymore
flyback: I wonder with all the open specs published on radeon
flyback: I can make a portable dvd player screen look really really good :)
flyback: I got like hmm 7 I bought broken on ebay
flyback: I think 4 working have video input
cxo: biotube, SUN did the same thing when they were fighting the ever increasing Visual Studio revisions, 6,7,8 etc.. Heaven forbid something versioned 1.3 could ever compete with something like 8.0. Hence Java jumped from 1.x to X. How silly it may sound, it actually put Java back on the map
airlied: Sun always did that
airlied: Solaris dropped the SunOS major number
cxo: Well it started some 10 yrs back. Not always
flyback: MightyMu, lemme find the pics
flyback: no chance of the rage cards getting tv out?
flyback: support
cxo: Didn't they stop making those?
flyback: yeah
flyback: I mean support in linux etc
flyback: has an idea of a simple pci card and portable dvd player as a cheap display for server posting checks etc
cxo: doesnt a dvd-player already have a tv out?
cxo: You could just splice the VGA connector into RGB
flyback: you mean tv in
flyback: yes they do
flyback: that's why I bought them broken cheap on ebay
flyback: I made sure the breakage wasn't related to the screen :)
flyback: but the default res and fonts pc's default to is almost unreadable
flyback: I dunno if it's just the players I got got really shitty scaler chips
flyback: they have a s-video/comp to analog rgb scaler chip
flyback: or the video card with tv outs I have are crap along with the one from work
flyback: or what
airlied: EruditeHermit: can you grab the latset radeontool from my repo?
MostAwesomeDude: eosie: R300_NO_TCL=1 will force r300g to a SW TCL pipeline.
airlied: and redo the dumps from pre-s/r and post-s/r
Magnade: what kind of 3d support is there for r600 cards atm?
Magnade: aka should i not be surprised if x crashes?
biotube: i've never had problems with it
Magnade: is kms required?
biotube: not from what I can tell
eosie: MostAwesomeDude: I guess you haven't unbroken it yet, because it doesn't work here
Magnade: http://www.reddit.com/r/linux_gaming/comments/a2kux/quantz_ported_to_linux_please_help_us_test_the/
Magnade: tried that which is 32bit only atm (on 64bit) and it crashed while trying to start a game
Magnade: menu seemed to work ok
Ghworg: Woot. Everything is working, kms, 3d and now suspend works too! Nobody touch the code, you'll just break it again ;-)
MostAwesomeDude: eosie: I haven't, no.
MostAwesomeDude: In a bit, I'm going to try rebooting and hopefully I'll magically be in F12.
MostAwesomeDude: And if so, then I can do a bit more work on it.
eosie: btw, you got an email ;)
MostAwesomeDude: Ooh, email. :3
cxo: Magnade, i have an r700, crashed a few times, but generally 3d supports for opengl < 1.5 is pretty ok now
Lutz_Ifer: quantz crashes for me too. full system lockup
DanaG: I've got the powaaaaaaaaaaaaaaaaaaaaaah....
DanaG: and radeon eats it. fglrx is less hungry. =þ
Magnade: Lutz_Ifer: guess i got lucky it just killed x and i had to log back in
Magnade: cxo: k