simplexe: hi all
hifi: today I'll try to get my TV to accept 1080p over DVI->HDMI and Radeon X1200
hifi: didn't get even 720p last time I tried
hifi: hm, no xvideo support
hifi: RS690 and KMS no xv, is that supposed to be?
chithead: no. possibly you don't have drm properly enabled
chithead: make sure that your libdrm is compiled with --enable-radeon-experimental-api
hifi: oh, I forgot to use PPA for xorg
hifi: but anyway, I got full 1080p \o/
hifi: oh shi
hifi: ddx thinks I have a HDMI port
nanonyme: hifi: It's likely you do, kinda.
nanonyme: Considering DVI == HDMI.
nanonyme: Mostly no point shipping cards with actual HDMI ports, having two DVI ports and an adapter is more useful usually.
chithead: especially considering that hdmi is electrically only single-link dvi
nanonyme: Such a card suffers a bit with a legacy monitor with only VGA connectors though. :/
hifi: nanonyme: my card has a VGA and DVI output, it shows both _and_ DHMI
hifi: though a "pro" model of the same motherboard (integrated gpu) has addittional HDMI port
hifi: before using git version of ddx there were only DVI and VGA
hifi: and I think HDMI was in the list but disconnected
hifi: also the resolutions for "HDMI" are a bit strange
hifi: and 0x0 for DVI
paranoid_android: sweet, blender corruption is actually gone now on r7xx for me
paranoid_android: only picking still doesn't work
paranoid_android: actually it does work in edit mode
paranoid_android: i just cant select the camera/lamp object :p
nanonyme: paranoid_android: Would imply it has been fixed quite some time ago, (many days? *gasp*) I don' think there's been commits recently. :)
paranoid_android: oh, yeah it's been a few days since i pulled
mcgreg: is it correct hat lspci+lsusb lists ALL hardware, no matter if they are support or not?
paranoid_android: it can also say if it is in use by a kernel driver or not
mcgreg: as far as I know my laptop has blutooth but neither lscpi or lsusb finds any hardware .. wtf
mcgreg: even thge kernel does load some bluetooth klernel modules but all toollsd say there is no device
nha: do you have a bios/hardware bluetooth switch? maybe that could have some effect
mcgreg: as far as I looked into it, all is enabled
mcgreg: I'll check ubuntu ...
paranoid_android: seem to be a few minor rendering issues with blender not rendering some points and stippling
EruditeHermit: morning MrCooper
nanonyme: MrCooper: Btw, been meaning to ask: Mr Cooper as in Twin Peaks?
MrCooper: yeah, that's one reason :)
paranoid_android: is it possible with mesa to override things like anti-aliasing / texture filtering like you can with the binary ati/nvidia drivers?
nha: use the driconf application to look at configurable settings
paranoid_android: ah cool
nanonyme: nha: Hmm, are the settings that are initially in driconf really the ones that are being used by the system or just driconf defaults?
nanonyme: Just wondering since default TCL mode is "bypass the TCL pipeline with state-based blah blah"
nha: they're supposed to be the default settings from the driver
nanonyme: Is TCL pipeline that bad then? :)
nanonyme: would've assumed hardware TCL would've been the default
nha: it is
nha: it's possible that that particular driconf setting isn't handled correctly
nanonyme: just came to think we graphics users are probably just horrible: be it corruption fixes or performance tweaks, we're pretty much insatiable :p
nha: well, this kind of thing really *should* be fixed
nha: on the other hand, I (and I'm sure this applies to other people as well) am bad at development context switches, and the salivating-factor for GLSL is clearly higher ;)
nanonyme: I'm not drooling so much after GLSL atm.... Mostly the only place where it would be especially useful for me would be Adobe Flash. :p
osiris_: agd5f: thanks for the extended FS registers guide
mcgreg: man .. I even did some risky bios update .. still I dont see any bluetooth stuff :/
EruditeHermit: nha: +1 GLSL
hifi: RS690 and KMS works about fine for xv playback, only thing that bothered me was occasional "shadow frames" flashed during the playback
hifi: looked like a vsync bug
osiris_: nha: we've got a problem
osiris_: nha: in sauerbraten game we run out of free tex coords for rewriteFog
osiris_: nha: we could probably stuff the X component in one of the tex coords, but I'm not sure it will work for all cases
nha: I've never seen that
nha: which level / what quality settings?
osiris_: nha: see http://bugs.freedesktop.org/show_bug.cgi?id=22741
osiris_: nha: fortunately running it under kms doesn't cause a lockup here
osiris_: nha: but with current master I get Don't know how to satisfy InputsRead=0x00000001
dileX: trying a 31-rc8 kernel with pkgs from debian/sid. got error "(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch." which pkg (libdrm, mesa, ddx) has/have to be upgraded?
osiris_: nha: we could stuff the WPOS attribute too, but with GLSL it will get nasty
nha: osiris_: that's an incredibly crappy situation; stuffing into colors didn't work due to clamping?
osiris_: nha: yes
nha: stuffing could be "interesting"
osiris_: yeah, for WPOS we would need 2 2d texcoords
MrCooper: dileX: you need to rebuild libdrm with --enable-radeon-experimental-api and build xf86-video-ati Git against that
osiris_: actually r500 can handle up to 10 texcoords
osiris_: we just doesn't support it yet
osiris_: that would require some major changes in shaders handling
nha: oh, Mesa's internal limits?
osiris_: we would have to handle attribute just like gallium does
nha: so then let's just do it in Gallium ;)
osiris_: we would have to map all the standard attributes to generic, and store which one needs clamping, which one needs cylindrical wrapping etc
osiris_: we need it for GLSL anyway
nha: why not leave it up to gallium then?
nha: maybe we can hack around that problem in Sauerbraten for classic mesa
dileX: MrCooper: damn. you are right.
dileX: MrCooper: trying a debian-kernel with "new" radeonkms-featureset enabled on my old T40 (r200) with official debian/sid pkgs.
osiris_: nha: we need to rewrite attribute handling for GLSL, so adding a proper attribute mapping for classic mesa wouldn't be a problem then
MrCooper: osiris_: I share nha's concern about duplicating things Gallium takes care of in classic
suokko: MrCooper: Copy code from gallium ;)
suokko: (I didn't read the log)
MrCooper: that's duplicating
MrCooper: reducing copy'n'pasting was one goal for Gallium
suokko: But we still need mesa 7.6 with working driver that isn't any worse than before rewrite
MrCooper: this was about GLSL
nha: suokko: I don't think shader handling was affected by rewrite; there were some changes to how fog is handled, but fog was broken before
osiris_: MrCooper: there won't be much to duplicate, and we need that code if we want GLSL for classic mesa anyway
suokko: ok :) Then I agree. Can we get r300g to working state for mesa 7.7?
MrCooper: well, that's the question, isn't it
MrCooper: don't see why not if more people help
nha: another point to consider is that GLSL is probably not worth it without OpenGL 2.0 support
nha: and for OpenGL 2.0, there are more missing extensions
MrCooper: which Gallium should give us more or less for free
osiris_: nha: hmm, I though we just need GLSL and ARB_point_sprites
nha: also texture_non_power_of_two and draw_buffers
suokko: dileX: You will need to rebuild mesa too for 3D support
suokko: dileX: And r200 won't run well unless mesa source was max a week ago
dileX: suokko: I hoped to not hear that :-)
suokko: dileX: If you aren't too much against using Ubuntu packages (They are made to work with Debian testing) you could use xorg-edgers packages that provide fairly good 2D and 3D for r200 now.
dileX: suokko: thanks. I am maintaining a reduced pkg-xorg with xorg-server from GIT (all debianized). but the T40 machine is a "stable" one ;-)
suokko: Too bad KMS is not even "stable" yet
MrCooper: osiris_: we should draw a line somewhere - otherwise if we do 2.0 for classic, why not 2.1? ... - and GLSL seems to make sense for a line?
osiris_: MrCooper: the shader compiler for gallium and classic mesa r300 drivers is common, and that's where 90% of work is needed for GLSL.
osiris_: MrCooper: so I don't think that is the proper border line
suokko: Does classic mesa have any support for GLSL for hw drivers?
suokko: I was just thinking that it could use code from swrast
suokko: And pass that data to shader compiler
osiris_: in mesa core, GLSL and ARB_vp/fp share common framework. adding GLSL support is mostly a matter of supporting new instructions
suokko: But if you can find easy way to add support for GLSL then I'm not against it. That would at least enable some eye candy.
glisse: bugzilla is down ?
suokko: https at least works
nanonyme: suokko: Maybe the core of it all being whether he can find a way that is easy enough for him to implement it himself without getting bored and giving up. ;)
suokko: nanonyme: Or core code is not too buggy and only working with swrast ;)
nanonyme: Since I doubt anyone would care enough of classic Mesa to continue the work if he gave up.
nanonyme: I was talking core of the issue, not core of the code, mind.
nanonyme: Anyway, isn't softpipe already supposed to be superior to swrast? ;)
nanonyme: (or llvmpipe at the very least)
suokko: But classic mesa has only swrast using the glsl implementation
nanonyme: Hum, the current plan is to have a partially capable Gallium3D driver for r200, full for r300 and higher and none for r100?
nanonyme: That's the impression I get from radeon feature matrix.
suokko: nanonyme: You could fix it so that r200 is not planed
suokko: Even tough it could be done
nanonyme: Oh, someone wrote a feature dependency tree. How cute. ;)
nanonyme: Actually it's a bit wrong.
nanonyme: Since aren't TV-out and Display port gonna be implemented on top of KMS too?
suokko: TV-out works without too
nanonyme: It does but is anyone going to bother fixing quirks at this point anymore?
tilman: penumbra/overture is segfaulting for me with master in radeon_buffer_objects.c:112. radeon_bo_open returned NULL
tilman: that function succeeded a lot of times before, but when it dies the requested size is much larger than before i think (~600k). this is with an r420 fwiw
nanonyme: Got the latest git?
tilman: this is da1248bee5471f8da2277118a23b53d308721fca
nanonyme: Is this KMS or without?
suokko: tilman: What is requesting 600k page?
suokko: tilman: Do you have back trace?
MrCooper: 600K BO, not page
tilman: nanonyme: without kms
suokko: ok bo :)
nanonyme: libdrm_radeon or the old one? ;) (there's two versions of that function, me thinks)
tilman: vanilla libdrm 2.4.13, linux 2.6.30
suokko: I love this verbose error message "make: *** No rule to make target `depend', needed by `default'. Stop."
tilman: i've got the stable stack, except mesa from master :]
nanonyme: Well, Mesa from master is the only thing you should be using anyway afaik. :3
nanonyme: It pretty much just seems to return bom->funcs->bo_open(bom, handle, size, alignment, domains, flags);
tilman: i guess it's the DRM_IOCTL_GEM_OPEN ioctl that failed, since i didn't see the 'failed to allocate' message
tilman: nanonyme: yes, which is bo_open in radeon_*_gem.c i think
nanonyme: Erm, shouldn't it be using userspace memory management without KMS?
Dr_Jakob: suokko: sudo apt-get install makedepend
suokko: Dr_Jakob: which makedepend = /usr/bin/makedepend
Dr_Jakob: suokko: then I don't know..
MrCooper: suokko: IME it can mean one of the source files can't be read
nanonyme: It trying to do ioctl's at all sounds like I'm missing something.
MrCooper: I agree the error is unusable, I suspect it's a make bug
suokko: Dr_Jakob: i know that I caused some error in Makefile but that error message doesn't help at all
tilman: nanonyme: i'm just guessing. i don't see another implementation of the bom...
Dr_Jakob: suokko: what MrCooper says ^^ its a missing C file...
nanonyme: tilman: Could be a broken non-KMS implementation. :/
tilman: there's radeon_bo_legacy.c in mesa
MrCooper: tilman: yeah, no GEM without KMS
tilman: i wondered a little why vbo were working now even without proper kernel mm ;)
nanonyme: Yes and it pulls in eg radeon_bo_open from radeon_bo_drm.h.
nanonyme: (or rather probably radeon_bocs_wrapper.h does pull it in)
suokko: "radeon_debug.c \" -> "radeon_debug.c\" fixed it :/
MrCooper: and radeon_debug.c is there according to file?
suokko: yes. I just created it
suokko: Now I put space back and it works!?
dileX: suokko: thx for latest commit. just needed it.
MrCooper: suokko: maybe there was no space before but some other non-printable character which make considered part of the filename
suokko: maybe. But I don't know which of my keys would cause
dileX: (radeon: Fix DRI2BufferPtr to be DRI2Buffer2Ptr for xserver 1.6.)
MrCooper: suokko: or maybe your computer is cursed ;)
suokko: MrCooper: maybe it needs pension
suokko: Or maybe it is some bug in vi
nanonyme: Yeah, suokko's solution was pretty neat.
nanonyme: At least the error should probably come from the right place if it fails. :3
dileX: interesting: if I have VGA=791 in my grub-cmd-line then I get "fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver" and radeonkms shows black screen in init-3. *not* adding VGA argument and enter init-3. load radeon-module with modeset=1 works.
mjg59: dileX: Don't pass vga=
dileX: mjg59: made my experience :-)
dileX: unfortunately, modeset=1 as grub-cmd-line is accepted as arg, but does not work (radeon.modeset=1 as arg not valid). any idea?
dileX: not work = no kms-enabled console (init-3)
nanonyme: Do you have fbcon compiled?
dileX: of course
dileX: yepp, in-built
chithead: dileX: radeon.modeset=1 only works if radeon drm is compiled in
nanonyme: And kernel modesetting enabled from staging?
nanonyme: Oh, didn't know that. *sigh*
chithead: if you have a module put option foo.. in modules.d, modprobe.d or however it is called on your distro
dileX: nanonyme: hehe. I said it works, logged in init-3. loading radeon-module with modeset=1
dileX: chithead: its compiled in. here nomodeset and modeset=1 work
dileX: chithead: radeon.modeset=1 had never worked here
nanonyme: Well, it should be defaulting to 1 anyway with stock 2.6.31.
MrCooper: chithead: no, it works for modules as well
dileX: maybe, its distro-specific or build-from-vanilla-source related
nanonyme: Well, some distros change the defaults. :)
MrCooper: but radeon.modeset is only available if radeon KMS support is enabled at build time
nanonyme: Iirc at least Ubuntu did.
nanonyme: Fedora defaults to KMS on like vanilla anyway.
dileX: MrCooper: you mean CONFIG_DRM_RADEON=y ?
nanonyme: dileX: I'd assume he means the staging option.
dileX: MrCooper: CONFIG_DRM_RADEON_KMS=y
MrCooper: dileX: put up dmesg for us to look at
dileX: MrCooper: wait, reboot the r200-machine and boot with modeset=1 (init-3)
MrCooper: no sign of the drm or radeon kernel modules?
dileX: its *not* loaded with modeset=1 as grub-cmd-line
dileX: I do now
MrCooper: looks good...
dileX: hmm, but why is "modeset=1" in grub-cmd-line not doing this at boot-time?
dileX: on r500 machine its OK
nanonyme: You mean radeon.modeset=1?
MrCooper: doing what? A kernel command line option doesn't magically load a module
nanonyme: Since telling radeon modeset=1 is the same as telling kernel radeon.modeset=1. ^^
dileX: MrCooper: modeset=1 is "changing" console while booting
dileX: on r200 its grub-1, on r500 its grub-2 <--- ?
MrCooper: if radeon is built into the kernel, or maybe in the initrd
dileX: MrCooper: thats an argument. I inspect the initrd.img files
BirnenSchnitzel: Hi, is anyone of the radeon main developers present?
MrCooper: dileX: and the CONFIG_DRM_RADEON* values are identical between the kernels?
dileX: MrCooper: its the same kernel
MrCooper: something doesn't seem to add up though; loading the kernel module manually fixed the problem, but it can't be built into the kernel and as a module at the same time
nha: If there is somebody with an R300 or R400 who could have a quick test with my branch git://anongit.freedesktop.org/~nh/mesa r300-compiler, I would appreciate it
nha: that's a gigantic patch, but all it does is remove the remaining Mesa dependencies from the shader compiler
nanonyme: If git no longer has a revdep problem for PPC on Rawhide, I could try it with rv350.
nha: or rather, that's all it *should* do, and I'm giving you advance warning to allow regression tests
nanonyme: Does it matter that I don't have a working KMS?
nha: not at all
nanonyme: Right. Will see if I can get git then.
nanonyme: The system is a tad volatile due to it being non-x86 so can't promise anything. :/
nha: don't sweat it
nanonyme: Seems like I'll get KMS for all my machines at latest by Fedora 13. Yay. :)
paranoid_android: what gpu is on an X1550 ?
nha: some R500 variant
paranoid_android: ah ok
marvin24_: nha: can you suggest a test?
nanonyme: nha: Btw, which chipsets share a common compiler?
nha: marvin24: if you could run piglit, that would be great (feel free to limit glean to just a single rgba visual with depth+stencil if it takes too long)
nha: nanonyme: R300-R500 all share some things in common, but not everything
nha: nanonyme: they use a shared codebase, but use slightly different paths
suokko: nha: Maybe we should fix piglit so it doesn't have so much compile problems
nha: suokko: what compile problems are there?
suokko: has some hacks to make it compile
suokko: nha: I have to use glew.h instead of glext.h
suokko: And then there is some missing function declarations
suokko: ext.h is hopeless
nha: ah! yeah, feel free to submit patches that convert things to using glew
suokko: glext.h that is
suokko: nha: btw, Should glew had typedef for GLhalfFloat?
suokko: That is one of thing that was missing from glew
nha: well, if it exists in glext.h it should exist in glew
suokko: What about missing function defines in glew? I guess they should exists too
nha: after all, the whole point of glew is to make GL extensions accessible
marvin24_: nha: also compile problems here
nha: marvin24: damn :/ well, if you can't get them sorted out, just try running interesting (for you) apps that use opengl
suokko: marvin24_: You can try this patch http://nopaste.com/p/aB5YVcE4K It is for commit 4f9b764c77251e152845513bbaeffc83bf487708 if not applying to current version
marvin24: suokko: mmh, does neither apply on 4f9b764c77251e152845513bbaeffc83bf487708 nor master
suokko: I did create that with git diff :/
marvin24: wonders what the test is about
nha: piglit tests a lot of different opengl functions automatically
nha: usually, when you change the driver, you don't really have any assurance that everything will still work fine, because if you just test, say, compiz + openarena or some other arbitrary app, you only test a very small subset of what opengl offers
marvin24: suokko: my fault (html inside)
nha: by automatically testing a broader set of functionality, one reduces the chance of stupid mistakes
suokko: yes. You should add /txt to the link to get pure text version :)
suokko: (Or I should do that) :)
marvin24: and lspci in user search path ...
suokko: Is that required too? Maybe cmake should check for it :)
marvin24_: the initial test fails
nha: ah, the dependency on lspci should be optional
marvin24_: I did PATH=$PATH:/sbin ./piglit
marvin24_: some tests fail, rest warns only
nha: some failures are unfortunately normal
marvin24_: seem that the warning are generated by the standard libGL output (like optimizations, dxtn, 3dnow)
suokko: It assumes that gl doesn't output anything to stderr
suokko: And it should unless you have LIBGL_DEBUG=verbose set
hifi: hm, openitg is surprisingly slow on X1200
marvin24_: I think a debug build is sufficient
marvin24_: and everyone builds with debug ...
nha: that's odd, because I don't get those warnings
suokko: I don't get them either and I have debug symbols enabled
marvin24_: does glxinfo /dev/null gives some output?
marvin24_: should be >/dev/null
nanonyme: hopes the software texture compression patent holders get very painful hemorrhoids for the rest of their life for not making an exception for Mesa...
suokko: nothing for me
marvin24_: are you running on x86_64 or i686?
marvin24_: ok - 64bit here, so maybe time for another patch
marvin24_: seems my remote machine has softlocked
marvin24_: could also be related to vnc (don't panic)
marvin24_: loves dualcore
suokko: You would need irc bot running there and check if that irc bot stays connected or not ;)
marvin24_: /whois marvin
marvin24_: add 24
marvin24_: Xorg runs at 100%
marvin24_: the last test was blendfunc
suokko: nha: see above
suokko: marvin24_: Sounds like gpu hang
suokko: So you will need to restart machine to use in opengl any more. (But first should try to get some debug info if it is possible)
marvin24_: I can still login
marvin24_: but gdb --pid `pidof Xorg`gives me nothing
suokko: It is blocked in kernel space
marvin24_: sysrq-t shows that glean hangs in a drm_lock
suokko: and xorg is in same lock
suokko: Can you find out what else is holding drm lock?
osiris_: nha: is there a way to make piglit run glean tests only for few visuals? (full regression test for all visuals is taking way too long on KMS)
suokko: I don't know. you might want to look applications blocked in kernel space
marvin24_: could also be related to radeonhd ...
marvin24_: hides ashamed in a corner
suokko: osiris_: You have to put cpufreq to powersave and run it over night ;)
osiris_: hehe :)
suokko: for me it took 14984.8060279 seconds ... That means over 4 hours
nha: marvin24: my changes really shouldn't cause any new lockups... can you see if the problem occurs with master as well?
nha: osiris_: GleanTest.globalParams += [ '--visuals', 'id==0xc4' ]
nha: (in the .tests file)
nha: I think glean can also select visuals based on characteristics like RGBA, depth, stencil etc.
nha: that would be needed for a general implementation
marvin24_: nha: I blame radeonhd and/or vnc for now
marvin24_: nha: will rerun with radeon and quit vnc
nanonyme: marvin24_: Tried radeon driver? :)
SimpleAONE: anyone has knowledge in regard to DVI and m9 ?
suokko: Is that typo?
SimpleAONE: were ?
suokko: I guess no :)
SimpleAONE: M9 is Radeon Mobility m9 ofcourse :)
suokko: I don't have dvi connector ;)
suokko: SimpleAONE: if you have problem it is bestto say the problem and put your xorg.log to pastebin
suokko: nanonyme: ping
nanonyme: suokko: pon
suokko: Can you test http://cgit.freedesktop.org/~suokko/mesa/log/?h=radeon_debug with r600?
suokko: (git clone --reference)
Arc: im having a scan problem with my rV350 (Mobility Radeon 9600 M10) svideo out - the scanrate seems off since the tv makes a high pitch squeel and the grey screen that normally reads "unusable signal" flickers
airlied: nha: texture_non_power_of_two has a workaround that ati/nvidia binaries use
airlied: they advertise 2.0 but don't advertise the extension
Arc: i currently have in the Device section:
Arc: Option "ForceTVOut" "on"
Arc: Option "TVDACLoadDetect" "TRUE"
Arc: Option "TVStandard" "ntsc"
koolfy: Hey, I'm gonna buy a new PC, what would be the best compromise between power and OS driver support and reliability ? (what chipset/card)
airlied: nha: game devs understand this to mean they can use npot tex coords but mipmapping won't work preply
airlied: which pretty much marchse the r300/500 hw
Arc: its almost as if my system is stuck in pal mode
Arc: or some other frequency mismatch
glisse: airlied: btw i think i found the issue with r4xx need to test tomorrow but this gonna look very ugly
glisse: seems that x86 bios patch atombios reg write and do extra stuff on some regwrite to correct buggy atombios :(
airlied: glisse: that doesn't surprise me on r5xx
airlied: r5xx even
airlied: damn r4xx even ;)
glisse: well it means i need special atombios reg callback for r4xx :(
glisse: anyway i am not sure it will be enough
airlied: can you not patch it up afterwards?
glisse: i need to test and i am just too tired of looking as bios dump
airlied: like we only should use atom for asic init
airlied: on r4xx
nanonyme: airlied: Are you gonna please push the PPC fixes for Fedora 12's kernel still? :)
airlied: nanonyme: which ppc fixes?
glisse: could do that but anyway adding 4 functions for r4xx doesn't sounds that bad
glisse: anyway zzzzZZZZZzzzz
nanonyme: Well, MrCooper said KMS works for him (iirc stock Fedora kernel) but it doesn't work for me with Rawhide kernel. Iirc exactly the same hardware.
airlied: I wasn't really planning on kms on ppc until the suspend/resume code is written
nanonyme: Erm, stock Linus kernel even.
nanonyme: Ah, right.
airlied: since it would break people using radeonfb on old mac laptops
Arc: hey guys, help on radeon tvout?
nanonyme: Right... Just wondering since I was hearing of KMS itself working.
nanonyme: But yeah, suspend/resume not working sounds like a good reason. I'll wait.
airlied: nanonyme: yeah it works, though I think some patches are in the ppc tree yet
nanonyme: Hmm, right...
Arc: by changing "ntsc" to "NTSC" i got it to work, but now it's black nad white only
Arc: is there something that needs to be done to enable color?
chithead: no color in tv-out is often tv standard mismatch. your tv surely is ntsc?
Arc: i am in the US
Arc: (II) RADEON(0): Default TV standard: PAL
Arc: (II) RADEON(0): TV standards supported by chip: NTSC PAL PAL-M
Arc: (EE) RADEON(0): Invalid TV Standard: NTSC
nanonyme: Arc: Err, iirc it should be explicitly lower-case.
nanonyme: Upper-case doesn't work at all.
Arc: so "ntsc" was the correct option, but when its "ntsc" it just flickers, while when it defaults to pal i get black and white
nanonyme: The default is actually ntsc iirc.
Arc: ok that will flicker with the text "unusable signal" on the tv
nanonyme: Try telling it pal or pal-m?
kkk: in my opinion ntsc is b&w, and pal flickers
nanonyme: Pal-m is close to ntsc but not quite.
nanonyme: Some funny guys decided to make a standard which has the word pal in it but is incompatible with it. :p
chithead: ntsc has bad connotation outside the us, nobody wants it
nanonyme: Arc: Anyway. Ntsc is the default and only lower-case values work.
Arc: pal-m gives b/w as well
nanonyme: Tried pal?
tzaeru: hm, wonder if there's been any progress with that library which is ought to grand GLSL support..
nanonyme: Oh, wait a minute....
nanonyme: That can't be the default it's pulling from the switch. o.O
nanonyme: Unless there's been changes. Hrm.
nanonyme: Ahh, stupid me.
nanonyme: It's rv350. >.<
Arc: confirmed, "ntsc" just flickers, "pal" and "pal-m" give a cut-off greyscale view
suokko: Arc: Can you post your xorg.log?
nanonyme: So not one of those AtomBIOS-based chips at all. :(
suokko: Just in case someone who knows about tv-out happens to come
Arc: nanonyme: me?
Arc: suokko: post to where?
nanonyme: Arc: Yeah. Ignore what I said before, that was just related to AtomBIOS TV out.
suokko: wonders if 800x600 is right resolution to begin with
Arc: ive tried others, with modelines, but xrandr doesnt seem to accept them
airlied: try NTSC instead of ntsc
nanonyme: I think he said he did.
airlied: forgets how it works
chithead: was already tried, resultet in pal
Arc: we've tried a lot. this is going on day 5
airlied: tv-out is usually works or fails, when fails we are geenerally lost
nanonyme: knows for sure it's lower-case in AtomBIOS TV out, no idea about non-AtomBIOS
embraceunity: I hear FreeBSD is switching to clang, does anyone know if building Mesa itself and the radeon driver with clang would have any noticeable speed up? I know clang and LLVM and being implemented for shaders, but I thought it might help if everything were compiled with it.
airlied: ah they are all lowercase
nanonyme: airlied: It's a bit inconsistent though that the X server outputs them in upper case. ;)
airlied: embraceunity: doubtful
embraceunity: ad, damn
airlied: nanonyme: yeah shold probably lower case the outputs
airlied: ah the manpage is correct
airlied: which is really the reference
Arc: what if, the port supports both svideo and standard video, and its defaulting to standard video so the clock is wrong
airlied: doesn't look like it shares the DAC with anything
Arc: im playnig a movie in pal mode right now, its b/w, and its cut off on the bottom, but is flicker free
suokko: I have some improvements to debug output code in my local branch at http://cgit.freedesktop.org/~suokko/mesa/tree/src/mesa/drivers/dri/radeon/radeon_debug.h?h=radeon_debug What I have missed there? Maybe scoping to add indention to output?
MrCooper: nanonyme: not sure why you think I run a Fedora kernel...
MrCooper: airlied, nha: with Gallium maybe we could also handle any missing ARB_npot features in the fragment shader
nanonyme: Mental note: when doing corrections, also include the name of the guy in the correction who you mentioned in the original wrong statement.
suokko: Have anyone noticed that firefox has huge impact on 3D performance. About 10% fps drop is what I see. (DRI2 windowed)
airlied: probably sucking cpu
airlied: and/or gpu
suokko: And it also has huge number of buffer objects allocated all the time
suokko: And it also can kill laptop battery life because I see it using only a few ms timer all the time in powetop.
meoblast001: where do you get the firmware the topic speaks of
meoblast001: the microcode
airlied: you have it unless your distro puts it somewhere else
airlied: in which case ask your distro
meoblast001: i use the Linux Libre kernel
meoblast001: i compiled it
meoblast001: my distro doesn't come with LinuxLibre
airlied: then you'll have to talk to them
airlied: we don't ship the firmware outside the kernel
meoblast001: looks like i'm staying 2D than
MostAwesomeDude: meoblast001: gNewSense and any other distro based on its package selection will *not* be useable, and we can't really support it since they've patched large amounts of our code out.
airlied: the firmware files will stealable at least in newer kernels
meoblast001: MostAwesomeDude: you work at ATI?
airlied: since I've applied the debian patch to make them separate
MostAwesomeDude: meoblast001: No, I'm talking as a member of Xorg.
meoblast001: i need to find that ATI employee i talked to
meoblast001: so i can figure out why the hell they don't want us knowing what's in the firmware
airlied: we do know whats in it
airlied: we don't have a compiler for it
MostAwesomeDude: meoblast001: From Linux Libre's release notes: "disable Radeon, R128 and MGA gpu drivers again, as in gen1.
MostAwesomeDude: Linux-libre radeon driver just doesn't work without firmware, breaking
airlied: and really its not useful
MostAwesomeDude: the Xorg radeon driver. Not having the kernel driver actually enables
MostAwesomeDude: the X driver to work, at least to some extent.
meoblast001: airlied: hex dumps aren't readable though :/
chithead: and as the three distros amd cares about are fine with the current situation, they see no reason for change
airlied: well now they can at least enabled the drivers with drm-next
meoblast001: MostAwesomeDude: so mine still works, just really slow?
meoblast001: bridgman: hi
meoblast001: you work at ATI right?
meoblast001: i think that was you
meoblast001: why is ATI holding back on us with firmware?
bridgman: I guess there's two parts to the answer
bridgman: one is that it's part of the hardware, not part of the driver, and we don't give out any hardware design information
meoblast001: the reason i want an answer is because i just bought an ATI card to realize it won't work with my system
bridgman: it's not like there's a general purpose processor in there running part of the driver
bridgman: which GPU do you have ?
meoblast001: only thing i like about it is it's quieter than my NVIDIA
meoblast001: besides that i want to get rid of it
airlied: the nvidia needs non-free stuff as well
bridgman: that's part of the 5xx family; it probably could give you 3d without microcode but it's a lot of development work with no obvious benefit
meoblast001: yes it does
meoblast001: but i already had that... i dished out an extra 14 bucks for this ATI
airlied: I think we already worked out you can't buy a discrete gpu that doesn't need some firmware
chithead: meoblast001: get an r100 card, these don't need firmware iirc
airlied: or non-free bit
bridgman: so why doesn't anyone have a problem with CPU microcode ? The CPU won't work without it either ?
meoblast001: well, it requires me to get a whole new kernel
meoblast001: i use a kernel that is stripped of hex dumps
bridgman: even r100 needs firmware AFAIK; everything from r128 has loadable microcode
bridgman: before that it was burned on chip
bridgman: didn't you just replace your kernel with one that didn't have the microcode ?
airlied: ouch it hurts when I do this
meoblast001: no, i used LinuxLibre for some time
bridgman: why do you use a kernel that is stripped of hex dumps ?
meoblast001: a few months now
meoblast001: hex dumps are unreadable by programmers
meoblast001: and cannot be studied or modified
chithead: meoblast001: if you want a system that does not require proprietary firmware, your choice is very limited. get a lemote yeelong
bridgman: microcode burned onto the chip is unreadable by programmers, and can not be studied or modified either
bridgman: why does everyone think that is somehow better - just because you don't have to think about it ?
chithead: bridgman: but linuxlibre or debian etc. do not ship it
meoblast001: yes, but when my OS has to send it to the hardware, we have a second problem
airlied: bridgman: its religion
bridgman: it's like putting your thumb over the oil light on the car dashboard; it's still there, you just feel better 'cause you can't see it ;)
meoblast001: i now have to get every firmware under the sun just to get 1 card to work
airlied: bridgman: it doesn't make sense
chithead: bridgman: from user perspective it does not make a difference, from distributor it does
bridgman: please don't tell me they strip out the CPU microcode updates and run with security holes
airlied: bridgman: see not sane
meoblast001: bridgman: are you guys afraid NVIDIA is going to use your information?
bridgman: not the microcode anyways
bridgman: it's real simple; if we start giving out horizontal microcode it's like giving out other parts of the internal hardware design; it makes the GPU less secure and we can't sell into ~99% of our market unless we keep it secure
bridgman: what do you do about CPU microcode ?
MostAwesomeDude: meoblast001: Your CPU is, guaranteed, a microcode CPU. It loads a block of microcode from a burned chip, and it can, with a proper kernel driver, load updated microcode.
MostAwesomeDude: This microcode is compeltely and totally indecipherable to us.
MostAwesomeDude: But if you don't have it, you could have security holes, random crashes, and other bad things.
meoblast001: yes, but it is burned into the chip, it doesn't create issues for me because it is directly in the hardware
MostAwesomeDude: Now s/CPU/GPU/g and re-read.
meoblast001: the firmware for the x1300 is burned in?
MostAwesomeDude: The GPU's default state isn't very useful; we load a bunch of ucode so that we can do fun things with it, like fast 2D and 3D.
meoblast001: than why isn't it using it?
MostAwesomeDude: Because the stuff that's on the card by default doesn't actually do anything? :3
bridgman: meoblast001; no, the kernel updates the microcode; you really don't want to lose the CPU microcode updates
meoblast001: idk, the FSFLA manages the kernel
MostAwesomeDude: meoblast001: I read their page. They've done some pretty bad things in the name of freedom.
meoblast001: things like?
MostAwesomeDude: No CPU microcode updates. Off the top of my head, Intel and Transmeta, (and probably the others) have known flaws in default microcode.
meoblast001: i want one of those MIPS CPUs
MostAwesomeDude: Um, no microcode for Ethernet controllers is going to suck balls because you can't get DMA.
meoblast001: but hey, at least my CPU works
bridgman: MIPS cpus are microcoded
meoblast001: not the one i heard of, the one RMS uses
MostAwesomeDude: If you want something with no ucode, try an ARM.
MostAwesomeDude: Except of course you're going to need a ucode Xloader to even boot the thing.
MostAwesomeDude: And then another ucode in the U-boot to get Linux loaded.
bridgman: sorry, they're microcoded too - the microcode is just burned into the chip so you don't have to think about it; but you can't stuy it, you can't modify it, etc.
MostAwesomeDude: And another ucode for your Ethernet controller.
MostAwesomeDude: And ARMs with GPUs usually have SGX! Those aren't open at all! No docs, no ucode, nothing!
bridgman: I really don't understand why FSF isn't drawing a line between horizontal and vertical microcode
bridgman: the fsfla site has a lot of information about the penguin with the bath brush but not very much about microcode ;(
bridgman: MIPS CPUs actually have a *lot* of microcode, and the recent ones even more so, since they've added microcode to help emulate X86 opcodes
meoblast001: i want something with free microcode or none at all
bridgman: maybe a SPARC ?
meoblast001: i suppose
bridgman: nearly all modern computer hardware is heavily microcoded
meoblast001: aren't those expensive though?
meoblast001: do SPARC systems have free microcode?
bridgman: even the hardware design is open source
MostAwesomeDude: meoblast001: Careful with that statement; you may find yourself without a computer. :3
chithead: sun published sparc cpu design and openfirmware under open source licenses
bridgman: I don't think CPARC cpus need microcode, checking now
meoblast001: hm, i'm liking this idea
meoblast001: maybe i should research it
meoblast001: if possible, my next system might be a SPARC
meoblast001: i don't know a lot about SPARC though
MostAwesomeDude: Well, what video card will you use?
meoblast001: i didn't say i'm going all free, that's impossibl
meoblast001: as free as i can get
MostAwesomeDude: You could probably find an old trident; I don't think those have ucode.
MostAwesomeDude: I mean, as long as you're going back to 1992.
meoblast001: i really don't mind using the firmwares for the time being
MostAwesomeDude: Or even better, a NeoMagic.
meoblast001: i just don't want to get all the firmwares for every nonfree device in existance
bridgman: the ATI GPUs before Rage 128 didn't use microcode, so that takes you up to ~1999
bridgman: the tricky thing is that most chips have micorocode burned into the hardware; it's going to be very hard to avoid that without going back a decade or so
bridgman: nearly all hardware vendors use microcode these days; it's just one more way to help deal with the ever-growing complexity
bridgman: so some of what would have been hardware gets implemented as microcode
bridgman: I just don't see how that makes it suddenly bad
meoblast001: can i use ATI microcode without downloading firmwares for everything?
bridgman: probably tweaking the drm source and building it
bridgman: by default I think the microcode is built into the drm binary
bridgman: so you could just tweak the source to only include and only reference the header files for the GPU you want
bridgman: in the meantime you should be able to get XAA acceleration without microcode; some of the EXA functions use the 3D engine and I don't think the driver will do that without microcode today
meoblast001: bridgman: how do i use XAA acceleration
meoblast001: i currently use the radeon driver and i'm told it fails to load
meoblast001: i only need my card to develop simple games, i do not need any fast acceleration
meoblast001: the speed of a year 2000 card should do the trick
bridgman: put Option "AccelMethod" "XAA" in the Device section of your xorg.conf file
meoblast001: brb have to restart xorg
bridgman: I don't remember of the stripped kernels return a fail when initializing the drm (which would be OK) or if they initialize but don't load the microcode (which would be bad IIRC)
bridgman: You might also need Option "DRI" "off" but I think that disables acceleration completely
meoblast001: bridgman: i tried running neverball and it ran as slow as last time i tried it
bridgman: neverball is 3D, isn't it ?
meoblast001: (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
bridgman: if you want to run 3d I *think* your best bet would be to use the radeonhd driver and set Option "AccelMethod" "shadowfb"
bridgman: XAA is only 2D; you need microcode for 3D with the current drivers
meoblast001: what does that do?
meoblast001: isn't it Driver "radeonhd" under the Device section?
bridgman: that moves the primary copy of the framebuffer into system memory and does all the drawing in software
bridgman: it's a big slower for 2D but should be faster for 3D
meoblast001: i suppose i could do the judging of whether or not i like it :P
meoblast001: time to restart xorg.. or if it messes up again, my whole system
bridgman: yes, you would need Driver "radeonhd", but you would also need to make sure you had the actual driver as well
bridgman: putting the Driver
meoblast001: no speed change and my display was over on the right side of my monitor
bridgman: that was with radeonhd and option shadowfb ?
bridgman: hmmm - I would have expected Neverball to be a bit faster
meoblast001: i only need this to develop my game
meoblast001: but i suppose i could just run it at a slower speed
bridgman: some of the recent Gallium3D software rendering work might be useful, but I don't know enough about it yet to be sure
bridgman: MostAwesomeDude, have you played with any of the Gallium3D software renderers ? Anything faster than classic mesa swrast yet ?
airlied: I guess the llvmpipe one will be better at sw shaders
bridgman: time for a benchmark article ;)
bridgman: Unigine demo on llvmpipe vs the new MS software renderer
bridgman: vs a Rage Pro ;)
bridgman: actually benching them against IGPs might be interesting
soreau: bridgman: What's used for benchmarking?
bridgman: if the comparison were just different mesa/gallium flavours I guess the easiest would be to use PTS
benh: wonders if agd5f is around...
bridgman: I don't think including the MS software rasterizer or SwiftShader really makes sense, but if they were included then we'd need test apps which ran on both OpenGL and DX9
spstarr: hey bridgman
bridgman: hi spstarr
bridgman: how come it only rains on weekends ?
spstarr: just the pattern we're in :)
bridgman: that's what they said 30 years ago too ;)
spstarr: bridgman: I've given up looking for work til Fall
spstarr: summer is dead
benh: that's silly
benh: this 256M vram radeon only has 128M accessible via the PCIe BAR
benh: i wonder why the FW screws it up that way
benh: and it it's something I can write a little quirk to fix
benh: the bridge has a good 768M window open to it so there's room to grow
benh: (X1900 / R580 "mac" btw)
ajavid: I also have X1900XT
ajavid: I am using xorg 7.4, OpenGL renderer string: Mesa DRI R300 20060815 TCL
ajavid: does this driver support xv in linux?
ajavid: this guys told me xv is bad quality. use opengl! with sw yuv-rgb conversion.
soreau: ajavid: Yes it supports xv in linux
_moep_: ... if dont the one of theese bugs... :D
tkil: where's the best place to find the support status for radeon hd 3850 agp on linux?