vehemens: compiz cube with reflection. screens and windows white however.
vehemens: lower cap has partial distortion while top cap has significant distortion
MrSunshine__: OpenGL vendor string: DRI R300 Project
MrSunshine__: OpenGL renderer string: Mesa DRI R300 20060815 NO-TCL
MrSunshine__: am i in the right place? :)
ferret_: xpress 200m is it? ;p
ferret_: Yeah, this is the right place
MrSunshine__: think so
MrSunshine__: so, then why do i get no-tcl ? and when do i get shader support, as they have removed the support for my card from fglrx and im developing a 3d engine .. its quite annoying :P
MrSunshine__: and is there no true 3d support in the driver?
ferret_: The card you have doesn't have TCL
MrSunshine__: ok
MrSunshine__: thats one :)
ferret_: If mesa hadn't detected that and turned it off, it would have crashed X and your input/output in a nasty way that would require a reboot
ferret_: It can still do shaders, they will just be very very slow
MrSunshine__: heh ok :)
MrSunshine__: well with fglrx i have colors etc on my objects, with this driver they are all white
MrSunshine__: and from the chart i loooked at before glsl wasnt implemented for the R300 driver :/
ferret_: That is a probably unrelatd issue...
ferret_: I would suggest a newer version of mesa to start with
gravirama: ïðèâåò
MrSunshine__: ferret_, but will that work at all when according to the chart on a site (yours?) i was given before glsl wasnt implemented yet ? :)
ferret_: didn't see you mention glsl before
MrSunshine__: nah missed that .. but i wrote it some lines up :)
ferret_: I don't really know about that...
ferret_: Potentially again there is a software implementation in place
ferret_: (there's no indication of a complete implementation for GLSL in any of the radeon drivers)
nha: ferret_: indeed, GLSL hasn't been implemented in the Mesa driver; it's enabled in the Gallium driver, but that driver is very experimental and I suspect you won't much enjoy working with it unless you want to dip your feet in driver development
ferret_: Yes, I was just reading about that
airlied: and all the vertex shaders will be done on the CPU
airlied: the fglrx CPU vertex shader compiler kicks our ass
vehemens: just been looking at the r6xx/r7xx shader docs trying to understand how to do a simple blit. it's not for the faint hearted.
MrSunshine__: well maybe a blit isnt so simple then ... ever thought of that? :P
vehemens: it used to be :/
airlied: vehemens: if it was simple I think alex would have done it :)
airlied: the only way to do a simple blit is to set the whole 3D engine up
airlied: there is no 2D engine
airlied: doing that in the kernel is non-trivial
vehemens: not all that easy in user space either based on what i've seen in mesa and radeon ddx
airlied: pretty much exa copy is a blit
glisse: hey if gpu programming was easy it wouldn't takes so much time and we would have time to drink pina colada on beach !
glisse: :)
vehemens: glisse: you could do both :)
nha: take your development system(s) to the beach!
nha: let your inner geek be free
glisse: i fear the fan might not like the sand... :)
vehemens: airlied: at some point he's going to need a solution. any idea what he has planned?
airlied: vehemens: I'm sure he'll tell us when he figures it out :)
glisse: if fbcon get killed i should see some kind of message somewhere on why ?
airlied: try chvting :)
glisse: [root@localhost ~]# modprobe fbcon
glisse: Killed
glisse: but nothings seems to popup in log
glisse: at least now the computer doesn't hard freeze
airlied: sounds like memory corruption
glisse: r6xx doesn't like 8bpp surface
airlied: I don't know what plymouth will do with 8bpp front buffer
glisse: it was the hdp surface
glisse: well hdp nonsurface
vehemens: dedicated shaders in kernel drm seems like one solution. maybe use the one in ddx.
airlied: dri2 would use the DDX one :)
glisse: vehemens: it's not that much the shader but the whole other part of the gpu you need to setup to actually run those shader
vehemens: how about shifting the dispatch code (texture and swap) to user space then?
vehemens: i'm assuming that dri support is still planned
Esmil: Hey, I'm getting errors when trying to compile the latest git version of xf86-video-ati. Here is the log if anyone is interested: http://pastebin.org/3001
stikonas: Esmil: maybe try updating libdrm
Esmil: stikonas: My libdrm is the one from freedesktop.org/git/mesa/drm, master branch with --enable-radeon-experimental-api enabled
Esmil: Should I use something else?
nanonyme: stikonas: Actually I had the exact same issue yesterday with newest components then.
stikonas: I've compiled everything a few hours ago, and there were no errors
nanonyme: *shrug*
nanonyme: Probably would want to find out first which X.org component has that symbol.
nanonyme: Erm, struct even.
glisse: Esmil: too old Xorg
glisse: you need new xserver
nanonyme: How old is too old?
nanonyme: 1.6.2+
nanonyme: ?
nanonyme: Typo
Esmil: glisse: Ahh, thank you
glisse: i am assuming you are trying to build ddx from git
glisse: often it needs Xserver from git
nanonyme: Right.
nanonyme: Targeted against 1.7 then, I assume.
boghog: blaargh
da1l6: hi
da1l6: I have a laptop with a mobility hd2600 (M76) chip and two video outputs (VGA and DVI-D) both outputs work with the radeon driver, but only one at at time.
soreau: what happens if both are plugged in?
da1l6: When i try to activate the second one (does not matter which one), xrandr tell me "xrandr: cannot find crtc for output VGA-0" (or DVI-0). Is this a hardware limitation or a bug?
da1l6: xrandr -q lists modes for both monitors correctly
MrCooper: Esmil: whoops, should be fixed now
da1l6: Driver version is fom git master, head at e38305a
da1l6: Xorg.0.log: http://pastebin.com/m51edc073
soreau: da1l6: What xrandr command is giving you this message?
da1l6: xrandr --output VGA-0 --mode auto --left-of LVDS
da1l6: the same works fine if DVI-0 is off
da1l6: but then DVI-0 can't be activated if VGA-0 is on
chithead: maybe you can add --crtc parameter to explicitly assign crtc to display
soreau: I seem to recall some crtc discussion the other day, though I can't remember specifics it could be a bug. I would like to think your hw is capable of using both outputs at the same time
chithead: "xrandr --verbose" will tell which crtc can drive which output
Esmil: MrCooper: Cool, it works now. Thank you
Esmil: Time to try out a kms kernel then :)
da1l6: chithead: Hmm... seems there are only two of them and one is already used for the panel. :( http://pastebin.com/m133e3aff
chithead: da1l6: so what happens if you specify a crtc
da1l6: both external outputs work if i turn the laptop panel off.
mjg59: Yes, most hardware will only scan out two separate images
mjg59: You can probably mirror onto DVI and span onto VGA
mjg59: But you won't be able to use all three separately
da1l6: mjg59: okay, thanks.
chithead: it might be possible to drive two outputs with the same crtc, but they cannot produce different pictures then
soreau: So is that a driver or hardware problem?
da1l6: hardware limitation as it seems
soreau: seems like all those mobility Mxx chips suck :)
chithead: there are very few chips on the market with more than two crtcs
glisse: soreau: nvidia are same regarding to this
glisse: it's just that there isn't much hw nowadays with more than 2 crtc
chithead: matrox I think
soreau: Oh so he's trying to use all three outputs?
soreau: I know you can't do that
da1l6: i didn't until now
da1l6: was so naive to think that two video outputs on this laptop mean that i can use 2 external moitors.
mjr: as they said, it actually does, though it's counterintuitive, yes, that the internal screen is useless or at most a mirror then
mjr: I would say it's still useful
dmb: is there any open source drivers with glsl support?
dmb: or will radeon be the first?
glisse: intel has glsl support
dmb: it does?
dmb: i thought I was using a 945 once and the glue function told me there was no support for glsl
dmb: glew*
glisse: intel gallium driver should support it
glisse: but i don't know how well intel gallium driver works
dmb: yeh, it was on windows that i actually tried it, no idea on linux
MrCooper: dmb: it's only supported as of i965
dmb: glisse, is that how radeon is going to work as well, with support in the gallium driver for glsl?
glisse: dmb: i don't think it's worse the trouble to support glsl with old driver arch
glisse: that said some might do the code :)
dmb: i really wish I knew more about video and graphics card, and I would contribute :P
dmb: those ati docs are kind of intimidating if you don't know much about graphic cards
glisse: there is plenty of info on the net about how gpu work from high point of view
dmb: does the video card compile glsl code or is it the driver that compiles it and sends the asm to the card?
glisse: driver does that
dmb: oh, so then it is a little difficult to implement as it requires a compiler :/
glisse: yeah, if it was easy we would have done it long time ago
MrCooper: dmb: Mesa core compiles GLSL to assembly
dmb: MrCooper, an assembly the video card can understand?
dmb: i'm guessing the assembly requires by nvidia cards differs from the assembly requires by ati cardsd
glisse: only the specific gpu driver inside mesa know how to talk to a given gpu
glisse: it's not standardized in anyways
glisse: so it's up to the gpu driver to translate into somethings the card understand
dmb: oh
DanielHorne: Anyone know if there's newer KMS code than that of linus' master?
DanielHorne: I'm using linus' master with an R500, and am getting "Ring test failed", "cp isn't working" and "Failed to initialize radeon, disabling IOCTL" errors
glisse: DanielHorne: AGP ?
DanielHorne: No, It's a PCI-E X1950
glisse: strange should work
DanielHorne: Well, the system boots up, and when starting X, it seems to correctly probe the sizes of the attached displays. But I've no DRM
glisse: yeah kms doesn't fail in proper way right now
DanielHorne: Any debug info you'd like me to try and find?
MrCooper: dmb: a HW independent intermediate representation
glisse: DanielHorne: if you have debugfs mounted there might few usefull files to dump
glisse: dmesg will definitly be helpfull as a start
DanielHorne: http://pastebin.com/m4f8b60a3
glisse: DanielHorne: disable the vesafb stuff
glisse: it's what breaking things
glisse: we need to check for such things
mjg59: Hm
mjg59: Now that we've got the boot VGA device exported in the kernel, we could probably tie vesafb to the PCI device
mjg59: That way the conflict would be obvious
glisse: yeah sounds like the way to go
DanielHorne: Thanks, guys. Will try that.
danielhorne: Recompiling without vesafb, machine locks up hard after (apparently) the screen probe
danielhorne: Can't get the dmesg this time, as it does not complete the boot.
mjg59: Make sure you don't have any vga= argument
danielhorne: Yeah, I didn't
danielhorne: Possibly flakery due to a dual-screen layout, perhaps?
danielhorne: I've a 1280x1024 and a 1920x1200. The 1280x1024 panel's been initialised to black, while the 1920 panel has a black square f the size of the other monitor, with the rest being covered in noise
danielhorne: bridgman: No joy without vesafb, either.
bridgman: maybe disconnect one screen ?
danielhorne: I'll try, just a sec
danielhorne: Nope. Screen is initialised, but no further signs of life
bridgman: hmm.. I don't know the kms code well enough to help much other than making sure that all the previous suggestions have been tried ;)
danielhorne: Ok, fair enough
bridgman: dmb: AFAIK the hw-independent shader language for classic mesa is defined here :
bridgman: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/shader/prog_instruction.h
bridgman: very similar to arb_fp/arb_vp
bridgman: scroll down to prog_opcode, then prog_instruction, then go back and look at the rest ;0
dmb: yeh, never tried yet, how does modesetting work with a dual screen?
danielhorne: I had it working before; when booting, each screen gets set to native resolution. The console is sized to the smallest screen, and displayed on all attached displays
danielhorne: Any screens larger than the smallest one have a black border.
danielhorne: But this quit working for me when I switched from Dave airlie's branch to linus' master.
Esmil: Aww, I still get this kernel bug when trying kms in 2.6.31-rc3: http://pastebin.org/3052 Am I the only one who experience this?
Kano: hi, how to force external vga port when internal laptop display is broken?
danielhorne: xrandr --output VGA-0 --auto
soreau: ssh into the lappy and use xrandr?
Kano: funny when you dont see anything ;)
soreau: ssh ftw
Kano: how to do that in xorg.conf?
Kano: no ssh running
danielhorne: Hmm. iirc not all of the randr instructions have conf file equivalents (maybe I'm out of date)
adamk_: Kano, Define a monitor section in your xorg.conf file with the identifier VGA-0
Kano: ok, and then
adamk_: Specify the resolution you want in there with the PreferredMode option and then start X.
Kano: how to set 60 hz?
adamk_: I believe simply using "1280x1024@60" will force it to 60, assuming Xorg detects a mode at that resolution and frequency. If it doesn't, or if that doesn't work for some reason, simply define a modeline.
adamk_: You can use gtf to create modelines.
Kano: i only need 1024
adamk_: Then try:
adamk_: Option "PreferredMode" "1024x768@60"
adamk_: Again, if that doesn't work, create a modeline.
chithead: I think you can also specify vertrefresh in the monitor section
adamk_: Hmm.. Could be. I haven't done that in a while.
Kano: option enable 0 for the lvds i guess
Kano: i can ssh to it, but
Kano: DISPLAY=:0 xrandr --output LVDS --off
Kano: does nothing
Kano: also i have got 75hz on vga
Kano: http://paste.debian.net/42146/
Kano: well i used now
Kano: xrandr --output LVDS --off --output VGA-0 --off
Kano: xrandr --output VGA-0 --auto
Kano: in a .kde/Autostart file
Kano: dpi is not optimal,but you see something
ernstp: just noted that the graphics in Eclipse is a LOT fast with shadowfb than exa
ernstp: but I'm on a r7xx card so maybe it's just something that's not finished yet?
danielhorne: Eclipse uses the SWT library for interface code. I'm not sure what pathway it uses for drawing graphics
MostAwesomeDude: GTK+
ernstp: yeah, doesn't it?
ernstp: that means I could use cairo-trace in theory
ernstp: wouldn't surprise me if it doesn't work though
ernstp: ok I need to do a lot of work to get cairo-trace working, it'll have to wait
AndrewR: anyone familiar with mmiotrace and r200 dri driver?
AndrewR: i have parsed log from cubemap demo in dri2 mode, it draws incorrectly as some can recall. File is nearly 800kb. Should i just compress it and attach to bugzilla entry?
dmb: for modesetting, is autodetection of laptop modes going to be coming soon?
dmb: so it automatically adds all modes besides the native resolution so you can switch with xrandr
dmb: without adding it yourself
adamk_: dmb, Works as expected here.
bridgman: my recollection was that kms only added the modes from edid, while user modesetting also inserted a bunch of standard resolutions from the x server
bridgman: unless that changed recently ?
adamk_: Well this is what xrandr produces on my laptop, without defining any extra modelines: http://pastebin.com/f6dad2c1
bridgman: any idea what the EDID info says ? I gather some laptops only return native res in the EDID block
bridgman: not sure if LVDS displays can have built-in scalers; my understanding was that they generally did not but I don't really know for usre
bridgman: sure
adamk_: From the Xorg log file, it looks like it's seeing 1400x1050 at 64.0 and at 53.3
adamk_: Which is odd...
bridgman: yep... does the X driver even read EDID when you're running KMS ?
adamk_: Oh, wait... I'm being quite stupid here.
adamk_: I'm on my freebsd laptop at the moment.
adamk_: Duh.
bridgman: well, it *is* a weekend ;)
bridgman: anyways, bbl
airlied: mjg59: we have fb handover now
airlied: i just haven't added radeon code for it, its only two lines
airlied: it makes vesafb detach when radeondrmfb attacjes
nanonyme: wonders whether bridgman meant you're allowed to be stupid on weekends or you're not supposed to do work at all
nanonyme: (or both)
mjg59: airlied: Do you know if vesafb is bound to the device you're binding?
airlied: I do overlapping checks on the phys addr ranges
airlied: same for efifb
airlied: I added new memory sizes to the fb code that they register start/end ranges
airlied: I just need radeon to register its vram aper start/end
mjg59: Ah, ok
mjg59: Easy enough
hifi: mm, black screen on r500 for any 3d rendering
hifi: kms, git mesa, ddx, xorg
danielhorne: Any ideas on how I could debug a machine that appears to crash immediately after kms initialises the screen?
airlied: danielhorne: boot with nomodeset
airlied: or radeon.modeset=0
danielhorne: Ok..
airlied: then rmmod radeon/drm
airlied: ssh in and modprobe it later
danielhorne: Well, i've got a non-kms backup kernel. was just wondering if it'd be useful to look into this to help debug the kms code.
airlied: it sounds like you don't have fbcon builtin or loaded
danielhorne: I'll check that.
danielhorne: Neg. fbcon's builtin
spstarr: you're kidding me
spstarr: "VIA's open-source advocate, Harald Welte, expressed their plans. VIA's official X.Org driver that is under a proprietary license can provide 3D support, but it will not be released as open-source because of third-party licensing claims."
spstarr: the guy who runs gpl-violations.org and is the supposed "open source advocate" for VIA
mjr: read on
mjr: and it's not like he calls the shots there
spstarr: im 2nd paragraph in ..
mjr: (shooting the messenger, eh)
spstarr: mjr: hmmm
airlied: danielhorne: then boot without modesetting, and if you can ssh in get a dmesg fro mwhen modesetting loads
airlied: danielhorne: you got > 4gb ram?
danielhorne: 4gb, yeah
spstarr: mjr: I just see more innocent kittens to be slaughtered :(
airlied: danielhorne: you''ll need some fixes I've got queued up hten
airlied: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-kms branch
mjr: spstarr, possibly. Or possibly they are serious about releasing more docs on those old chips and doing it right for the new chips from the get-go as they say. We'll see. Won't be buying them of course before they deliver, but I think some benefit of the doubt is deserved; amd also took its while to get somewhat on the righteous path
spstarr: airlied: will the r6xx/r7xx stuff be backported to F11? or will I have to cherry pick rawhide bits for ddx, kernel, libdrm, mesa?
airlied: spstarr: I doubt we'll bother backporting
airlied: F12 will be out before its stable
danielhorne: airlied: thanks, I'll try that
nanonyme: airlied: I guess the more interesting question is whether F12 will be released with the r6xx/r7xx stuff.
airlied: nanonyme: depends on when the stuff stabilises
glisse: nanonyme: non kms r6xx/r7xx support should be their, hopefully kms non accelerated should also be there :)
AndrewR: airlied, ping ...
airlied: AndrewR: pong but not for long
nanonyme: glisse: Hmm, so the KMS accelerated stuff might take until next Spring?
glisse: now i think Bad Santa has his people working on that ;)
glisse: s/now/no
AndrewR: airlied, what about fixing dri2 on latest kernel, with colortiling on? I have my own patch, but it probably not complete and not very correct ...
nanonyme: Hehe. ^^
AndrewR: dri2 on rv280
airlied: AndrewR: I'm still writing the kernel code
airlied: when I finish it I'll push out th eother bits
AndrewR: airlied, thanks
boghog: cant wait for the kms stuff, i just finally got it working on my intel laptop
mcgreg: meh .. half of thisday I tried to install debian on my usb hdd .. and I failed 1000x times
spstarr: airlied: ok
spstarr: mjr: true
mjr: (can't really blame them for not wanting to write whole new drivers for basically obsolete hardware)
vehemens: noticed experimental 3d wiki lists mesa merge to happen under plans
bridgman: I can fix that ;)
nanonyme: bridgman fixes everything! \o/
bridgman: just the easy stuff ;)
nanonyme: bridgman: Most commented since if I was paid to be here on weekdays, I would most def not be here on weekends. ;)
nanonyme: s/st/stly/
bridgman: I'm not actually paid to be here during the week either, so it's OK ;)
nanonyme: :D
vehemens: bridgman: enable and test? then there's code somewhere?
nanonyme: Hmm, what did this relate to? :o
bridgman: textures ? yeah, AFAIK it's been written twice; original code was done back in April, then Alex rewrote chunks of it to make use of new common code from radeon-rewrite
nanonyme: Are there any test progs in Mesa that the texture code passes?
vehemens: maybe i'm missing something, but i had the impression it's not public yet (i.e. not in git).
bridgman: let me check; pretty sure it was pushed a while ago
nanonyme: Well, my two-parted question still applies. ;)
airlied: I think the texture code is out there.
airlied: hmm this firemv has some funky connectors
bridgman: looks for the second part ;)
bridgman: ah, you mean "are there any test progs that the texture code passes ?"
bridgman: yeah, the ones that don't use textures ;)
bridgman: http://cgit.freedesktop.org/mesa/mesa/commit/?id=1bad691a177240e8281592fa66c9e6ab0869f618
nanonyme: Well, I actually meant to ask whether there are programs that use the texture code and if the texture code actually passes those tests but you're right, badly worded question.
vehemens: well the texture code is, but don't you still need blits in dispatch swap and texture (mesa has a mempcy for texture)?
bridgman: memcpy for texture is already there AFAIK
airlied: the kernel code has a texture memcpy
bridgman: memcpy from system memory to vram is really fast, maybe 2GB/sec
bridgman: it's only memcpy *from* vram that's pig-slow
bridgman: then again I got chased by a pig a couple of months ago, they are *not* slow
vehemens: okay, let me regroup here. compiz doesn't work for me. so is that missing/disabled functionality or just a bug(s) that needs to be tracked down?
airlied: vehemens: I'd start a bit lower down than compiz
bridgman: compiz needs textures
airlied: its like going to pluto without trying mars first
bridgman: that's how you copy with the 3D engine; point a texture to src, point render target to dst, draw a quad
airlied: I've no idea if the texture TFP code is all hooked up either
bridgman: airlied; bad analogy, sometimes mars is on the other side of the sun ;)
bridgman: agd5f thought it was all hooked up but it didn't work so nobody is really sure ;)
vehemens: mars is in the wrong direction unless your going to slingshot off of the sun
bridgman: there should be a red light that goes on every time an analogy is abused
biotube: then it would never turn off ;)
airlied: normal people accept the analogy is meant to only reflect some small part of the reality
airlied: and wasting time disecting an analogy isn't going to fix any of the problems.
bridgman: there's a long thread about tripping overcurrent protection with the "extreme burning" mode of OCCT, where about half of the posts were discussing the relevence of the automotive analogy being used to justify the outrage
bridgman: or ridicule it, depending on which interpretation of the analogy you followed
airlied: its why engineers have parties on their own :)
bridgman: or maybe extreme burning is furmark, I forget
bridgman: ;)
bridgman: anyways, I think getting basic textures working first before trying compiz definitely makes sense
bridgman: no matter what side of the sun it's on ;)
airlied: I'd start with texrect as it likes rectangular textures
biotube: how about this: you've got to get to jupiter before you sundive
bridgman: can we do car analogies instead ? I was getting pretty good with them
biotube: spacecar!
cybersphinx: bridgman: Mars is still always closer than Pluto.
nanonyme: Then again, since Pluto isn't a planet it might not count anyway.
biotube: isn't flamebait a nono?
vehemens: flyng car? http://www.engadget.com/photos/parajet-skycar-flying-vehicle-evolves-now-ready-for-pre-orders/2152296/
nanonyme: Flamebait? o.O
nanonyme: vehemens: And yeah, neat.
nanonyme: Wonder how stearable it is.
bridgman: wonder how airtight it is ?
cybersphinx: But for some on-topic discussion: I've recently installed all the new kernel/drm/xorg-ati/mesa stuff, and KMS/DRI2 seems to work nice. But how can I test Gallium3D? Mesa still seems do use the old DRI stuff.
cybersphinx: (It's a test system with a 9600XT, it doesn't matter if it doesn't work.)
nanonyme: You actually installed the Gallium driver, right?
bridgman: mesa should automatically use dri2 if you have kms/gem/ttm etc enabled, I think
bridgman: I mean classic mesa
airlied: cybersphinx: gallium3d doesn't build for radeon at the moment
bridgman: the radeon-rewrite project allowed classic mesa to run over non-kms or kms
nanonyme: airlied: Doesn't it still favour classic Mesa even if you build Gallium3D?
cybersphinx: Yes, the Mesa/DRI2 part seems to work (more or less).
airlied: nanonyme: if you could get it to build, it won't use it by default yes
cybersphinx: airlied: Well, Mesa with Gallium built some days ago, and I installed it via make install.
airlied: and even if it does build you have to jump through hoops.
airlied: cybersphinx: the radeon bit doesn't compile
nanonyme: Oh, I wasn't aware of this. How long has it been in an unbuildable state?
airlied: since I broke it.
cybersphinx: airlied: I think I had some r300 gallium file.
airlied: I nearly fixed it last night
airlied: but I watched tv instead
nanonyme: *shrug*
cybersphinx: I had to fix one thing to compile it: http://pastebin.com/f729927d8
nanonyme: Uh, oh.
cybersphinx: Then it installed a EGL_r300.so in /usr/lib/dri.
MostAwesomeDude: I'll fix it later.
airlied: I'll give you 5 guesses how well that is going to work
MrCooper: airlied: nha's fix seems to work
MostAwesomeDude: nha's fix works, but I haven't applied it because I haven't tested it.
airlied: MostAwesomeDude: just apply is already :)
MrCooper: MostAwesomeDude: I have
MostAwesomeDude: MrCooper: Awesome.
MrCooper: MostAwesomeDude: btw, there's still an instance of a VAP_CNTL_STATUS write that doesn't set the swap bit for big endian
MostAwesomeDude: airlied: So could we pass around pixmaps with each CRTC?
MostAwesomeDude: MrCooper: Really? I didn't see it on grep; I can track it down if it's still a problem.
cybersphinx: So, any hints on how to actually use gallium (and see it crash and burn, judging by the last comments)?
MrCooper: MostAwesomeDude: r300_surface.c
airlied: its not totally correct though
airlied: sinec he never registyers a flush handler
airlied: MostAwesomeDude: don't see why not, you can just make the current code have a pointer to the screen pixmap
MostAwesomeDude: MrCooper: Arg. I know where it is. Will fix.
MostAwesomeDude: airlied: Yeah, but the idea is that the screen pixmap won't actually be BO-backed.
airlied: MostAwesomeDude: it'll get cut up down further into multiple bo pixmaps?
airlied: MostAwesomeDude: the thing is you probably want an interfrace to the drivers that works with old and new ways
airlied: so you probably want the driver to carry a pixmap ptr in the crtc always
MostAwesomeDude: airlied: Well, so far I haven't been able to get around the fact that drivers need to be able to bind each shard to a CRTC.
MostAwesomeDude: I was thinking that it would probably be easier for EXA to support both shattered and non-shattered pixmaps, and then just require EXA_HANDLES_PIXMAPS for shattering.
MostAwesomeDude: And, if a driver doesn't want to do shatter, then it can just never shatter pixmaps, it can set a flag for EXA, and just never call exaSetShards(). :3
DanaG: hey, what's this about shattering?
DanaG: =þ
MostAwesomeDude: DanaG: Just my GSoC project.
MostAwesomeDude: Thinking about the proper sets of interaction here.
MostAwesomeDude: I think DDX should track root shards but not auto-created shards.
MostAwesomeDude: 'Cause it has special root shard requirements.
airlied: MostAwesomeDude: why does it care about root shards?
airlied: if you have a scanout this pixmap interface
airlied: which you then use for normal root pixmap in non-shatter case
MostAwesomeDude: airlied: I think I missed something. The point was that root shards need to be scanout-able and that DDX probably has special requirements for that.
airlied: MostAwesomeDude: then just add a create pixmap flag
airlied: we have a usage set of flags already
MostAwesomeDude: airlied: Okay. So then how does the DDX know what to do when handed a shattered pixmap?
airlied: I don't follow what difference is a shattered pixmap to the DDX at that point
airlied: if you are going to do operations on it, I assume the ops will have been broken up before hand
airlied: so it won't know its a shard its working on.
airlied: and scanning out should be just a matter of here show this pixmap, again not caring if its a shard
airlied: the only thing I can see being an issue is most drivers pre-allocate the front buffer
airlied: but I've always wished that to be fixed
airlied: and it sounds like this work would do that
MostAwesomeDude: airlied: Yeah, it will...
airlied: then make cursors pixmaps and we have no non-pixmap allocs
MostAwesomeDude: I'm not talking about the part where EXA renders on each shard separately.
MostAwesomeDude: I'm talking about how to get each shard over to the scanout bits.
airlied: you call some the crtc mode setting function with a pixmap
airlied: so probably adding a pixmap ptr to the randr crtc structs
airlied: potentially you could hijack rotated pixmap
airlied: since really that is doing something very close to what you want
airlied: since rotation is scanning out an alternatice pixmap to the root one
MostAwesomeDude: Hm.
MostAwesomeDude: This is true.
MostAwesomeDude: This is actually an interesting idea.
DanaG: doesn't know what you're talking about, with "shards" and "shattering" -- all I can think of is glass. =þ
nanonyme: DanaG: Maybe they're plotting to do something about windows?
MostAwesomeDude: Hm.
MostAwesomeDude: So maybe add a PixmapPtr to xf86CrtcPtr, and co-opt shadow_{allocate,create,destroy}?
airlied: sounds like a plan, in fact you could probably push rotate out of the driver also
tpocra: I have a Radeon X1950... is radeon driver good enough to render Doom 3?
DanaG: That reminds me... ever see doom3 on a voodoo2 or a voodoo5?
airlied: MostAwesomeDude: it seems like with a pixmap allocate hint, rotate could all be done in the X server
tpocra: I can run Quake
adamk_: tpocra: If you run it with the ARB render path, yes.
DanaG: http://www.firingsquad.com/media/gallery_index.asp/244
airlied: MostAwesomeDude: but that might be pushing the boundaries :)
DanaG: naw, that link... now that is pushing boundaries.
biotube: Doom classic looks better than that
DanaG: =þ
MostAwesomeDude: airlied: Hm, will have to think on this.
nanonyme: biotube: Meh, iirc you couldn't even aim sanely in the original Doom. :/
biotube: nanonyme: you couldn't aim vertically
nanonyme: Exactly.
biotube: but then, that's what autoaim is for ;)
DanaG: A different game, Duke3D, had some very awesome capabilities for its time.
DanaG: Teleporters, conveyors, subway train thingies, and all sorts of stuff.
nanonyme: The first game I remember which had a proper aiming system was Quake.
biotube: Doom revolutionized nearly everything
biotube: can't blame the devs for not bothering with vertical aiming
nanonyme: Doom was mostly Wolfenstein 3D version 2.0 ;)
nanonyme: No real new innovations.
airlied: descent was the only true aiming :)
biotube: loves descent
biotube: nanonyme: no real innovations?
biotube: IIRC, wolfenstein enemies were idiots
nanonyme: So were Doom ones? :p
biotube: doom baddies stategerized
nanonyme: Heck, you have to go pretty modern to get enemies with decent AI.
DanaG: Another fun thing: squishing enemies in Duke3D.
DanaG: Made this nice disgusting stringy guts thingy from ceiling to floor.
nanonyme: Hehe.
nanonyme: (and by decent I meant enemies which run away and try to flank you instead of attacking you if they think they can't do it)
nanonyme: Attacking you up front even.
biotube: doom baddies were plenty deadly
biotube: they seemed to know how to gang up
biotube: unless they were attacking each other
nanonyme: It's one thing to have an enormous mass of monsters running at you and having intelligent enemies coordinating an attack.
boghog: had lots of fun with duke3d on my dads 486, slow as it ran
biotube: it's been entirely too long since I've played - I can't even remember if doom's monsters used cover
nanonyme: Heck, the intelligent enemies could even have inferior equipment to you and still be deadly unless you're good. ;)
biotube: the invisible bulls were tough
boghog: was duke3d actually true 3d like quake? i remember it had some weird texture mapping
danielhorne: IIRC, most of doom's enemies AI was less than a single page of code.
danielhorne: People just ascribed more complex behaviour to them
biotube: simple things can have complex behaviour
biotube: or at least deadly behavior :)
nanonyme: You can get killed by pretty much anything if you arm them well enough and have enough of them. Doesn't equal them being actually smart...
biotube: maybe I'm just being nestalgic
biotube: I even know what runtime error 200 is
nanonyme: (and it's pretty simple to arm them well if you're a game developer since you can just up their damage capabilities)
DanaG: google for eduke32 and "high resolution pack" -- it makes duke3 look almost modern-ish.
biotube: i suppose most of their intelligence comes from the little holes in the map
danielhorne: Someone did a ROTT-gl. windows only, I'm afraid
terracon: I like the doomsday engine
boghog: neat; http://www.eduke32.com/images/shots/hrp.jpg
biotube: did anybody port doom to 3d?
DanaG: ROTT had some pretty awesome weapons.
DanaG: Drunk Missile, Flamewall, and such.
biotube: god ahnd
biotube: s/ahnd/hand
danielhorne: dog mode!
nanonyme: Hmm, I wish Wolfenstein3D devs would have implemented a dog mode cheat that turns you into an angry doberman. ;)
DanaG: oh, and check out "voxelstein 3d" -- it's amusing.
danielhorne: Impressive
nanonyme: Okay, I think I'm getting disturbed enough to go to sleep.
DanaG: oh yeah, and they say you'll "never figure out what the cheat is" -- but all you have to do is look at the source code.
nanonyme: :P
danielhorne: Was a raytraced version of elite force, too
Kuaera: I have a R580 card and cannot get support for OpenGL 2.0. glxheads reports support for 1.3. xserver-xorg-video-ati version 6.12.1. Any direction?
DanaG: oh yeah, any of you ever use a FireMV card?
airlied: I've got one I'm "using" right now
DanaG: What are the GPUs in those things?
airlied: the one I have hs dual M9s
DanaG: I couldn't find a clear answer to that anywhere. ATI/AMD site sure doesn't say.
DanaG: M9 is mobility... what generation?
DanaG: I know the desktop names better than the laptop ones.
DanaG: Or rather, Rxxx numbers.
airlied: rv280
DanaG: ah.
DanaG: 9200-ish?
DanaG: googles it
airlied: 9000 I think
DanaG: google says it's 9200.
DanaG: Is that a PCI one you have, or a PCIe one?
airlied: PCI
airlied: I think the PCIE ones are PCIE1x any3ways
damentz: hey airlied or agd5f, how does Backing Store work in X?
damentz: it's off by default but improves 2d performance for me
damentz: but i'm not sure how it works
airlied: its magic that I ignore mostly
damentz: hmm, what do you mean?
airlied: http://tronche.com/gui/x/xlib/window/attributes/backing-store.html
damentz: ah, thanks!
damentz: this would not store it in video ram right?
airlied: its up to X, that is the magic bits I'm not sure about
damentz: i see
damentz: well it looks like it has the same features as exa actually
damentz: greedy, smart, always
damentz: and NotUseful, WhenMapped, and Always
damentz: that's a strange coincidence
damentz: haha
damentz: airlied, i don't believe this uses video ram
damentz: the common synonym to backing store is swap space
damentz: and backing store must use the WhenMapped attribute if set to the boolean of true
airlied: damentz: it won't care if it uses viudeoram
airlied: videoram is a driver idea
airlied: backing store is up in the server
damentz: hmm
damentz: so you mean it has access to use videoram if it wants?
airlied: I assume it just does something with pixmap
airlied: and doesn't destroy contents
damentz: i see
damentz: i think it's beneficial
damentz: i'm reading that it conserves window contents when it is obscured by something else
airlied: so does compositing
damentz: so that it doesn't need to be redrawn
airlied: running xcompmgr
airlied: will do the same thing
damentz: ah, so backing store is compositing for 2d
damentz: that makes sense
airlied: no its just with compositing you can't destroy obscured contens
airlied: because you don't know what obscured means anymore
damentz: hmm, so because of that
damentz: everything has to be preserved
damentz: in video ram preferably?
damentz: so really
damentz: in a fully composited desktkop, like i'm hearing with the wayland server - backingstore would be deprecated?
damentz: but until then, backingstore has some usefulness for 2d
DanaG: hmm, is it a good idea to enable backingstore? I never did figure that out.
damentz: it depends
Kuaera: I asked this several hours ago, but I'll try again, now that there are some active people about...
Kuaera: I have a R580 card and cannot get support for OpenGL 2.0. glxheads reports support for 1.3. xserver-xorg-video-ati version 6.12.1. Any direction?
damentz: i think with XAA it made a larger difference
damentz: with EXA i'm noticing less of a performance difference
damentz: but it's still beneficial
damentz: i've never noticed it slow anything down
damentz: some people claim that it slows 3d
damentz: but why should it, there is less redrawing
damentz: at the end of the day, you would probably use more cpu power from the algorithm behind it
airlied: Kuaera: no GL2.0 support
damentz: but these days, most computers are video card bottlenecked
airlied: damentz: with a comp manager you don't need backing store
DanaG: interesting: http://anandtech.com/video/showdoc.aspx?i=3602
damentz: right, but 3d performance overall is slower
damentz: so i keep it off since i often play games or running 3d things while using 2d things
DanaG: The only 3D thing I regularly use... is compiz. =þ
damentz: oh haha, i'm a gamer
damentz: i play many games through wine and a few high end ones that are native to linux
Kuaera: airlied: So there's literally no way besides fglrx to run OpenGL 2.0?
DanaG: Running synchronized to the vertical refresh. The framerate should be
DanaG: approximately 1/865889 the monitor refresh rate.
DanaG: lolwut?
DanaG: that's glxgears,
DanaG: damnit, now glxgears makes you do the math yourself.
vehemens: airlied: going to mars first. running texenv gives me the same thing for all of tests except the undefined decal ones.
DanaG: Granted, it's not meant to be a benchmark... but it'd be at least good for testing vsync!
DanaG: 276 frames in 5.0 seconds
DanaG: great... now I have to pull out a calculator.
DanaG: =þ
airlied: Kuaera: no
damentz: i think you guys should test gallium3d on the game Savage 2
damentz: it's free, and uses nearly all of the opengl features
Kuaera: That's actually the precise reason why I'm trying to get OpenGL 2.0 to 'work' :/
airlied: we'd have to write gallium3d first