glisse: marienz: so no lockup with agp patch ?
Nightwulf|work: hi all
dileX: anyone knows whats up with kernel.org?
dileX: $ git pull
dileX: fatal: The remote end hung up unexpectedly
edwin: glisse: what info do you need for RHBZ 582158?
glisse: edwin: i think airlied patch fix it
glisse: so i will wait until it hit some kernel for people to test
edwin: ok
edwin: its a minor issue :)
glisse: yeah minor
airlied: yeah its fixed alright
airlied: just need to push to F13
edwin: dileX: git pull on kernel.org works for me
glisse: airlied: btw we have firemv multi gpu bug yeah
edwin: glisse: in fact most bugs in radeon are either minor, or already fixed/workaround available :D
glisse: well there is still a bunch of bug with strange/broken monitor
glisse: and there is the never dying lockup bug
edwin: glisse: maybe 582166 is a normal bug
edwin: glisse: and what about the rendercheck failures, is it because the monitor went to dpms off during the test?
glisse: we also have a bunch of mesa bug but right now i consider then as low priority
glisse: i need to look into the rendertest thingy
glisse: i will rework my agp patch first
airlied: glisse: I have a firemv, it worked last time I tried it
airlied: or at least some of the outputs did
dileX: re
dileX: edwin: yay, working here now
edwin: airlied: does drm-radeon-testing/drm-linus contain new stuff vs 2.6.34-rc4, or should I just switch to 2.6.34-rc4?
dileX: [ 71.347298] [drm] Initialized radeon 2.3.0 20080528 for 0000:01:00.0 on minor 0
dileX: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blobdiff;f=drivers/gpu/drm/radeon/radeon_drv.c;h=4b05563d99e16335f729cd3b5fe5bcbff683669f;hp=055a51732dcb7b76a100d79ee2b642de9cc9eefe;hb=cae94b0ad9d147152af77b971a7234faf20027a9;hpb=f12eebb0acbaa6dcb60ed34451f5b159f509b2c0
dileX: airlied: whats with the date :-)? hardcoded?
airlied: dileX: yeah we are lay with dates
dileX: indeed: drivers/gpu/drm/radeon/radeon_drv.h:#define DRIVER_DATE "20080528"
airlied: dileX: no rc4 is older than d-r-t
airlied: lazy
dileX: grr, #define DRIVER_DATE "20080528"
dileX: damn irc-client
dileX: yeah, changes in two files radeon_drv.h and radeon_drv.c
dileX: last listed change in radeon_drv.h is "* 1.33- Add r6xx/r7xx const buffer support"
dileX: "add MSPOS + 3D texture + r500 VAP regs" missing?
paulk_: Hello ! I'm using Fedora 12 with the official kernel. But today I decided to user linux-libre, a completly free linux kernel version. But now, I'v got no 3D acceleration with my Radeon HD 4350.
paulk_: Does radeon requires a binary blob ?
soreau: Perhaps you need to install the firmware
MostAwesomeDude: /topic
paulk_: ok but this firmware is non-free ?
glisse: paulk_: fglrx likely replaced the free library
glisse: try force reinstall of mesa mesa-dri and mesa-dri-experimental package
glisse: well force reinstall all mesa package
mjr: sadly it is non-free
paulk_: ok
paulk_: Will I one day be able to run 3D without this non-free firmware ?
glisse: paulk_: unlikely if no one re it
glisse: note that we know what the firmware do
glisse: and there is nothing bad or evil in it
glisse: in fact one can do a driver without the firmware but i will be slow
paulk_: ok
paulk_: Anyway, 2D is still usable without the firmware
glisse: no 2d accel without firmware
paulk_: Yes, but I can still play videos…
paulk_: HD in fullscreen is so slow !
ghepeu: hi. any idea how i can debug broken tearing avoidance with dri2 on my rv370 card?
ghepeu: i tried bisecting mesa, but a version I know worked now is broken
glisse: maybe some change in the ddx
ghepeu: I'll try with xf86-video-ati. I just hope it is not the kernel. I hate bisecting the kernel.
oga: sent some patches that i've been discusing with agd5f for a while to the ati list.
airlied: oga: leaking the FB map on recycle might be a bigger deal than leaking the regs map
oga: the alternative is to know which order you're in and nuke it on the second drivers go through
apexo: about https://bugs.freedesktop.org/show_bug.cgi?id=27452 ... any information I can provide that might help track this down? I could also apply kernel patches (against 2.6.34-rc4, preferably) to test potential fixes ...
oga: however, right now it is just plain wrong
airlied: apexo: I don't suppose you'd be able to try drm-radeon-testing?
airlied: if you haven't, it has some edid parser fixes from ajax that might help (or might not)
airlied: oh you have those already ;-)
airlied: reads bugs
apexo: :D
apexo: I could have tried ... but git.kernel.org seems defunct ATM ...
apexo: but if you think I got those fixes ... well
apexo: currently running -rc3, are those fixes in -rc4?
apexo: then at least I'd have to restart :)
dileX: apexo: yay, again to be precisely
airlied: apexo: yeah 3a44d has them all
airlied: apexo: can you get the same log with the other card?
airlied: so boot exactly the same way with just the cards changed?
airlied: would be inclined to blame atombios_set_crtc_dtd_timing
apexo: so -rc4 got the same problem
apexo: I don't exchange cards, I only got the 5750 :)
airlied: its the only codepath thats realy different between the evergreen and previous cards
airlied: apexo: http://fpaste.org/15fy/raw/
kjeldahl_: Half a day without slowdowns today, dual-screen RV730, xorg-edgers on Ubuntu Lucid. Any big changes last few dates?
airlied: does that make any difference? I'm just guessing at this point
apexo: positive
apexo: we're now at 1924x1080
apexo: (up from 1922x1080) :)
apexo: so I guess -1 won't work^
airlied: okay so its an off by one in this function somewhere else then ;-)
ghepeu: d'oh. i reverted everything (xserver, ddx, mesa, kernel) to what I was using in january and tearing is still there. i don't know what to think, maybe I'm going mad
ghepeu: is anyone else having tearing problems wihth dri2?
ghepeu: (in compiz)
dileX: airlied: forgot to push "drm/radeon/kms: add FireMV 2400 PCI ID." or kernel.org's GIT problems :-)?
airlied: dileX: mirroring process
dileX: airlied: OK. last time I saw an old website layout w/o GIT tree's listed when gasping on k.o
airlied: apexo: can you attach the edid file from /sys/class/drm/card0-HDMI\ Type\ A-1 (or something like that)
airlied: to that bug
airlied: I'll see if I can take a look tomorrow, though feeling a flu coming on
soreau: sweet, sky works correctly in et now
soreau: textures look more vibrant and fluent it seems too
airlied: soreau: r300g?
soreau: airlied: Just looking at classic ATM
soreau: fires up the g
soreau: Works with gallium too just much slower
mjt: radeon 0000:01:05.0: DVI-D-1: EDID invalid.
mjt: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
mjt: there's _no_ monitor connected to DVI
ghepeu: is there a relation between the irq reported by radeon in /proc/interrupts and the vblank irq?
ghepeu: ok, I wrote a bash script who calculate roughly the increase/s of the interrupts reported in the 'PCI-MSI-edge radeon' line
apexo: airlied: done
ghepeu: with compiz and dri2 there are usually 2-6 interrupts per second
ghepeu: if I move a window around the number jumps to 250 or so, and I see tearing
ghepeu: if I enable the benchmark plugins the interrupts/s always stays at ~120 and there's no tearing moving the windows around
oga: airlied: if you think leaking the fb mapping would be worse (i'm inclined to agree)
oga: how about refcounting so instead of never unmapping we just refcount per driver instance and free when both unmap
MrCooper: ghepeu: maybe the benchmark plugin forces compiz to always render the whole screen instead of just incremental updates
ghepeu: MrCooper, and is that a bad or good thing? the tearing with dri2 is pretty much unbearable as it is now. even textured xv suffers from it, so I can't even watch videos
adamk: Yes, the benchmark plugin damages th the entire screen.
ghepeu: what is bugging me is that in january, when I first tested dri2, there wasn't tearing at all
MrCooper: ghepeu: do you get XVideo tearing even in fullscreen, and do you have 'unredirect fullscreen windows' enabled in compiz?
ghepeu: with 'unredirect fullscreen windows' there's no tearing anymore
glisse: waou even rage 128 can lockup
marienz: glisse: I don't think I've seen it either lock up or draw corruption with that agp scratch page patch, but it's possible that's just a coincidence, since it wasn't doing either all that often
marienz: hah, I take back the "no corruption" part, just got a line of garbage in urxvt again
glisse: yeah corruption can still happen
glisse: marienz: let me know tomorrow if you still didn't experiend lockup
glisse: thx
marienz: sure, and thanks again for the speedy fix :)
glisse: well i already have patch standing by so ...
BlueAidan_work: so my macbook pro doesn't like the radeon driver + KMS. Under load, it wil randomly reboot (nothing in any logs). I used to be able to disable KMS via kernel parameters / moprobe.d parameter. Now however, if KMS is disabled X starts up but only displays a blank screen.
evil_core: forcelowpowermode breaks blitter or scaler on r500
evil_core: all looks really strange
evil_core: all is zoomed, but all looks like screen cuted into tiles and not adequatly assembled
evil_core: # git branch
evil_core: * drm-radeon-testing
evil_core: is it pm2?
evil_core: git pull git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-testing-pm2
dileX: evil_core: you have to clone first and then switch to drm-radeon-testing-pm2 GIT branch
dileX: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git && git checkout -b drm-radeon-testing-pm2 origin/drm-radeon-testing-pm2
dileX: check with git branch -l on which branch you are (l)ocally
evil_core: but I wanted to upgrade current repo, not empty it :/
evil_core: # git pull git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-testing-pm2
evil_core: From git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
evil_core: * branch drm-radeon-testing-pm2 -> FETCH_HEAD
evil_core: Already up-to-date.
maligor: what exciting bits does drm-radeon-testing-pm2 contain?
evil_core: and dunno how to swith to pm2 now
evil_core: maligor: notihnjg so exciteing, its generalky broken
evil_core: and it needs KMS
maligor: well, I've tried out dynpm in 2.6.34 and it wasn't exactly terribly usable yet either
MrCooper: evil_core: if you ran the same command before, you already merged the drm-radeon-testing-pm2 branch into the checked out branch
maligor: I
evil_core: MrCooper: but what can I do now?
Jonimus: evil_core: build it ofc
evil_core: make -j2?
evil_core: sound to simple
evil_core: and dont got in in brnach -r or local :/
suokko: evil_core: pull simple merges all remote commits to your current local branch. If you want separate local remote branch you need to add git remote and fetch that remote
evil_core: both dynpm and dynclks causes hardlock when starting Xorg with modeset
evil_core: I got T60p with r500
evil_core: wonder if airlied tested pm2 on his
maligor: it does say "TODO: ... - test on more hardware." in the last pm2 change
adamk_: Is atombios used for anything other than modesetting?
mjt: isn't it the core thing?
mjt: like some abstraction level that provides much higher primitives for the gpu programming, like assembler vs visual basic ? :)
mjt: is Not A Guru (tm)
mjg59: mjt: Not really
mjt: so i don't really know
mjg59: adamk_: It's used for various things
mjg59: Not for actual acceleration, though
mjg59: adamk_: atombios.h has a list of the defined tables
adamk_: mjg59: Thanks.
mjg59: Modesetting is the big one, but also things like setting the gpu and memory clocks
NTU: Hi. quick question. Is a 4200 and a 4650 crossfireable? And do I need a crossfire bridge?
NTU: Nevermind about the crossfire bridge...
MostAwesomeDude: We don't support Crossfire.
NTU: sorry..
MostAwesomeDude: No worries.
evil_core: whos responsible for pm2, agd2 and mjg59?
evil_core: or maybe somebody else tested pm2 on r500 and it works?
ponyofdeath: hi, i am getting [KMS] no dricreatePCIBusID symbol no kernel modesetting when i do Xorg -configure. here are my logs: http://pastebin.com/xuCGLmk4
chithead: ponyofdeath: dmesg too
ponyofdeath: chithead: http://pastebin.com/XWgDympQ
ponyofdeath: chithead: gentoo adm64
chithead: [ 3.246536] r600_cp: Failed to load firmware "radeon/R700_rlc.bin"
chithead: ponyofdeath: please see channel topic how to install firmware properly
marienz: ponyofdeath: wild guess: your libdrm is too old
chithead: that would cause a different error
marienz: my bad then, sorry
Obscene_CNN: a handy dandy x86-64 inline asm COPY_DWORD macro I wrote if anybody wants to use it http://pastebin.ca/1868252
dhawk: ponyofdeath: install x11-drivers/radeon-ucode
TGEN: Obscene_CNN: why don't you use SSE
chithead: dhawk: that is only on gentoo, and it doesn't look like ponyofdeath runs gentoo
chithead: other distros have their own methods
Obscene_CNN: TGEN, I'll look into that next.
suokko: Obscene_CNN: It is often known in compile time if dword count can be divided by 2 or 4
dhawk: chithead: ponyofdeath wrote he is on gentoo amd64 at 20:19 :)
chithead: ah ok
Obscene_CNN: suokko, well I wrote this to be universal so I could use it in radeon_dma.c in mesa
Obscene_CNN: its near optimal when copying something to uncached ram
ponyofdeath: dhawk: dont see that in portage
ponyofdeath: dhawk: i got it from freedesktop.org/~agd5f/radeon_ucode/
marienz: ponyofdeath: it's ~arch but it's there
chithead: radeon-ucode is in portage
Obscene_CNN: to make it better it would need to write to 16 byte boundaries
ponyofdeath: marienz, dhawk ok got it now
suokko: Obscene_CNN: dma buffers are at least 16 byte aligned
Obscene_CNN: suokko, then I may eliminate 4 or 5 instructions from it and try it
Obscene_CNN: but for now I'm going to keep it the way it is
suokko: I jsut don't remember if any code uses offsets to buffer that is not 16 byte aligned
ponyofdeath: marienz, dhawk, chithead ok so i got the firmware in there and X now starts but i cannot get the second monitor working here is my xorg.conf and xorg log http://pastebin.com/fMayzSde
suokko: But if there is any it could be fixed not to use offsets
TGEN: suokko: isn't that hardware dependent?
suokko: TGEN: It is driver depend and dma buffer allocation quarentees alignment
marienz: ponyofdeath: you have two "device" sections for the same card. I don't think that's correct, but I might be wrong (I don't have a dualhead setup around)
ponyofdeath: marienz: well i was looking off of the ubuntu xinerama howto but i guess that could be jacked up
chithead: ponyofdeath: http://wiki.debian.org/XStrikeForce/HowToRandR12 describes how to statically configure two monitors with xrandr 1.2
ponyofdeath: chithead: thanks
suokko: But good night :)
evil_core: # git diff -u
evil_core: dives me empty output
evil_core: it means I dont got pm2?
evil_core: airlied: pm2 works on your T60p?
evil_core: intel got HiZ in free driver?
ponyofdeath: hi, wondering why me second monitor is using the wrong resolution of 1280x1024 when i have set PreferredMode to 1680x1050. can someone please help me fine tune that? here is my xorg.conf and xorg log
ponyofdeath: http://pastebin.com/qPTKkpLY
adamk: ponyofdeath: Presmably 1680x1050 shows up in xrandr for both monitors?
ponyofdeath: adamk: yeah i can change it after X starts to 1680x1050 fine
ponyofdeath: adamk: xrandr --output DVI-0 --mode 1680x1050
adamk: Perhaps your desktop environment is changing the resolution?
ponyofdeath: adamk: http://pastebin.com/ntRHdPUG
ponyofdeath: adamk: i use fluxbox i doubt it
ponyofdeath: adamk: if u look at the xorg log it says using 1280x1024
adamk: Yeah, then that's not the problem.
ponyofdeath: adamk: so in the log also it does not take the options for Monitor0 as it did for Monitor1 which has PreferredMode
airlied: oga: yeah refcounting would be cool, I'm not sure why I didn't refcount the regs one
oga: the diff is already on the list ;)
airlied: evil_core: I had some issues with it I haven't had time to look
evil_core: airlied: I got hardlocks after typing few commands or loading xorg, I wanted to know if its specific to me ;)
airlied: oga: cool, will see it in a few mins then ;-)
airlied: evil_core: no I think thats what happened here
adamk: ponyofdeath: Maybe try giving the monitors the Identifier that xrandr uses.
evil_core: anyway do you know if intel supports HiZ in their driver, and if it would provide fglrx performance level for old games, and if it would be easy to write?
ghepeu: MrCooper, adamk, you were right about the compiz benchmark plugin: I found a reverted patch in compiz git log who added an option to always damage the entire screen, and with that there's no tearing anymore
adamk: ponyofdeath: Not sure if that'l solve the problem, but you could at least remove the two Monitor Options in the Device secton.
ghepeu: it doesn't seem too good for performances, however. scrolling in firefox is distinctly slower
airlied: evil_core: HiZ isn't generic feature
adamk: ghepeu: So with benchmark damaging the entire screen, there's no tearing, but performance is worse?
adamk: ghepeu: That's really not surprising, though. That means it has to redraw the entire screen with each damage, not just part of the screen (which is the purpose of the damage extension, as I understand it).
ghepeu: with benchmark or with the compiz core patch. no real data, however, that's just a feeling
adamk: Yeah, that's the reason compiz doesn't redraw the entire screen :-) Performance goes down.
evil_core: airlied: I know it was avaible for r200, dunno about r300/r400, how commands, differ. I know whats that from wikipedia and how it works ;)
adamk: I'm fairly certain I've seen this discussion either on #compiz-dev, the cf forums, or the nvidia forums.
ghepeu: what I don't understand is what changed since january in mesa/ddx/xserver/kernel. tearing avoidance used to work without compiz always damaging the entire screen
airlied: evil_core: yeah Intel don't have an equiv I don't tink,
airlied: I think nvidia do something similiar buts it not call Hi
adamk: ghepeu: Sorry, no idea. I'm the wrong guy for that one :-)
evil_core: I told that r200 free drivere got in changelog its implemented
airlied: yeah hyper z clears are in the UMS driver, not complete HiZ support
evil_core: for r30/r400 too?
airlied: no r100/r200
evil_core: I wonder if some person like me, w/o programming skills can try to backport it for r500 using old UMS and intel code
evil_core: and if its worth
evil_core: I understand nobody is interested in writing such thing, they prefer to buy better cards, but I am sure I will stay with r500 for years, cause love FlexView and 4:# aspect
evil_core: So I must do something myself to get decent performance ;)
ghepeu: adamk, I hope somebody will fix this problem before my next holiday. in the mean time I'll go back to ums
evil_core: ghepeu: por stop using compiz/firefox, WMaker and w3m works everywhere w/o problems
ghepeu: evil_core, fwiw, I could just login in ssh from my work laptop with vista
airlied: evil_core: what intel codE? there is no intel code I just said they don't have it
ghepeu: sshd, bash and tcp/ip work everywhere without problems too
ghepeu: ;)
marvin24: mesa's 385e2896ebf54ac0b016132fe513f21a5b67ba4f broke swapbuffers here, anyone else?
Obscene_CNN: marvin24, does that keep you from building xorg-server-1.8.0 ?
evil_core: marvin24: swapping buffers is ok for me in mesa master
evil_core: Obscene_CNN: you are developing radeon drivers, or only writing tricky patches from time to time?
marvin24: Obscene_CNN, evil_core: got fixed on #dri-devel
Obscene_CNN: evil_core, more likely writing tricky patches. But I do have some stuff that will probably be accepted in the radeon drivers
tormod: Sarvatt, what do think about the ever-increasing gem object bytes? is bug 565981 a real bug or red herring?
tormod: oops wrong channel :(
Tommeh: tormod: aren't you the chap that runs xorg-edgers? :)
tormod: Tommeh, yes, although sarvatt does most uploads nowadays
Tommeh: Well, I would like to thank you both! :)
Tommeh: It's been very valuable to me.
tormod: Tommeh, great, you're welcome
Tommeh: In fact, the only issue I have ever had is when trying to upgrade to Lucid today - even after ppa-purge, there were still tonnes of broken dependencies, heh
Tommeh: But it's fine, clean install is a good idea :)
Tommeh: But yes, thank you both for your efforts!
tormod: you did the ppa-purge _before_ you upgraded?
Tommeh: Ofc. :)
Tommeh: I removed every PPA I could, except wine.
Tommeh: And there were many broken xorg packages.
Tommeh: Well, broken dependencies - not packages - sorry
tormod: Tommeh, ok maybe ppa-purge did not clean out everything. it only reverts packages that exist in the ppa, so if some stuff was removed from there...
evil_core: I got in KMS some 4096x4096 texture limits errors in wine
evil_core: and info it needed 8192x8192
evil_core: i it KMS/gallium limitation?
evil_core: and can I change it easily?
Tommeh: tormod: it's a good idea - probably works for drivers-only :)
Tommeh: But I knew I would have a 50/50 chance of a fresh install, so I am not worried.
Tommeh: It's only my work machine!
tormod: oh no worries then :)
Tommeh: So long as you keep going with it into the Lucid/M cycle it's fine!
evil_core: what can be cause of MEsa reverting to soft rendering in one game?
Tommeh: *cycle(s)
DanaG: Next thing I'd want a ppa for: "pm2" kernel.
DanaG: With those extra-patches for manual power-state selection.
evil_core: DanaG: dumb idea
DanaG: Why?
evil_core: pm2 causes hard lockups at now for r500
evil_core: nearly after load
evil_core: what we got currently in UMs/KMS/gallium: fbo,pbuffer,GLSL?
MostAwesomeDude: You're mixing and matching a bit too much.
MostAwesomeDude: Gallium doesn't work with UMS, period.
evil_core: I know
evil_core: but it would be good to got such things in tables
evil_core: to set wine registry, etc
glisse: 1
evil_core: libGL: radeonCreateScreen: drmMap failed for GART texture area
evil_core: libGL error: Calling driver entry point failedlibGL error: reverting to software direct rendering
evil_core: lcan I do anythin with that?
evil_core: I know KMS supports GART, but breaks everything else breaking all game :/
otaylor: evil_core: "KMS as installed on your system"
otaylor: evil_core: I think you are mostly seeing errors in putting things together, or "noise" as UMS or KMS is differently buggy at the moment
otaylor: evil_core: there really are no regressions from UMS to KMS ... KMS is supposed to be uniformly better in all respects, that's some bug that's happening with the particular versions of things on your system
dileX: Linux 2.6.34-rc5 released
Tommeh: gives up compiling -rc4
evil_core: wheres otaylor to fuck :/ wanted to answer him...
Tommeh: I was going to point out I had annoying regressions with KMS over UMS
Tommeh: but I've not tried with -rc4 yet, so shouldn't really.
dileX: evil_core: its really hard to follow you
evil_core: KMS got regressions over UMS, its the fact
evil_core: and the most annoying isnt performance one, but not longer running apps
evil_core: and I am sure about mien built environment, it was redesigned after previous crashes, and I checked many things with ldd and followed gcc output
evil_core: I am the distro developer and I really know how to do it
dileX: evil_core: which distro BTW?
evil_core: PLD ;)
evil_core: pld-linux.org
evil_core: yeah, we arent death yet!
evil_core: dead*
dileX: interesting: 1st April 2010: PLD Linux switch to DEB package format
evil_core: once it was biggest rpm distro, and second after debian(in repo size)
dileX: OT: http://kde4.livecd.pld-linux.org/ links to nirvana
evil_core: it links to nowhere for me, to nonexistent shadzik project
dileX: hmm, you support also ppc arch
evil_core: its old project made when kd4 was unstable and installable with many Qt3 apps, it was kind of KDE4 preview for PLD users
evil_core: we dont support anymore
evil_core: it was supported in Ac, and for ~3 years in Th, but theres not too much PPC now
evil_core: especially after Apple migration to x86_64
evil_core: there are probably some users that still supports it, but not too much
dileX: last days there was someone on ppc arch having troubles w/ r128 and openfirmware
evil_core: remember
evil_core: but I dont have PPC ;)
Obscene_CNN: ppc is so much better than x86
dileX: evil_core: do some marketing for you(r distro) - a test should worth it
evil_core: Obscene_CNN: but its death on desktops
evil_core: dead*
Obscene_CNN: well thats because M$ hadn't updated their ppc compiler in years and M$ office ran faster under x86 emulation than it did natively
evil_core: dileX: 90% of our deveopers now develops Arch, in previous years many went to gentoo, its not distro for average user I think
evil_core: Obscene_CNN: no, its because Apple abandoned it
Obscene_CNN: thats why mapple abandoned it
evil_core: and the only widely avaible machines now, are DRMed consoles
evil_core: ee?
evil_core: Apple used Visual Studio?
Obscene_CNN: M$ used visual studio to make the mac version of office
evil_core: yeah, but I dont believe in such optimizations to be distinguishable by office users
evil_core: its mostly RAM and GUI reponsivness
Obscene_CNN: excell it was very noticable
evil_core: but average user make timetables
evil_core: http://carme.pld-linux.org/~evil/varia/wszib/fizyka/
evil_core: I use vim + bc(and usually $(()), and thats enough for all
evil_core: but we got also console 'sc'(excel replacement) and tpp(text power point)
evil_core: its UTF-8 if you want to see that files ;)
evil_core: anyway I am going sleep, cause its nearly 3AM here in Poland, and I must wakeup on lecture (Dethkarz LANpart over WiFi ;)
evil_core: I winder if it would be easy to play Ignition over IPX using linux machine and wifi ad-hoc
Obscene_CNN: good night then
evil_core: good night
evil_core: noit sure if glide ignition didnt supported TCP, but it fallbacks to swrast undr UMS and doesnt start under KMS at all :/
evil_core: I googled it should be easy to use IPX with wine :)
dileX: evil_core: sent the PLD URLs to that guy
evil_core: to which guy?
dileX: evil_core: guy with problems ppc/r128
dileX: evil_core: we are getting OT, PLD has IRC support?
AstralStorm: hey, I'd really like the open driver to have OpenGL 2.1 support
AstralStorm: a good starting point would be running fgl_glxgears
AstralStorm: (uses pbuffer I think)
AstralStorm: at least some kind of rendering to texture there
AstralStorm: and w/o PBO, everyone knows how hard it is
AstralStorm: ;p
AstralStorm: actually, GLX_SGIX_pbuffer and GLX_EXT_framebuffer_object
AstralStorm: can pick one (and FBOs are supposed to work)
arling: I see the 10.4 preview was released a few days ago for windows. I found a few posts stating it was released for linux (64-bit) also as a preview from ati, but I can't find a link to that. I'm running Fedora, so the Ubunti preview won't help.
arling: ahh wrong channel sorry
Tommeh: arling: either way, good luck with that ;)
arling: Thanks :(
Tommeh: #phoronix might be some help - there's probably at least one person trying to extract the catalyst driver from Ubuntu and make it work elsewhere.