Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-12-22

Search This Log:


dileX: agd5f pm patches:
Nightwulf|work: hi all
dileX: hi Nightwulf|work
Nightwulf|work: hi dileX
Nightwulf|work: hmm...is it possible, that the actual git driver doesn't work with 2.6.31.y from radeonBuildHowTo? gives me just a black screen and nothing more!?
soreau: Nightwulf|work: What chip do you have?
Nightwulf|work: RV635
Nightwulf|work: but the same behaviour I get with my RV790 @home
soreau: If you already have latest libdrm, mesa and ddx maybe you should try drm-radeon-testing
soreau: The wiki needs to be updated really
Nightwulf|work: reverting to a approx. 2 weeks old version of radon gives me a working X again
soreau: So bisect it and file a bug
Nightwulf|work: since there was no WW or EE in the log, is there a possibility to raise debug message level?
soreau: Yea, file a bug
Nightwulf|work: o.O
Nightwulf|work: perhaps you should read my last question again? ;-)
Nightwulf|work: problem is, there is no information in dmesg and Xorg.0.log so I asked wether I can raise the level of information to get something I could attach to the bug ;-)
dileX_: dmesg_agd5f-radeon-pm.txt: http://pastebin.ca/1723487
gsedej: hi! what means output of glxinfo "GLX version: 1.2"? so no 2.0 is supported? What happens if app needs opengl 2.0 extentions? (software emulation?)
airlied: gsedej: thats GLX version not GL
airlied: depending on GPU and mesa, radeon will give GL 1.5 (r300->r500) or GL 2.0 (r600->)
airlied: with latest mesa git
gsedej: will GL 2.0 be supporded on r300?
MrCooper: gsedej: probably only with the Gallium driver, if at all
MrCooper: also, with current xserver and KMS/DRI2 the GLX version is 1.4
gsedej: MrCooper, OpenGL version string: 1.5 Mesa 7.6, OpenGL extensions: ...
dileX_: airlied: with libdrm_radeon changes in mesa GIT now, isnt building libdrm-2.4.17 with --enable-experimental-api obsolete, now?
gsedej: MrCooper, I do not use KMS.
gsedej: is there way to fore openGL 2 extentions (object buffer) to render software?
soreau: gsedej: As MrCooper said, gl 2.x will likely be implemented for r3xx in the r300g gallium driver. It already reports OpenGL renderer string: Gallium 0.3 on RV350\nOpenGL version string: 2.1 Mesa 7.8-devel though the actual functionality is still a WIP
gsedej: ok, thx
soreau: Also, gallium only works with kms
CyberArch: What is the best driver to use for an ATI RADEON 9200SE (RV280 based) graphics card? According to http://xorg.freedesktop.org/wiki/radeon the "radeon" driver provides 2D acceleration, and also 3D acceleration, but as far as I can tell I'm unable get Compiz working properly, even though the module is loaded in the kernel (not sure if correctly)
adamk_: The radeon driver is the correct one.
soreau: CyberArch: What does glxinfo|grep renderer show?
adamk_: What distribution are you using?
CyberArch: The graphics card is used with Xubuntu now, but I used it with LinuxMint and Ubuntu also
CyberArch: soreau: the command outputs -> OpenGL renderer string: Software rasterization
soreau: CyberArch: That is the problem. Pastebin /var/log/Xorg.0.log
CyberArch: soreau: http://pastebin.com/d29cf8e11
amarsh04: with hardare acceleration it should look something like: OpenGL renderer string: Mesa DRI R200 (RV280 5964) 20090101 AGP 2x x86/MMX TCL
CyberArch: Ok, thanks for letting me know! I must debug this problem now.
soreau: CyberArch: Is this an upgrade from an earlier version of ubuntu or a clean install?
CyberArch: Clean install
soreau: Have you ever had fglrx installed on the system?
amarsh04: on Debian unstable with the radeon 9200se, my /etc/X11/xorg.conf is:
amarsh04: Section "Device"
amarsh04: Identifier "Radeon 9200SE"
amarsh04: Driver "radeon"
amarsh04: BusID "PCI:1:0:0"
amarsh04: Option "AccelMethod" "exa"
CyberArch: fgrlx support for RV280 series has been dropped in 2006
CyberArch: *fglrx
amarsh04: this is with an agp card
CyberArch: soreau: I won't be able to use the ATI proprietary driver with never kernels and newer X.org server verions
adamk_: He wasn't suggesting you use the proprietary driver.
soreau: CyberArch: I know, I am just trying to figure out how you managed to break it
adamk_: He was asking if you ever had it installed.
soreau: Right
soreau: CyberArch: With xubuntu, the driver should work ootb
adamk_: From the log file, it looks like the AGP driver for the chipset just isn't getting loaded.
adamk_: CyberArch, Please pastebin the output of 'lsmod'
CyberArch: When I do a sudo lspci -v it tells me that there are 2 kernel modules : radeon and radeonfb, is there a conflict between these?
CyberArch: adamk: http://pastebin.com/d5678f805
CyberArch: 0
adamk_: Well amd64_agp is loaded and it's shown to be in use. I'm not sure what's going on here.
soreau: adamk_: Can radeonfb cause trouble?
adamk_: I have my doubts, but that's probably the first thing I'd check.
soreau: Hmm lsmod doesnt show its loaded
amarsh04: on my PII with radeon 9200se, the Xorg.0.log looks like: http://paste.debian.net/54662/
amarsh04: CyberArch, what is the output of lspci|grep -i radeon
CyberArch: 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
soreau: CyberArch: Is this in fact an amd64 setup?
CyberArch: 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)
CyberArch: My processor is an amd64 but the operating system is 32 bits
adamk_: What's the output of 'cat /proc/fb' ?
soreau: CyberArch: Does lspci|grep -i agp show anything?
CyberArch: adamk: nothing outputs
amarsh04: weird, CyberArch, I get: 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 02)
CyberArch: soreau: 00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge (rev a2)
soreau: Ah
adamk_: So it doesn't look like you're using radeonfb after all.
soreau: So nvidia agp probably needs to be loaded instead of amd_64 agp
soreau: Which would seem backward :P
dileX: airlied: tried libdrm-2.4.17 with mesa and ddx from GIT. looks fine with latest libdrm API changes.
soreau: hm
CyberArch: hmm, I just noticed there is not xorg.conf file in /etc/X11
CyberArch: *no
soreau: That is no problem
soreau: CyberArch: Try this: Log out of X, get to a tty, then run sudo /etc/init.d/gdm stop, then sudo rmmod amd64_agp and then sudo modprobe nvidia_agp then sudo /etc/init.d/gdm start
soreau: Oh meh, its xubuntu
soreau: CyberArch: So it would be xdm instead of gdm
soreau: Hopefully this will load the right agp kernel module for your boards agp chipset
CyberArch: no that's not the problem I need to stop it other way
CyberArch: the Upstart has changed
soreau: Ah, I thought they changed it back
CyberArch: this is weird can't stop it? can I use runlevels?
soreau: What are you trying?
CyberArch: your method /etc/init.d/gdm stop , their method : service gdm stop , or gdm stop
soreau: sudo service gdm stop ?
CyberArch: I'm root
soreau: Well unfortunately that is a bit beyond the scope of this channel
soreau: Ah, its xdm btw
soreau: not gdm
soreau: since you are using xubuntu
CyberArch: after finally I killed gdm it tells me the amd64_agp is used? huh? It's safe to use rmmod -f amd64_agp ?
soreau: I would blacklist the amd64 agp module, tell it to load the nvidia agp one and reboot
dileX: if someone is willing to test and debianize latest libdrm (amongst others libdrm_radeon API changes), I prepared a patchset against libdrm-2.4.17: . Note: requires mesa and ddx from GIT master.
CyberArch: amarsh04: still around? can you pastebin your /etc/X11/xorg.conf file ? I managed to blacklist the amd64_agp but is still loaded (weird) and now when I do a glxinfo | grep renderer I get "Mesa DRI R200 (RV280 5964) 20090101 AGP 8X x84/MMX+/3dNow!+/SSE2 TCL, and lsmod output tells that "radeon" is used by "2"
soreau: Are you still not able to start compiz?
CyberArch: I tried to enable some effects but nothing happens
soreau: Did you actually start compiz?
amarsh04: CyberArch, will do in a minute
AstralStorm: hmm, is that testing GLSL any complete?
amarsh04: This is all I have:
amarsh04: Section "Device"
amarsh04: Identifier "Radeon 9200SE"
amarsh04: Driver "radeon"
CyberArch: I did now with compiz --replace, I get a black desktop with nothing on it
amarsh04: BusID "PCI:1:0:0"
amarsh04: Option "AccelMethod" "exa"
BioTube: AstralStorm: complete 1.2, AFAIK
CyberArch: Why is this happening ?
BioTube: it's enabled by default, at any rate
soreau: amarks: 1) Use a pastebin service 2) He asked for X log, not conf
AstralStorm: BioTube: hmmh no, no no
AstralStorm: I'm talking about that testing OpenGL 2 define
CyberArch: soreau: I asked for xorg.conf
soreau: Oh yea
adamk_: rnoland, Thanks for that fix last night. Works great.
soreau: CyberArch: You shouldnt need an xorg.conf
soreau: CyberArch: Can you pastebin the output of compiz?
soreau: adamk_: Curious, what was wrong with it?
soreau: CyberArch: Hmm.. by black desktop, do you mean you cant see your panel either?
adamk_: Looks like the glsl code was getting compiled but not linked in, if I'm reading the patch correctly.
CyberArch: soreau: in which log file can I find it? I can see the panels from top and bottom, but the desktop background is black with no icons on it
adamk_: But now I get opengl 2.0 reported on FreeBSD with an HD3450. :-)
soreau: CyberArch: Well that is probably a good sign. Can you try enabling effects in ccsm?
adamk_: I have no idea if all the extensions work.
soreau: adamk_: Test it! ;)
adamk_: Well glslnoise pops up a window but it reports "noise4: not yet supported shader instruction"
soreau: CyberArch: but the output of compiz is not stored in a log file, it is output to the terminal when you run it
adamk_: Gonna try in Slackware.
CyberArch: soreau: I have effects working. After I ran Compiz from terminal I get some errors. I need to restart can't use the keyboard anymore. I'll paste bin the output in a moment.
soreau: CyberArch: Well if its working, dont sweat it ;)
soreau: That was the original issue, iirc :)
CyberArch: soreau: effects are working but with the problem of black screen! and the windows are moving a bit harder! heres the output of compiz --replace from the terminal : http://pastebin.com/d7c9f47e0
soreau: CyberArch: You dont have a black screen
soreau: You have merely neglected to set an image in the Wallpaper plugin ;)
CyberArch: black background
CyberArch: and no icons
soreau: Desktop looks cleaner without icons anyway
soreau: CyberArch: Since you no longer have driver troubles, please ask in #compiz
CyberArch: ok, one more thing can you tell me what this line does if I put it in /etc/modprobe.d : install amd64_agp /bin/true (i'm not sure about the /bin/true part)
AstralStorm: adamk_: of course it's not supported ;)
spreeuw: nexuiz now works with glsl
spreeuw: but its pitchdark
AstralStorm: spreeuw: hehe
MrCooper: agd5f: is it just me, or are your actual patches one step behind their descriptions? :)
agd5f: MrCooper: whoops. did I attach the wrong patch?
MrCooper: the message still looks the same
agd5f: you sure? looks ok here. v1 was the original. v2, I sent before you responded, v3 was attached to my reply to you
MrCooper: I'm only seeing the code change which was supposed to be in v2 in v3, and I'm not seeing the code change which is supposed to be in v3
MrCooper: but maybe I just looked at it for too long :)
agd5f: MrCooper: no code change, just updated commit message
agd5f: I guess I could add a comment to the code as well
MrCooper: ah, I meant the debug message
agd5f: ah :)
kmays: spreeuw: Could you really push Nexuiz with graphic settings? I used Unigine:Tropics which acts up a little in water reflections and such..
mortal_: the latest git still crashes with urbanterror, now the error message is different (radeon 8500)
mortal_: I have 2.6.32.1, does it have some influence?
dileX: agd5f: I have a backtrace with your latest radeon-pm patches .
agd5f: dileX: looks like something in Zajec's patches. my patches do actually hook up any new functionality yet
agd5f: *don't
dileX: agd5f: you are right. I have same backtrace on "Dec 18 01:16:4" without your patches :-)
mortal_: http://pastebin.com/m465e3af8
mortal_: this is the error msg, it drops back to xorg desktop with a low resolution
agd5f: mortal_: file a bug: https://bugs.freedesktop.org
mortal_: agd5f: I think there is one filed
mortal_: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg45356.html
mortal_: this
agd5f: mortal_: does that patch help?
mortal_: I do not have the tree for compiling
mortal_: I use ubuntu bleeding edge xorg
mortal_: will it be included in the tree?
mortal_: could I somehow just compile the driver part and use it
agd5f: mortal_: I suppose eventually
mortal_: all the other components are recent enough
mortal_: ehm, how do I check the unstable git out?
mjt: got a D510-based system (by a chance really, were shopping for a small itx board and come across the new D510MO mobo released a few days ago)...
mjt: agd5f: do you know anything about it? :)
agd5f: mjt: D510?
mjt: new atom with embedded gpu
mjt: "pineview"
mjt: phoronix says you asked Linux to pull DRM bits which contains pineview bits too.. ;)
mjt: er Linus :)
agd5f: mjt: not me.
mjt: hehe.
mjt: http://www.phoronix.com/scan.php?page=news_item&px=Nzc4OQ
mjt: ok
mjt: that's David not you
mjt: ;)
mjt: but in any way it has nothing to do with radeon really :)
agd5f: mjt: all the drm patches funnel through dave
mjt: yeah
mjt: (this mobo actually works with 2.6.32 but VGA is @60Hz max)
lordheavy: nice ! http://www.phoronix.com/scan.php?page=news_item&px=NzgzMg "AMD Publishes Evergreen Shader Documents"
Ronis_BR: agd5f: hello, I tried default kernel hibernation software but I still couldn't hibernate with radeon driver and KMS enable :
Ronis_BR: agd5f: I'm getting ring test fail at resume
agd5f: Ronis_BR: still using tuxonice?
Ronis_BR: agd5f: no
Ronis_BR: agd5f: uswsusp
Ronis_BR: agd5f: no patches on kernel
muzblast: i have a problem: when i enable kms, display will go blank and not even magic req boot doesnt work. how to solve that? (2.6.32.2 i686 smp desktop-preempt, drm+radeonfb compiled in (same with modules))
muzblast: card is mobility X1400 on dell inspiron 9400
agd5f: muzblast: need to have fbcon loaded to get a console
adamk_: muzblast, radeonfb?
adamk_: muzblast, radeonfb should not be used...
muzblast: radonfb compiled-in
agd5f: and you need xf86-video-ati with kms support for x
muzblast: system crashes before getting to X. just right after loading module or entering gfx mode when compiled-in
adamk_: If you really are using radeonfb, you are asking for trouble.
muzblast: so, radeonfb should be forgotten?
adamk_: You should only use the radeon DRM.
spreeuw: kmays: nexuiz has advanced graphics stuff yes
muzblast: is there different success rate for module version and compiled-in one?
spreeuw: but you have to turn it on
adamk_: Hmmm... progs/glsl/skinning causes FreeBSD to crash and burn.
spreeuw: the defaults are for 9800 cards or so
spreeuw: but you need some superheavy card
spreeuw: or a better driver
spreeuw: for normal
adamk_: muzblast, I've only really tried it recently with the drm stuff compiled in.
adamk_: muzblast, But it should work either way.
spreeuw: kmays: the tropics demo may be more diverse in used shaders
spreeuw: I downlaoded it but havent started it yet
muzblast: if you encounter problems during module load, what do you use to get last-second oops messages? (gfx is already be dead). netconsole ? serialport?
agd5f: muzblast: might be easier to load radeon manually after you have your system up. then you can load it over ssh
muzblast: thank you adamk, agd5f, i'll try and see what happens.
spstarr: looks at Phoronix and smiles
spstarr: all sorts of new goodies
spreeuw: like?
lordheavy: a good xmas gift :-)
lordheavy: http://www.phoronix.com/scan.php?page=news_item&px=NzgzMg
spstarr: i hope my system irq issue can be fixed then I can use KMS for good finally
spstarr: I did get some emails last night from some folks
spstarr: hope this is a small quirk needed for my model
spreeuw: you have some igp or so?
spstarr: airlied: You have a W500 laptop still? It would be nice to see if you also see the irq issues I see also.
spstarr: spreeuw: na, i have something wrong with irq handling, with dynticks on its even worse with it off, i still see issues
spstarr: this process of IP review is working well
spstarr: the balance AMD is providing is working quite well indeed
adamk_: The number in the name of the Xorg log file specifies the display, right? /var/log/Xorg.1.log would be DISPLAY :1 ?
adamk_: Never mind... Confirmed it in the log file.
dileX: adamk_: have vgaarb activated?
adamk_: Hmmm? I was just confirming that I thought because someone on the FreeBSD forums insists that /var/log/Xorg.1.log was just from an older instance of Xorg, and was not from running Xorg on a display other than :0
adamk_: Not even sure what vgaarb is :-)
_KAMI_1: hi
_KAMI_1: Hey Guys!
_KAMI_1: I put 2.6.32 kernel
_KAMI_1: and latest radeon and x org from Xorg edgers PPA
_KAMI_1: and my card (Mobility radeon 3470) works very well
_KAMI_1: thank you
mortal_: my radeon does not work :/
mortal_: 8500
dileX: adamk_: http://tinyurl.com/yaw2j28
adamk_: mortal_, If "does not work" is all you can tell us, I'd assume that your card is broken :-)
mortal_: adamk_: the bug is already filed by someone else
mortal_: it is a oneliner
mortal_: I wish someone committed it to git
_KAMI_1: I have two problem/question
_KAMI_1: 1) in openoffice I got a white screen in the begining of the 3d animation
_KAMI_1: 2) How can I set up HDMI
spstarr: bbl
_KAMI_1: So how to set up HDMI my radeon card (Mobility 3470)
adamk_: _KAMI_1, HDMI audio or video?
gimzo: Hi, is there a way for R800 to give me at least correct resolution in F12 ?
_KAMI_1: audio and video :D
_KAMI_1: I have Ubuntu 9.10
_KAMI_1: 2.6.32 kernel and latest xorg edgers build
adamk_: _KAMI_1, Well HDMI audio through the video card is only supported by the radeonhd Xorg driver or the latest version of the radeon KMS driver in git.
adamk_: _KAMI_1, As for video... If you run 'xrandr' does it show anything attached to the HDMI port?
adamk_: I'm not very familiar with HDMI video, but if it's using display port, I think that was also just recently added to the KMS driver.
_KAMI_1: adamk_:
_KAMI_1: I have two problem/question
_KAMI_1: 1) in openoffice I got a white screen in the begining of the 3d animation
_KAMI_1: 2) How can I set up HDMI
_KAMI_1: (II) RADEON(0): Port2:
_KAMI_1: XRANDR name: HDMI-0
_KAMI_1: Connector: HDMI-A
_KAMI_1: DFP1: INTERNAL_UNIPHY
_KAMI_1: DDC reg: 0x7e20
evil_core: hi
evil_core: what I have broken?
evil_core: I got always black screen
adamk_: _KAMI_1, I don't have an answer to (1)... As for (2), I told you all I know and what to check :-)
evil_core: even with old libGL and old swrast
evil_core: in quake3
evil_core: can ddx drvier be broken?
evil_core: and how to force swrast?
adamk_: evil_core, Simply removing the DRI driver your GPU normally uses should force libGL to load swrast. Not sure if there's an environmental variable to force it to use swrast.
adamk_: evil_core, Does 'glxinfo' show direct rendering with the correct renderer string?
evil_core: yeah, ut2k4 and neverball works
evil_core: but not ioquake3
evil_core: quake3 got black screen from first play with updating kernel drm
evil_core: adamk_: there was some env, but I got internet very rarely when started snowing
evil_core: fuckin trees and wifi ;)
evil_core: Zajec: any new pm patches?
Zajec: evil_core: don't see need for
Zajec: evil_core: waiting for agd5f's code
Zajec: reading PowerPlayInfo
dileX: Zajec: saw my backtraces?
evil_core: http://www.phoronix.com/scan.php?page=news_item&px=NzgzMQ
Zajec: dileX: in bug report?
evil_core: so only r600 will got GLSL soon?
dileX: Zajec: no BR
dileX: (1st thought its agd5f pm-patches, but its before they were published)
evil_core: anybody can run ut2k4 on r500 gallium w/o wxploding kernel driver?
Zajec: dileX: what is this backtrace about?
Zajec: dileX: is that caused by my patch?
evil_core: http://www.phoronix.com/scan.php?page=news_item&px=NzgzMQ
evil_core: anybody can explain me that drivers?
Zajec: ah, yeah, it is: "EIP is at radeon_pm_compute_clocks+0x83/0x2e0 [radeon]"
evil_core: I got radeon_dri.so
dileX: Zajec: not sure, agd5f thinks so
evil_core: for gallium
evil_core: but what is r300g?
Zajec: weird, it looks like missing first line with info about problem...
evil_core: and what branches of mesa, ddx and ddx should I use?
Zajec: is that some NULL reference or what? :/
Zajec: evil_core: r300g is gallium driver for r3xx-r5xx
evil_core: Zajec: is that waht I am using?
Zajec: evil_core: you saw fence error, didn't you?
evil_core: Zajec: yes
evil_core: many of them in gallium ut2kt
Zajec: dileX: could you check your log for some message before this pastebin-ed thing?
evil_core: but not in non-gallium quake3 blackscreen
evil_core: theres no error
Zajec: evil_core: do you have multiply errors?
Zajec: evil_core: or just one and reboot is needed?
evil_core: I am using currently 2.6.32 + drm 33rc1
Zajec: evil_core: what is quake3 blackscreen? don't understand
evil_core: black screen and quake3 hangs
evil_core: I go to consoel and killall -4 quake3
evil_core: no error
evil_core: from libGL or from quake
Zajec: evil_core: does it happen only with PM patch?
evil_core: no
Zajec: :|
evil_core: always
Zajec: so what is your issue with PM and fence
Zajec: ?
evil_core: it wasnt issue with pm
evil_core: i removed pm because it was unusable
evil_core: only blinking while frew switching
evil_core: with pnm I got probvlem with lower clocks, likebig moire
evil_core: erverywhere
evil_core: like analog interferences
evil_core: like broken DAC
evil_core: when 15/5Mhz
evil_core: but its not problem, i removed this patch, because like other said with clockgating its unusable because it doesnt save alot power
dileX: Zajec: seems not to have more infos in /var/log/*.1
evil_core: ../xf86drmMode.c:247: error: variable ‘dirty’ has initializer but incomplete type
evil_core: master drm is broken
_KAMI_: re
_KAMI_: What does this message means, and how to fix it: IRQ's not enabled, falling back to busy waits: 2 0
[Enrico]: _KAMI_: you have to use kms with a recent drm (you need drm-next) and you also need to install the radeon firmware for irq
evil_core: airlied broken drm? or something bad with mine gcc?
lordheavy: evil_core: libdrm from git master is building fine here
_KAMI_: [Enrico]: I am checking it
_KAMI_: [Enrico]: drm2 is installed
[Enrico]: drm2??
_KAMI_: yeah
_KAMI_: no drm-next
[Enrico]: _KAMI_: you need drm-next. but i didn't understood what do you mean with drm2
_KAMI_: I dont know what is the name of radeon firmware package
_KAMI_: I have package called drm2
[Enrico]: _KAMI_: tells me nothing sorry
agd5f: Zajec: my current patches if you are interested. not hooked up yet, but you can see where they are going: http://www.botchco.com/alex/xorg/pm/
Zajec: agd5f: browsinh
Zajec: *ing
_KAMI_: [Enrico]: Back to the HDMI
_KAMI_: I have this to xrandr: http://www.pastebin.ca/1724061
Zajec: agd5f: see one mistake in my patch
Zajec: agd5f: i didn't remove all DPMS_OFF checks which are incorrect
Zajec: as we need to check mode again after back from DPMS_OFF
_KAMI_: I have connected (LCD panel of laptop) VGA, and HDMI (same TV) resuloton 1360x768    /   59.8*
Zajec: in radeon_legacy_encoders.c
Zajec: oh, pci lanes, great
Zajec: i missed that
Zajec: hm, but rv370 only...
Zajec: not for r600
agd5f: Zajec: code for r6xx+ is in xf96-video-ati
agd5f: just needs to be ported
Zajec: last one is huge, will check that
Zajec: agd5f: ok, i'll port it
bridgman: kami, the pastebin looks right - what is the driver doing differently from what you want ? guessing you want hdmi at a different resolution ?
bridgman: are the displays cloned right now or showing separate info ?
bridgman: do you actually have three displays or just two ?
Zajec: agd5f: should we care about pci lanes info from AtomBIOS?
Zajec: agd5f: i would like to decrease pci lanes to 1 for DPMS_OFF
agd5f: Zajec: probably makes sense to follow the tables
Zajec: agd5f: would you like me to modify my PM patch (V9) or make little fix on top of it?
agd5f: Zajec: fix for what?
agd5f: the DPMS off thing? just make a v9 for that
Zajec: agd5f: we shouldn't check for DPMS_OFF in radeon_legacy_encoders.patch
Zajec: ok
Zajec: agd5f: what are low and hight engines in RS780?
agd5f: Zajec: it's a 24 bit value
Zajec: ah :)
agd5f: low 16 bits and high 8 bits
Zajec: err, moment... I see something confusing
Zajec: + USHORT usEngineClockLow;
Zajec: + UCHAR ucEngineClockHigh;
Zajec: does UCHAR is really some CHAR? or is this just for bits length?
agd5f: Zajec: 8 bit value
Zajec: ok, thanks :)
agd5f: UCHAR 8 bit, USHORT 16 bits, ULONG 32
Zajec: oki :)
Zajec: but still, i hate reverted bit order in AtomBIOS ;)
Zajec: and generally anywhere where it is used ;)
agd5f: Zajec: reverted bit order?
Zajec: little/big endianess :)
agd5f: Zajec: it's little endian
Zajec: yeah, i know... :)
Zajec: i really preffer big endian :)
Zajec: nevermind, have to get used to that :)
airlied: it should be both
airlied: since we work on ppc
aljaz1: Hi there! Stopping here a bit to find out a bit more about the problem described here: http://bugs.freedesktop.org/show_bug.cgi?id=25460. I'd very much like to use the KMS variant if possible and would be happy to provide any additional info on the subject.
Zajec: agd5f: why do we have clock_info array for each power_state?
Zajec: agd5f: and we use only 1 element every time?
agd5f: Zajec: r600+ have multiple clock modes per power state
Zajec: ag, frev==4
Zajec: yeah
agd5f: so take them all and pick between them at runtime, otherwise, which one do you take?
Zajec: agd5f: picking the one is tricky... :/
agd5f: Zajec: they tend to have different voltages
agd5f: if the clocks are the same
Zajec: agd5f: emm, so...?
spstarr: tries VBOs
agd5f: Zajec: so you have power state 0 which has 3 clock modes each clock mode may have different voltages and clocks
agd5f: so in power state 0, you may transition between clock modes as needed. when factors change, you may change to a different state and then transition between clock modes there as well
agd5f: really comes down to how we decide when to change modes/states
Zajec: agd5f: so first I have to choose power_state and then clock_info
Zajec: agd5f: but which power_state should be used when?
Zajec: agd5f: it doesn't seem they have "names" like "this if for DPMS_OFF", "this if for low load"
agd5f: Zajec: things aren't that simple
Zajec: yeah, that is thing I know :P
Zajec: btw. what is result of: bool asd = 10;
agd5f: Zajec: you look at the current state of the hw. how many displays are on, how many fences outstanding, etc. Initially we will probably only care about 3 states, max, min, and somehting in the middle
Zajec: agd5f: don't you increase too early: "state_index++;"
Zajec: this should happen after matching mode as default i guess
agd5f: Zajec: yeah
agd5f: I'll fix that up
aljaz1: so I guess there's no idea at the moment why HDMI output switches off when I switch off DVI under KMS (rv730xt, 2.6.32.2, mesa/drm/radeon - today's git)? :)
dileX: aljaz1: give drm-next a try?
aljaz1: dileX: so, back to compiling you suggest? I was thinking of trying 2.6.33-rc1 at first...
dileX: aljaz1: drm-next has latest drm-2.6 stuff.
dileX: 2.6.33-rc1 misses some patches
tesuki: Are there any good guide how to get started Hacking on the Driver?
dileX: aljaz1: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-next
aljaz1: dileX: I'm aware of that - it's just easier to know if it's already been tackled with...
tesuki: Should I first read about how the kernel and drivers interact or what should I learn?
dileX: aljaz1: if you wanna test 2.6.31-rc1, I have the patches from drm-radeon-testing on top
aljaz1: dileX: you mean 2.6.33-rc1?
dileX: sorry, yes
dileX: http://pastebin.ca/1724169
aljaz1: dileX: so I take the rc1 tar and patch with this file?
dileX: for example
dileX: cd linux-2.6.33-rc1 ; patch -Np1 -i /path/to/patch
aljaz1: dileX: ok, off I go trying this one. thanx for now.
Zajec: agd5f: ok, so we should get minimum, maximum and middle modes... how can I decide which is minimum? for example I can not compare modes: 800engine & 600memory vs. 600engine & 800memory
Zajec: agd5f: how can i know which will eat less power?
agd5f: Zajec: we'll have to figure that out. the flags will probably be useful. I was planning to unify them
Zajec: agd5f: flags? ATOM_PPLIB_R600_FLAGS_*? not many of them
spreeuw: is there anything useful for r700 in those r800 docs?
agd5f: Zajec: unify across different power table versions. e.g., most have a SINGLE_DISPLAY flag or PERFORMANCE/POWER_SAVE, etc.
Zajec: agd5f: is that released?
Zajec: agd5f: I can see ATOM_PM_MISCINFO_POWER_SAVING_MODE
Zajec: agd5f: but that's for ulPowerPlayMiscInfo (Legacy Power Play Table Definitions)
agd5f: Zajec: yes, it's there. ATOM_PPLIB_CLASSIFICATION*
agd5f: ATOM_PPLIB_DISALLOW_ON_DC, etc.
Zajec: agd5f: should we store whole usClassification or extract needed info from it?
agd5f: Zajec: I was planning to unify some subset of the flags from all the different table revisions
agd5f: PM_SINGLE_DISPLAY, PM_AC_ONLY, PM_PERFOMANCE, PM_POWER_SAVE, etc.
Zajec: ok
lexsoOr: hey guys
lexsoOr: I've got a ati radeon mobility X1600
lexsoOr: are there any drivers availible which DONT mess up my pc ? :P
adamk_: lexsoOr, Sure, the open source drivers.
adamk_: lexsoOr, They should come with any reasonably up-to-date distribution.
spstarr: news
spstarr: agd5f: GLSL is working on r6xx
spstarr: although it is ever, so slowly < 1FPS
spstarr: this is a good sign, slow or not it didnt crash now (second life)
spstarr: turns on force power management
spstarr: non-KMS for now
spstarr: tries GLSL with LowPower
spstarr: good work :)
Zajec: agd5f: could you update your patch (state_index++) and update my patch (V8 -> V9)?
agd5f: Zajec: yeah, I'll do it later this evening
spreeuw: does AMD have an answer to ION?
spreeuw: for XBMC
spstarr: Nvidia's ION?
spstarr: I wouldn't worry about ION, NVidia is self-destructing :)
spreeuw: yes an intel/nvidia bundle
spreeuw: for lower energy media cnetres
spstarr: they're working to become a niche company
spreeuw: I dont really care about them
devh: hi! i get "/usr/bin/X: symbol lookup error: /usr/lib64/xorg/modules/drivers/radeon_drv.so: undefined symbol: drmGetDeviceNameFromFd" with mesa/libdrm/xf86-video-ati all master and 2.6.33_rc1 KMS, nomodeset works just fine? any ideas?
jcristau: devh: your libdrm is too old
devh: jcristau: git master is too old?
jcristau: if it doesn't have drmGetDeviceNameFromFd it's not from git master
devh: commit fdb33d56de3edf27f24c6db0e6beaed823f7bc38
devh: Author: Dave Airlie
devh: Date: Mon Dec 21 15:03:31 2009 +1000
devh: is the last commit i have, building from git
spreeuw: commit f67748038935e609aa85450b20d550b4813c9429
spreeuw: Author: Eric Anholt
spreeuw: Date: Wed Dec 16 15:50:40 2009 -0800
spreeuw: mesas
spreeuw: commit fdb33d56de3edf27f24c6db0e6beaed823f7bc38
spreeuw: Author: Dave Airlie
spreeuw: Date: Mon Dec 21 15:03:31 2009 +1000
spreeuw: for drm for me
devh: oh sorry! my bad! had a stale copy in /lib64 and the new one in /usr/lib64. thanx for the help though! ;)
Zajec: agd5f: ping
agd5f: Zajec: pongish
Zajec: agd5f: where I should define some unified flags like ONLY_SINGLE_HEAD?
Zajec: radeon.h is fine?
agd5f: Zajec: sure
Zajec: agd5f: when do we need to convert LE to CPU?
Zajec: (little endian)
Zajec: agd5f: 16 and 32 bits only?
agd5f: Zajec: yes when you read from the bios
Zajec: UCHAR can be read "as is"?
biker_rat: Should the libdrm package contain libdrm_radeon.so.1?
biker_rat: I have a question about libdrm & kms
spreeuw: mja
spreeuw: yes it does biker_rat
gsedej: hello! I have RV350, ubuntu 9.10, no KMS, no DRI2. I have problems with textures. I think Gl.Texture2D is not working OK. (I use mono and TAO framework in C#)
gsedej: how to check if Gl.Texture2D is running ok natively?
airlied: if you build it with the options in the wiki page yes
airlied: oops he left
airlied: 2D textures should be fine, its like basic GL
gsedej: airlied, here is my game in C# using openGL for render
gsedej: http://www.youtube.com/watch?v=T4sfrA1lVDg
gsedej: OpenGL 1.5 works fine
gsedej: but textures are missing
gsedej: I think in some other test are missing too
aljaz: oh well. It took a bit of time and dileX isn't here anymore. I compiled the 2.6.33-rc1 with patches from drm-next as he suggested but now I'm struggling to pass through the boot process. It says requesting the rlc firmware but it just hangs there for about a minute and then displays some trace calls. I cannot copy them nor are those written in the log. Both firmware files are under /lib/firmware/radeon and /lib/firmware/2.6.
airlied: you need another firmware
aljaz: Now I don't really know whether it found that file or not
aljaz: which one?
airlied: http://people.freedesktop.org/~agd5f/radeon_ucode/
aljaz: I have those already - ?
aljaz: newer versions?
aljaz: this is what I already have:
aljaz: aljaz@slash:/lib/firmware/radeon$ ls
aljaz: R600_rlc.bin R700_rlc.bin
aljaz: I've rewritten them and will try again...
aljaz: nope. still the same- asking for the file and not taking it. Any idea where it goes looking for them? I've put them in lib/firmware/radeon
airlied: did you rebuild initrd? are you building radeon into the kernel?
aljaz: radeon is built in the kernel and I've rebuilt the kernel since adding the files. I can however try and rebuild initrd.
[Enrico]: aljaz: if you build radeon into the kernel you have to include the firmware in the kernel as well
[Enrico]: aljaz: this is done with EXTRA_FIRMWARE config
aljaz: I do it all the time
aljaz: It works but not with the new interrupt firmware
[Enrico]: aljaz: that's normal give me time to explain
aljaz: both other files are loaded, it hangs while loading the third one
lordheavy: gsedej : your problem can be related to "non power of two" textures
[Enrico]: aljaz: the new irq firmware is not included in kernel source, so you have to cp them from /lib/firmware/radeon to /usr/src/linux/firmware/radeon and add them to EXTRA_FIRMWARE
gsedej: lordheavy, Does exist some test program ?
gsedej: I only use mono/C#
[Enrico]: aljaz: there is another way if you want. that is setting EXTRA_FIRMWARE_DIR to /lib/firmware and using EXTRA_FIRMWARE as before
lordheavy: glxinfo | grep power_of_two
lordheavy: GL_ARB_texture_non_power_of_two if supported
[Enrico]: aljaz: i've never tested including it in initrd, but this should work too
aljaz: neither did I
gsedej: lordheavy, no output
lordheavy: so you need to round your textures to power of two otherwise textures will be blank (or white)
gsedej: this problem is related to?
aljaz: enrico: so here is what I got: I have those files in /lib/firmware/radeon and in linuxsourcedir/firmware/radeon
lordheavy: gsedej: it's a common mistake
lordheavy: search about opengl and power of two textures
aljaz: enrico: what is this EXTRA_FIRMWARE again? a path?
gsedej: It's driver or framework bug. Same program works fine on nvidia
[Enrico]: aljaz: no a kernel config variable. did you ever recompiled a kernel?§
aljaz: enrico: yes, many times and that variable is always on. :)
[Enrico]: aljaz: that variable is not on or off, it is a list
[Enrico]: aljaz: a list of firmware to be included in the kernel
lordheavy: gsedej: hardware limitation -> http://www.opengl.org/wiki/NPOT_Textures
[Enrico]: aljaz: for example i use EXTRA_FIRMWARE="radeon/RV620_pfp.bin radeon/RV620_me.bin radeon/R600_rlc.bin" since i need those 3 fw
gsedej: lordheavy, so textures that are not 4x4,8x8, 16x16, .. just won't work?
lordheavy: gsedej : yes, you need to resize them
aljaz: enrico: I guess I never saw it that way because I do config with xconfig. Going to check now what's there...
gsedej: lordheavy, so this is related to ??? (game works OK on nvidia, so it's not opengl... game works on this computer under windows and directx, so it's not hardware)?
aljaz: enrico: no, I never set that variable. I only set the "CONFIG_FIRMWARE_IN_KERNEL=y" and that was it
lordheavy: directx isn't opengl, and it's a hardware limitation on your card (RV350), but you can workaround that limitation
gsedej: so, looks like windows version of framework has workaround, because game works (but it's kin'a slow)
lordheavy: some drivers expose npot extension, but it's terribly slow, it's better to resize to pot size to gain speed
[Enrico]: aljaz: i use xconfig too :D
[Enrico]: aljaz: CONFIG_FIRMWARE_IN_KERNEL=y doesn't includes the radeon irq firmware since it is NOT included in kernel
[Enrico]: aljaz: unluck kernel upstream doesn't accept new firmware anymore ...... don't ask me why
aljaz: enrico: so we'll have to do mechanical work everytime then, I guess?
gsedej: lordheavy, THANKS man... I was searching for that answers for months
aljaz: enrico: unless distros include them...
[Enrico]: aljaz: well if you set EXTRA_FIRMWARE_DIR to /lib/firmware you have to do it only once (if you use your old .config for newer kernel -- and make oldconfig :D -- )
aljaz: enrico: yes that's my laziness tactics. :)
[Enrico]: aljaz: eheheh
aljaz: enrico: although I still struggle through all the new options and wonder whether I need them or not
aljaz: enrico: off to restarting again
aljaz: enrico: Success!
[Enrico]: aljaz: :D
aljaz: And what is more: HDMI and DVI are separated!!! :)
[Enrico]: aljaz: good work, enjoy interrupts support
[Enrico]: eheheh
aljaz: So I guess I can close the bug now
aljaz: I was only molested by that hdmi-dvi siamese-twins thing
aljaz: not sure what to do with interrupts, though
[Enrico]: aljaz: well you do nothing directly, they are just usefull ^^
aljaz: but my only motivation was getting kms back on a newer card so I can have acceleration on other users
aljaz: enrico: thanx. Now I really need to go to sleep! bye
GoGi: drivers for all types of hardware have always been in the kernel, why not for graphic cards?
GoGi: or why only now with kernel mode setting?
airlied: GoGi: history
airlied: there have be graphics drivers in the kernel, fbdev etc
amarks: hey guys, what is the preferred method for stress testing? using nexuiz to reproduce an issue isn't immediate, i would like to spin the gpu harder, is there a test tool or a more demanding game i should load?
airlied: amarks: pretty much just games, usually crashing is more to do with something a game does than any stress test
amarks: airlied: is nexuiz pushing my rv790 hard though?
airlied: amarks: probably other games might do more /less
airlied: its really a per-app kind of thing
evil_core: airlied: did you broke drm?
amarks: airlied: ok thank you
evil_core: I cannot compile it, git log says you changed it lasgt
evil_core: ../xf86drmMode.c:247: error: variable ‘dirty’ has initializer but incomplete type
airlied: evil_core: no sounds like a local issue
airlied: haven't heard anyone else complain
Droste: works for me too, but i just checked the file... is "struct drm_mode_fb_dirty_cmd dirty = { 0 };" wrong? I expected "struct drm_mode_fb_dirty_cmd dirty;"
MostAwesomeDude: Nope, correct and preferred.
Droste: ok
MostAwesomeDude: Initing structs to 0 keeps valgrind off our backs, and makes debugging easier.
Droste: ok, didn't know that :-)
Droste: evil_core: maybe your "include/drm/drm_mode.h" isn't up to date
GoGi: I have a new x server version and now Ctrl-Alt-Backspace does not work anymore why?
Droste: add Option “DontZap” “false” to your xorg.conf (section server flags)
Draconx: it's disabled per default, and the documentation for enabling it is wrong, you need to add Option "XkbOptions" "terminate:ctrl_alt_bksp" to your xorg.conf.
Draconx: (the decision to make X by default behave very much like a hardlocked system -- black screen, no mouse cursor, unresponsive quit command -- baffles my small little brain)
MostAwesomeDude: You're right. We should make it a blue screen, white cursor, and quit on Ctrl-Alt-Del.
MostAwesomeDude: No, wait. Checkered screen, black cursor, quit on Ctrl-Shift-F1.
Draconx: I was thinking more like a grey pattern, an X shaped mouse cursor and a quit command (ctrl+alt+backspace sounds reasonable).
MostAwesomeDude: Never used emacs, I take it?
airlied: if you are testing X, X -retro does that
Draconx: well, it doesn't enable zapping.
MostAwesomeDude: I've got it! Red screen, rainbow cursor, quit if any four keys are held down.
MostAwesomeDude: In all seriousness, defaults that *nobody* would like are best, because it incites distros and users to do something about it.
MostAwesomeDude: Kind of like not having a default root password.
Draconx: the first time I ran X when I installed it on a new machine with the latest and greatest, I seriously thought the intel driver had deadlocked, becuase I was faced with a black screen, no mouse cursor, and the quit command didn't work.
MostAwesomeDude: What program were you running?
Draconx: X.
MostAwesomeDude: And which distro?
MostAwesomeDude: So, you were on LFS, Arch, or Gentoo, and you ran X by itself.
Draconx: Turns out that someone had just changed the default behaviour of X to be: black screen, no mouse cursor and a disabled quit command.
Draconx: This was not a LFS, Arch or Gentoo decision, it was an X server decision.
MostAwesomeDude: Well, you won't say which distro you're running, so I'm guessing at the distros that let you directly mess with these things easily.
Draconx: well, one that lets me install and run an X server.
MostAwesomeDude: X isn't meant to be run bare, without setup scripts. It doesn't contain policy.
Draconx: I had xinit configured to start with a black background, because I didn't like the grey-ish pattern appearing before my wallpaper was loaded, yeah.
evil_core: will check, butDroste: git pull in rootdir isnt enough?
MostAwesomeDude: Well, that explains why X didn't exit. X will exit when there are no more clients left; you had a client doing the wallpaper.
Draconx: uhm, X doesn't exit when there are no clients left.
Draconx: xinit kills it when the program that xinit starts exits.
airlied: X resets when no clients left
evil_core: Droste: git diff shows differences, thx
evil_core: how to update dirs if git pull isnt enough?
Droste: evil_core: I'm not really familiar with git, but I would suggest "git checkout"
Draconx: airlied, okay, but it doesn't quit.
Droste: though git pull should be enough
evil_core: Droste: no, its not svn
evil_core: it only marks something
evil_core: or display
Droste: I know ;-) but I thought checkout also reverts local changes which may lead to merge errors
BioTube: cehckout just changes the working branch
BioTube: reset --hard HEAD removes all uncomitted changes
Draconx: MostAwesomeDude, and the client that sets the wallpaper exits after it's done its business.
evil_core: BioTube: doesnt help
evil_core: # git pull
evil_core: Already up-to-date.
MostAwesomeDude: # The very top of Death's Peak in Chrono Trigger has a tree. Using the Time Egg here allows one to bring Crono back from a timeline where he died.
MostAwesomeDude: Boy, this is truth.
MostAwesomeDude: This is also "stop looking up video game spoilers."
BioTube: MAD: relevence?
MostAwesomeDude: This is also "unbind the middle-click from pasting into the console."
evil_core: BioTube: helped :)
MostAwesomeDude: Not relevant, just an embarrassing mispaste.
BioTube: ahh
MostAwesomeDude: On the bright side, it doesn't appear to be obscene.
Droste: BioTube: "git checkout ." re-checkout all files, overwriting any local changes. This is most similar to "svn revert" if you're used to Subversion commands
evil_core: should I use xcb?
BioTube: evil_core: it's just an alternative to xlib
Droste: has anyone tried kde4.4 compositing with xorg7.4, current drm,mesa,xf86-video-ati and a single core cpu? is it normal that the xorg process runs with an average cpu usage of 50%? no effects enabled, only compositing mode...
evil_core: ddx and mesa shoukd be rebuild after libdrm upgrade?
chithead: normally it is a good idea to build x server, ddx and mesa against the same version of libdrm
evil_core: xserver?
BioTube: xserver shouldn't deal with libdrm directly
evil_core: I am distro developer, hour ago Mesa was upgraded, libdrm now
evil_core: wonder if should I increment release and rebuilt them
evil_core: http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl
evil_core: its glsl w/o gallium for r500?
airlied: its just GLSL in the generic compiler
evil_core: but its normal that gallium + ut2k4 breaks kernel driver?
MostAwesomeDude: Part of that branch needs to get merged to master, part of it's broken.
evil_core: Iam also wondering if mine card is sinmply too slow for uxga mode
MostAwesomeDude: r300g has had some updates in the past few weeks that greatly improve stability and performance.
evil_core: I also wonder if the problem is kernel or mesa for me
evil_core: I gor 33rc1 drm backported to 2.6.32
evil_core: w/o gallium I got blackscreen in ioquake3, even with system libGL and swrast
muzblast: looks like kernel crashes if i load fbcon module before radeon. is that normal?
evil_core: no
evil_core: i got fbcon builtin
muzblast: blender2.5alpha0 performance with triplebuffer is unusable... though works find under windows. is anybody hacking on that area?
muzblast: i guess not then.
evil_core: how to get drm-radeon-testing?
soreau: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git; cd drm-2.6; git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
soreau: muzblast: The radeon devs develop the radeon driver, not individual apps
evil_core: soreau: thx
evil_core: it means that we are forced do download first HEAD and later update it to drm-radeon-testing branch?
airlied: its git you download it all
soreau: evil_core: It will download airlieds git kernel tree then switch to the drm-radeon-testing branch
evil_core: so can we download much less by downloading only one branch?
agd5f: evil_core: you have to download the whole thing
evil_core: but is mine V5200 too slow for 1600x1200?
evil_core: I see it only depends on resolution, on 1280x1024 all apps works smooth
evil_core: i checked q3, neverball, tc-elite, ut2k4 andd all them become laggy when set to 1600x1200 even when all other settings are set to much lower
kmays: some apps may 'crash' if resolution too high for them.
evil_core: and I am scared that I ever will be forced to got laggy gfx or upscale lower res
evil_core: no, not crashing, but definitely not smooth. Not slideshow but not enough for fpp
muzblast: soreau, i know. i was just wondering when radeon drivers might be able to have work-usable performance.. real-world apps are good test ground for that, no?
kmays: evil_core: just not optimized in all areas...try Unigine:Tropics benchmark.
evil_core: kmays: I dont wangt to benchmark mine card. I wonder if mine card isnt to slow for 1600x1200 in OpenGL general
evil_core: kmays: not, new shi y titles, but ut2k4,neverball, quake3/tc-elite, even bzflag
evil_core: the best thing I get with unstable drivers is no-tearing, with stable drm it was nightmare
soreau: muzblast: Work is being concentrated on feature implementation and not performance of those features yet. My best guess is whatever you're doing/seeing is likely falling back to software routines. In short, check back in a few months ;)
muzblast: ok
soreau: hides from bridgman
kmays: Your card should be fast enough... I have a ATI 9250 that pushes a 1080p screen with those games..no problems... (not the hardware).
evil_core: with unstable ddx I get pixelated some textures in quake3, with unstable kernel I am getting black screen in quake3
evil_core: kmays: its r600?
evil_core: omg, old r350
bridgman: 9250 is r2xx
evil_core: yeah. right
bridgman: r350 is 9800 afaik
evil_core: I got one 9200, horrible perforfance
evil_core: bought it because of egl and Xgl, month later it was deprecated and developers made driver for r300
evil_core: kmays: and you got perfect framerate while rotating camera in 1080p rendering resolution?
bridgman: evil_core, is openarena working for you ?
evil_core: no, because of libpng or jpg
evil_core: too lazy to patch it
bridgman: you should get that fixed first, or it's going to be hard to figure out which are driver issues and which are not
evil_core: but its ioquake3 engine
evil_core: airlied: ut2k4 works in gallium on your T60p?
airlied: evil_core: no idea, I don't get to play games
bridgman_: evil_core; the reason I suggest getting openarena working is that it's one program for which pretty much everyone knows the status
bridgman_: at least on classic mesa, not sure about 300g ;)
evil_core: I too, prefer 2d one, but all you are checking drivers stability is openaera and glxgears?
bridgman_: ?
bridgman_: I'm just saying that if you ask 10 people about the status of a game more of them will know about openarena
airlied: only runs gears and openarena ;-0
bridgman_: 300g is still at the "add functionality" stage, don't think it's going through heavy app-level testing yet
airlied: and compiz and gnome-shell
bridgman_: focus is still on getting all the unit tests passing afaik ;)
bridgman_: airlied; what else is there ?
airlied: bridgman_: oh and piglit sometimes ;-)
evil_core: i prefer wmaker, and after running powertop I becamed paranoid that disabled blinking cursor in powertop ;)
evil_core: in xterm*
evil_core: drm-radeon-testing is from 2.6.29?
evil_core: i called git log
bridgman_: drm-radeon-testing should be newer than 2.6.33
bridgman_: it's the stuff that will eventually go into 2.6.33 or 2.6.34
evil_core: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git; cd drm-2.6; git checkout --track -b drm-radeon-testing
airlied: its based on 2.6.31 and a lot somewhere
evil_core: this commands are enogh to get all from scratch?
airlied: hmm ust have rebased itsv2.6.32 now
airlied: v2.6.32-256-g0786201
airlied: evil_core: you forgot the origin/drm-radeon-testing
airlied: on the end of the git checkout I think
evil_core: it doesnt change nothing :/
evil_core: anyway its still 2.6.29
evil_core: in Makefile
evil_core: 2.6.29rc2
bridgman_: evil_core, maybe you're looking at different code from airlied
evil_core: # git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
evil_core: warning: refname 'origin/drm-radeon-testing' is ambiguous.
evil_core: fatal: git checkout: branch drm-radeon-testing already exists
bridgman_: doesn't the origin/xxx specify which branch you're getting code from ?
evil_core: I hadnt written origin before
evil_core: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git; cd drm-2.6; git checkout --track -b drm-radeon-testing
evil_core: I used it to clone
bridgman_: is when it comes to git
airlied: evil_core: git branch -D drm-radeon-testing
airlied: git checkout master
airlied: then git branch -D drm-radeon-testing
airlied: then rerun
airlied: bridgman_: so do you have access to schematics? :-)
evil_core: airlied: rerun all commands?
evil_core: from git clone?
airlied: evil_core: no just the checkout one
bridgman_: airlied; I know who to ask...
evil_core: ]doesnt work
airlied: bridgman_: I'm not sure you can wire that CEC line via a DVI<->HDMI convertor
airlied: unless there is a spare DVI ping you can abuse for it
bridgman_: ah yes
MostAwesomeDude: OA is laaaag but playable, if only barely.
evil_core: takes less then second, and Makefile identical
bridgman_: MostAwesomeDude; that's on 300g ?
airlied: evil_core: can you pastebin git branch -a,
MostAwesomeDude: bridgman_: Yeah.
evil_core: http://pld.pastebin.com/f71f0a2a5
bridgman_: ok, that's still huge progress ;)
airlied: evil_core: okay git checkout master
evil_core: so maybe add 'remotes'?
airlied: or maybe git checkout -f master
airlied: then git branch -D origin/drm-radeon-testing
airlied: then do the git checkout line again
evil_core: # git checkout -f master
evil_core: Switched to branch 'master'
evil_core: [root@sinistar drm-2.6]# git branch -D origin/drm-radeon-testing
evil_core: Deleted branch origin/drm-radeon-testing (was 1de9e8e).
evil_core: [root@sinistar drm-2.6]# git checkout --track -b origin/drm-radeon-testing
evil_core: Branch origin/drm-radeon-testing set up to track local branch master.
evil_core: Switched to a new branch 'origin/drm-radeon-testing'
airlied: you are doing it wrong ;)
airlied: that git checkout line is bogus
airlied: git checkout --track -b drm-radeon-testing origin/drm-radeon-testing
airlied: you'll have to run all those commands again
evil_core: # git checkout -f master
evil_core: Switched to branch 'master'
evil_core: [root@sinistar drm-2.6]# git branch -D origin/drm-radeon-testing
evil_core: Deleted branch origin/drm-radeon-testing (was 1de9e8e).
evil_core: [root@sinistar drm-2.6]# git checkout --track -b origin/drm-radeon-testing
evil_core: Branch origin/drm-radeon-testing set up to track local branch master.
evil_core: sorry
evil_core: it works, thanx :)
evil_core: its 5:51AM and i misstyped ']' as'[' in screen
evil_core: Its getting bright, so I am going sleep
evil_core: gnight all!
bridgman_: MostAwesomeDude, just curious -- do you have a feeling for what is making OA slow on 300g or is that "one of the things that will need to be figured out eventually" ?
MostAwesomeDude: bridgman_: Dirty state emit is slow; we need to move over to atoms.
MostAwesomeDude: Buffer clears aren't quite as fast as they could be.
MostAwesomeDude: We should use immediate mode instead of VBOs for small renders.
MostAwesomeDude: No Hi-Z could be a problem.
MostAwesomeDude: Those are the main things.
bridgman_: ok, so no real mysteries then... great
bridgman_: tx
MostAwesomeDude: Well, I mean, it's kind of a mystery in terms of what's different from r300c.
MostAwesomeDude: The big differences are purely architectural.
bridgman_: ahh, so those aren't things that are done differently from 300c ?
airlied: we don't have HiZ in r300c
MostAwesomeDude: Yeah, these are all also r300c problems, more or less.
MostAwesomeDude: r300c has state atoms though.
bridgman_: my recollection was that OA ran pretty well on 300c, although I had some kind of big honkin' 5xx card IIRC...
MostAwesomeDude: And I *know* Gallium can improve on at least a couple of atoms in terms of emission and state change.
bridgman_: I'm trying to figure out whether there's enough work for a full time tester assuming we can target what they look at...
bridgman_: maybe I never noticed the mesa releases before, but it seems like we have mesa releases happening all the time these days ;)
agd5f: ARGH! kernel i2c is not conducive to hw i2c engines
airlied: agd5f: it should be, I thought the whole algorithm stuff was meant for that