Radeon IRC Logs For 2009-10-29
ajami: airlied: what was going wrong with the kernel? Why wasn't it "letting me boot"
airlied: ajami: not sure, lots of fixes for different things, probably a crash in new spread spectrum code
mart: Ghworg, http://www.two-kings.de/tutorials/dxgraphics/dxgraphics16.html similar to fbo's sure lot different at same time
happycube: mostawesomedude: here's a version of r300_emit_query_finish shortened by replacing the switch w/a for loop: http://pastebin.com/m1f3bc799
Ghworg: mart: From what I can tell from the wine source the textures I'm interested in (DXT1-5 or s3tc) just get passed straight through to mesa
Ghworg: Ah well, will just have to wait for someone who actually understands this stuff to fix the real bug
mart: s3tc was somekind of compression alghorithm, what about dxt what this stands for, render to texture?
agd5f: mart: dxt is s3tc, just the ms licensed version
agd5f: directx texture compression
MostAwesomeDude: happycube: I'm not totally sure if that's more readable, but it's quite clever. :3
happycube: thx :) (as for readability... i think the best hope's really good commenting)
MostAwesomeDude: Yeah, there's always a tradeoff between verbosity and complexity in code regardless of how many wall-o-text comments I put in there.
MostAwesomeDude: I mean, I laid the comments on *THICK* when I first wrote it all up, and it's still a jumble in some places.
soreau: dont you hate it when you find yourself back in the same place after a few months going (what the hell was I thinking)
happycube: this code's just intrinsicly complex... there're only so many ways to write a CS register sequence
soreau: and your comments dont even make sense to you ;)
happycube: yeah ;)
soreau: then it clicks, and you crack a crooked smile (clever dog you..)
MostAwesomeDude: I love some of my comments sometimes. :3
MostAwesomeDude: But I don't have very many good ones in r300g.
spstarr: tests today's mesa git
ajami: airlied: I think there may be an issue with r600_tex...http://pastebin.com/d645a8de1
ajami: airlied: or it could just be an issue with the game I am attempting to play. Not sure.
airlied: ajami: looks like r600 mesa bug
airlied: not really looking at those yet since they are experimental
mart: agd5f, need to take a look to which memory pool/framebuffer are they rendered adventually with opengl, compiz had that s3tc option too
mart: there is an open source toolkit for amd also, was something like close to metal, which may be interesting
MostAwesomeDude: I don't know why Compiz would use S3TC.
MostAwesomeDude: Also nobody does CTM.
airlied: MostAwesomeDude: it only uses it when you string random words together from reading 20 firefox links composited on top of each other
airlied: with like a 10% alpha
MostAwesomeDude: airlied: Ooooooh. I see.
happycube: lol
happycube: the CTM documentation is suprisingly similar to the r500 programming manual
happycube: ^ hopefully it got used to help r300 pre-amd-opening-up
MostAwesomeDude: Yeah, CTM was pretty much r500 fragment shaders IIUC.
MostAwesomeDude: But it wasn't really easily accessible until the r5xx manual got released.
happycube: and by then they'd moved on
happycube: also nv40_draw_elements ends with a flush. :P there's gotta be a better way tho.
happycube: (theirs is rather different, though... looks like it optionally flushes the texture cache and optionally sets up a fence)
mart: happycube, so it's good stuff then, cause r500 human readable context is needed to try programming/talking about stuff
happycube: not really - one could do something similar when gallium's finished around TGSI... and then you get something that works on more than one chip type ;)
mart: without screaming on the streets like an idiot trying to figure out , what which loop does, happens also very randomly to lot's of people who can't stick their penis to former girflfirends target buffer
happycube: "this is rocket science, not GPU coding."
spstarr: touches the bottom of his laptop case.... .. mmmm hot
spstarr: might be hot to begin cooking an egg
mart: constantly even so to speak, "..." years and years 10 and counting, so to start negotiating how to kill one of them off or slice throat with their own knives, and forward the kgb agents names to police departements "whith a pistol i carry that dude is a threat to john Kerrys whife"
Ghworg: My laptop runs ~10C hotter than it did under fglrx, it'll be nice when the powersaving stuff goes in and my fan can occasionally switch off
mart: airlied, how randmos is that? how long should i suffer , going into court with such absurds, until it hits you, or you land to your feets or someone here would understand, a faget like matthew garret? every fucking day, every single day same problems
DragonionS: hi all! I have a problem during trying to start Radeon driver with Gallium. I see cursor and screen is black.
DragonionS: What could it be?
MostAwesomeDude: All kinds of things.
MostAwesomeDude: Radeon Gallium drivers are still really really experimental and you shouldn't be surprised if they don't work.
DragonionS: thanks
DragonionS: for the answer
MostAwesomeDude: Are you trying xorg st or dri st?
DragonionS: what does it mean "st"? I have xorg-server 1.7.1, mesa, radeon, drm from git
MostAwesomeDude: Which part of Gallium are you trying out?
MostAwesomeDude: How are you running it?
soreau: MostAwesomeDude: While youre here, can you explain what xorg st is or the difference between it and dri st?
MostAwesomeDude: soreau: Sure!
hoo-hah: hi guys, any of you on gentoo with x11 overlay? seems I can't build mesa-9999.
hoo-hah: I'm trying to wgetpaste the portage log, but my net is shaped
hoo-hah: and it struggles to get uploaded
MostAwesomeDude: dri-st is the radeon_dri.so driver. It can be used to do GL.
soreau: For instance, I have gallium installed to nonstandard prefix and loading only certain gl progs by setting LIBGL_DRIVERS_DIR. Would it be any different if I were using xorg st too?
DragonionS: I've installed mesa with Gallium USE-flag that compile mesa with "enable-gallium-radeon" option
hoo-hah: I'll try uploading through ompload
MostAwesomeDude: xorg-st is the modesetting_drv.so driver. It can be used with Xorg to do regular 2D.
DragonionS: than I have the latest radeon driver from git
amarks: hoo-hah: what is the build failure?
hoo-hah: http://omploader.org/vMm5kOA
DragonionS: I am loading ttm driver from kernel
MostAwesomeDude: DragonionS: What programs are you trying to run? Just X?
DragonionS: no, gnome
DragonionS: :)
MostAwesomeDude: Hm.
hoo-hah: from the log, gmake[5]: *** No rule to make target `compiler/libr300compiler.a', needed by `r300_dri.so'. Stop.
MostAwesomeDude: Could you pastebin your Xorg.0.log?
amarks: hoo-hah: yes i am on gentoo, i have hit this issue since brian paul changed the makefile
amarks: hoo-hah: do you need r300?
hoo-hah: nope
DragonionS: wait a bit - I'll switch to gallium...
amarks: hoo-hah: then remove r600 from the ebuild and rebuild the manifest
amarks: sorry
amarks: r300
hoo-hah: wait. I think i need r600
hoo-hah: ah, kay
amarks: hoo-hah: it is something gentoo specific as mesa git compiles file manually
amarks: s/file/fine
soreau: MostAwesomeDude: So.. Would it make any difference if I were using xorg st too? (for progs using r300g)
hoo-hah: amarks: ah cool. I've never taken a look inside the ebuild
hoo-hah: amarks: do you reckon that I can remove other chipset support while i'm there?
hoo-hah: all I'm after is r600 support
amarks: hoo-hah: you can, i did not
hoo-hah: or does this mean I'll need to modify the other 2 ebuilds
MostAwesomeDude: soreau: Yeah, xorg-st is a lot less tested and possibly broken w/dri-st.
soreau: MostAwesomeDude: That is to say, it would make a difference. It would be worse. (?)
amarks: hoo-hah: just edit the driver_enable video_cards line
hoo-hah: yeah
MostAwesomeDude: soreau: Yeah, probably.
soreau: ok thanks for clarifying
soreau: I will probably try it anyway ;)
MostAwesomeDude: DragonionS: Hm. Looks like your X server's not using Gallium directly, so it should work fine.
ajami: airlied: so what exactly is this new spread spectrum code?
DragonionS: thanks for the answer. I wish you good luck in your work and as ATI user. ;)
blueldr137: hi
blueldr137: does anyone here use a X1600 card?
blueldr137: glxinfo can't identify my chip id, and therefore puts me in indirect rendering :(
blueldr137: would installing the latest 'xserver-xorg-video-chips' package allow my chip to be identified?
MostAwesomeDude: That's for a Chips video card, actually. :3
MostAwesomeDude: xserver-xorg-video-ati is what you want.
blueldr137: oh lol :P
MostAwesomeDude: Also, for 3D, you're going to need to update Mesa; IIRC it's called "libgl-mesa-dri" on Debian.
blueldr137: ok
MostAwesomeDude: You *are* on Debian, right?
blueldr137: yes
MostAwesomeDude: Stable, or testing?
blueldr137: stable
MostAwesomeDude: Ah.
MostAwesomeDude: Could you pastebin the output of "LIBGL_DEBUG=verbose glxinfo" so I can be sure I'm not misleading you? :3
blueldr137: sure... my deb version is lenny too
blueldr137: http://paste.debian.net/50241/
blueldr137: thanks
MostAwesomeDude: Yeah, Mesa's just too old, that's all.
blueldr137: so I just need to update 'libgl-mesa-dri' and not 'xserver-xorg-video-ati'?
MostAwesomeDude: Oh, wow. Lenny's libgl1-mesa-dri is version 7.0, that's ancient.
MostAwesomeDude: Yes, with the caveat that you're going to have to pull it from squeeze. :3
MostAwesomeDude: $ aptitude -t squeeze update libgl1-mesa-dri
blueldr137: ok... squeeze is the upcoming deb release right?
MostAwesomeDude: Or something along those lines; haven't done Debian in a bit.
MostAwesomeDude: Yeah, squeeze is current testing.
blueldr137: ok I'm sure I'll be able to figure it out now lol
blueldr137: thanks
blueldr137: I'll try to update it now :)
hoo-hah: urgh
hoo-hah: who was I chatting with earlier regarding gentoo ebuild?
hoo-hah: (lost my irc session log)
hoo-hah: are the latest mesa xf86-driver-ati and libdrm dependent on xorg-server 1.7+?
hoo-hah: I remember getting dri2 for my r600 card working with xorg 1.6.x
hoo-hah: xorg log at http://dpaste.com/113608/
airlied: ajami: spread spectrum is used on laptops to make the LVDS not interfere with other things
hoo-hah: ah, nmv
hoo-hah: *nvm
hoo-hah: turns out it was due to evdev module having to be rebuilt
hoo-hah: with 1.7.1 xorg upgrade
amarks: hoo-hah: yes that is necessary with any major upgrade
hoo-hah: amarks: I always thought it'd be taken care of with xorg-server upgrade
hoo-hah: does this mean I'll need to explicitly upgrade any input modules I'm using (mouse,kbd)?
amarks: hoo-hah: yes, typically you rebuild all x11-drivers
amarks: hoo-hah: or update to the latest
amarks: hoo-hah: mouse is 1.5.0, keyboard is 1.4.0 and evdev is 2.3.0
hoo-hah: yeah, that's available with ~amd64
hoo-hah: (what I'm running)
amarks: sometimes this happens as part of the dependencies, sometimes not
hoo-hah: I just didn't expect to have to manually rebuild. evdev now appears in world
amarks: when u emerge xorg-server it will warn you
hoo-hah: amarks: does your world file contain those input drivers you've installed?
amarks: absolutely
hoo-hah: odd. I thought they'd just get puleed in as dependencies based on what's in make.conf
amarks: they are separate packages, why wouldn't they show in world?
hoo-hah: dunno. I've had problems with dependencies ending up in world, that should have not been there
hoo-hah: I'm sking in #gentoo to be sure
amarks: hoo-hah: why do you care if it's in world or not?
hoo-hah: amarks: if the driver rebuilds ideally should be done as oneshot
amarks: hoo-hah: i've never used oneshot really, i'm not across why it is necessary
amarks: hoo-hah: i.e. for most stuff, you want it recorded so it can be updated
ajami: airlied: that error I showed you earlier the r600Delete? that issue is causing a lot of problems actually. These stemed from the latest master.
ajami: Everything requiring OpenGL as far as I can tell if getting a segment fault. I try opening comiz, segment fault. Glxgears, segfault.
ajami: if->is
ajami: agd5f, glisse, airlied, anyone working on r600 classic ^^^
ajami: and now I am getting either gpu hardlocks or kernel deaths. I just had to hard restart my comp. Anything I can do to help narrow this/these issues down, let me know.
ajami: VLC using Xv hasn't had any issues. Heck 720p playback actually works flawlessly on my computer now. Never, not with propriotary drivers, fglrx/windows, has my comp been able to do so.
honk: that's pretty poor :}
twoerner: glisse: 4G does not fix my poblem
twoerner: glisse: to have only 4G does not fix my problem
DJJeff: ATI T200 Unified AVStream Driver has a yellow sign
DJJeff: whats the best fix?
Nightwulf: hi all
glisse: airlied: your patch post pone corruption
glisse: got them now after 2h or desktop usage
glisse: this thing is painfull to debug
agd5f: ajami: make realclean and re-install
agd5f: glisse, airlied: regarding the font corruption, have you tried adding an HDP cache flush when mapping/unmapping a bo in vram?
glisse: agd5f: good idea :)
glisse: i need to stop working on 3 differents things a the same time
agd5f: glisse: yeah, me too
spreeuw: hmm any idea why my 3d fullscreen windows are not fullscreen? they are centered 1:1
spreeuw: and slightly darker too than they should be
agd5f: spreeuw: laptop?
spreeuw: no an eizo tft
spreeuw: on a 3450 pcie
spreeuw: it started after I updated my xserver to the current stable
spreeuw: no errors in the log
agd5f: spreeuw: xrandr --verbose and check what scaler is set to
spreeuw: scaler: off
spreeuw: in 2d desktop
agd5f: spreeuw: what res is the 3d app trying to switch to?
spreeuw: 1280x960 which is available in xrandr
agd5f: and what's your monitor's native res?
spreeuw: native is 1920x1200
spreeuw: current
spreeuw: does tha texplain the sclaer off atm?
agd5f: spreeuw: does xrandr --output