kickar: hey guys i have a driver problem
kickar: anyone can assist me ?
marvin24_: cool, wz2100 is working on r600
raevol: marvin24_ i totally thought you were talking about a person haha, glad i googled it
marvin24_: raevol: ok - the game is a little old, but I liked it
raevol: i'll check it out, thanks
Nightwulf|work: hi all
EruditeHermit: what is required to build libdrm-radeon1
EruditeHermit: what is the option
EruditeHermit: --enable-radeon-experimental-api
mikkoc: glxgears still broken with git: http://pastebin.ca/1545533
marvin24: mikkoc: what's in dmesg? you may need an updated libdrm_radeon and radeon module
mikkoc: i just compiled everything from git
mikkoc: nothing special from dmesg
mikkoc: http://pastebin.ca/1545555
marvin24: works here with rs780
mikkoc: i have 785g tho
marvin24: mikkoc: should be no difference, restarting X might help
mikkoc: i rebooted
masa-: which dri-drivers should i specify when compiling mesa? radeon,swrast,r300,r600 maybe?
masa-: i want to test the current code myself on X600 and HD4350
marvin24: masa-: X600 -> r300, HD4350->r600
marvin24: (man radeon)
masa-: so do i need the swrast and radeon parts?
MrCooper: radeon no, swrast only when there's a problem with the HW drivers
marvin24: masa-: with "man radeon" I meant the man page of radeon(4)
masa-: yes i know, but i just wondered what the radeon option is to --with-dri-drivers=
nanonyme: Well, just radeon there implies r100, I think.
masa-: the radeonBuildHowTo had radeon,r200,r300
masa-: ok
nanonyme: radeon,r200,r300,r600 builds for all generations.
masa-: right
masa-: so i'll pick r300,r600,swrast
nanonyme: Sure.
masa-: so is this new 3D r6xx code working with or without KMS or both?
marvin24: masa-: no KMS for r6xx yet
masa-: ok
masa-: what about r300?
airlied: the 3D driver actually sorta works under kms on r600
airlied: just not for very long
masa-: hehe :)
airlied: once we solve the issues in the kernel it might actually not need major work
nanonyme: Also the Mesa code should be with and without KMS, technically, I think.
masa-: so it's some kernel and/or drm thing?
nanonyme: Likely mostly.
masa-: hmm, what kind of stuff is in 1) kernel (itself?), 2) drm modules, 3) libdrm
airlied: drm modules are the kernel
airlied: we don't do kms stuff anymore with external tree
masa-: so if i build the agd5f drm modules, what kernel should i be using?
nanonyme: Shouldn't matter. They become part of the kernel you compile them against.
nanonyme: (Modular design)++
masa-: ok, i'll then build the latest -rc
masa-: hm, mesa didn't compile :/
masa-: radeon_screen.c: In function ‘radeonCreateScreen’:
masa-: radeon_screen.c:1049: error: ‘R600_SCRATCH_REG_OFFSET’ undeclared (first use in this function)
airlied: new libdrm
airlied: or kernel-headers
masa-: i just compiled libdrm from git, but will the mesa build find it because it's in /opt/xorg?
nanonyme: If you're using the same prefix for Mesa, easily, otherwise you have to setup include paths.
nanonyme: (setting library paths in that case is a good idea too)
masa-: yeas i have /opt/xorg for all the testing stuff i'm compiling
nanonyme: In any case, should be defined in radeon_drm.h.
masa-: i have only linux-headers 2.6.27-r2 installed, should i install 2.6.30-r1 which is the latest in portage?
masa-: and what is in those headers anyway, doesn't it come with kernel sources?
nanonyme: Should.
masa-: ./src/gallium/winsys/drm/radeon/core/radeon_drm.h ?
nanonyme: Sounds irrelated.
masa-: that's the only one find gave me
nanonyme: Well, it it shouldn't be under Mesa's sources so that's not entirely unexpected.
masa-: oh, so my bad..
masa-: where should it be?
nanonyme: DRM sources.
masa-: hmm... how should mesa build find it then? should i put the drm directory under mesa?
nanonyme: Didn'y you just say you installed the stuff under /opt/xorg?
nanonyme: s/y/t/
masa-: yes
masa-: ah
masa-: there is include folder which has it..
nanonyme: Bingo. ;)
masa-: ok i thought the drm source folder :p
masa-: stupid me
nanonyme: Btw, you did install libdrm from git, right?
masa-: yes
masa-: the dile /opt/xorg/include/drm/rdaeon_drm.h has the define that mesa is complainig about
masa-: s/dile/file/
masa-: and the other typo.. :p
masa-: and the third.. :D
masa-: gg
algol: what does the acronym CS stand for? (e.g. in struct drm_radeon_cs)
airlied: command submission
JohnDoe: Counter-Strike :) ?
algol: airlied: thanks
masa-: "Run 'gmake' to build Mesa"
masa-: gmake and not make?
nanonyme: It's the same on Linux, me thinks.
nanonyme: On non-Linux specifically gmake.
nanonyme: gmake Makefiles have commonly stuff that unix make can't handle.
masa-: right, running amke and it prints out gmake[n] lines
nanonyme: Nowadays guideline seems to mostly be "use GNU or cry".
scarabeus: well most distros ship make == gmake anyway
masa-: hmm what... it enters dri/r300 and then fails with ‘R600_SCRATCH_REG_OFFSET’ undeclared
nanonyme: It's used in a common file.
masa-: right
nanonyme: scarabeus: Linux is not the entire world.
nanonyme: Since what you actually said was "most Linux distros ship make == gmake".
scarabeus: i nevel feel the urge to compile mesa on lets say hpux
masa-: autogen reported the correct prefix /opt/xorg so it should be able to find the header, and at least it didn't complain about missing header..
masa-: or it didn't fail with that error
nanonyme: I doubt even BSD's ship gmake as make.
nanonyme: masa-: If the prefix doesn't work, tweak include and library paths appropriately.
scarabeus: well i think bsd should more complain about that drm is developed directly in-kernel rather about that they have to use gmake :]
nanonyme: scarabeus: I didn't say that was their main concern, I just said in most *nixes it's is an invalid assumption that make == gmake.
scarabeus: ok, in that you are correct
masa-: nanonyme: but shouldn't it fail if it doesn't find a header that gets #included?
nanonyme: masa-: Well, at worst it's pulling headers from /usr/include/.
nanonyme: You have duplicates of your headers.
nanonyme: Also remember to run make clean every time before running make to clean up garbage from last time.
nanonyme: (or at least after the last time resulted in breakage)
masa-: i just did that, but it failed again
nanonyme: You might have to play with CFLAGS and LDFLAGS then to get it to detect the right headers and libs.
nanonyme: (unless it's using pkg-config somewhere to get the header paths)
nanonyme: Ah.
nanonyme: It probably is.
masa-: err..
nanonyme: There's LIBDRM_CFLAGS and LIBDRM_LIBS for overriding pkg-config.
nanonyme: Actually since you likely wanted KMS for r300, LIBDRM_RADEON_CFLAGS and LIBDRM_RADEON_LIBS.
algol: looking at radeon_fence struct I see that there's a comment about a lock protecting the inner list
nanonyme: masa-: You didn't install pkg-config under /opt/xorg, right?
algol: /* protected by radeon_fence.lock */
masa-: nanonyme: i didn't install pkg-config period :)
nanonyme: masa-: Then it's using headers and libraries outside the prefix.
algol: but there's no lock in struct radeon_fence, there's one in radeon_fence_driver
masa-: [I] dev-util/pkgconfig Available versions: 0.21-r1 0.22 0.23
nanonyme: It's using your system pkg-config which gives it your system include and lib dirs. You need to override.
algol: possibly the comment is referring to this lock?
masa-: err what? there are several pkg-configs?
nanonyme: You can have one in every prefix. :)
masa-: huh
nanonyme: Mesa is heavily relying on pkg-config in configure so you have to manually override the paths when pkg-config is giving unwanted ones.
masa-: so i should install one pkg-config instance to that prefix?
nanonyme: No, it will likely break worse.
nanonyme: Just override the paths.
nanonyme: Using LIBDRM_RADEON_CFLAGS and LIBDRM_RADEON_LIBS environmental variables.
masa-: ok..
nanonyme: You did install the libdrm from git with --enable-radeon-experimental-api, right?
masa-: yes
nanonyme: Yeah, those are the variables to use then.
algol: yep, reading the code it seems that this is the case.
nanonyme: masa-: You know how to use CFLAGS and LDFLAGS, right?
masa-: eh..
masa-: well i exported LIBDRM_RADEON_LIBS=/opt/xorg/lib
nanonyme: Okay, so no.
masa-: not sure what i should put to CFLAGS?
masa-: right..
masa-: well this is going nicely :<
nanonyme: Probably something along the lines of LIBDRM_RADEON_CFLAGS=-I/opt/xorg/include/drm and LIBDRM_RADEON_LIBS="-L/opt/xorg/libs -R/opt/xorg/libs" but unsure
nanonyme: I just install over system libraries. ;)
nanonyme: s/libs/lib/g
serrghi: i have mob x1600 card, using radeon driver. But i cant get wc3 (warcraft 3) or any other 3d application to run. it runs with about 2fps :/ any tips?
nanonyme: Pastebin glxinfo |egrep "(render|version)" ?
serrghi: http://pastebin.com/m5fa02eca
nanonyme: Could try with a newer Mesa drivers.
nanonyme: s/drivers/driver/
nanonyme: serrghi: You aren't running Compiz, right?
serrghi: no.
serrghi: hm, which mesa version is the newset?
serrghi: i have mesa 7.5 installed..
nanonyme: Yeah, I noticed.
nanonyme: I'd try Mesa from git to see if it runs better.
nanonyme: There might be some people shipping snapshots for your distro.
serrghi: one question though. i see R300 is used by Radeon 9500-9700
serrghi: is there a way to force the usage of a different driver?
nanonyme: No point really since R300G isn't yet done.
serrghi: but according to mesa's wiki x1600 is supposed to use rv5xx
nanonyme: You read wrong.
serrghi: :(
serrghi: damn ati!
nanonyme: Hmm?
nanonyme: serrghi: ATi has nothing to do with Mesa doing a joint driver for chipset families... Well, unless you count in that they designed the chipset families.
nanonyme: Yeah, leaving is always the smartest thing to do.
algol: I'm not sure I understand the fence mechanism in the DRM. The fence_driver gets a scratch register that is written with seq when the fence is emitted.
algol: but what does the GPU do with this value?
maleadt: Hi, I'm getting a backtrace in dri (http://pastebin.com/d58aebddd) when running the newest software (mesa ddx etc from git, kernel 2.6.30, drm from agd5f's branch) on r700 hardware. Should I trace faulty commit & open a bugreport, or is this known already?
nanonyme: algol: Some vague understanding/recollection tells me it's related to waiting.
nanonyme: (but not waiting as in kernelspace waiting for the card but instructing the card itself; collect an accurate description from your local developer :p)
suokko: config fail :/ Somehow my mesa and ddx gets linked against system libdrm_radeon
suokko: or at leastddx does
Terman: agd5f: what was the change again to get git xf86-video-ati to compile for kms?
suokko: Terman: You need to build libdrm with --enable-experimental-api
Terman: suokko: sure, I just always forget which patch is necessary to get it compile
Terman: ../../src/radeon_dri2.c:205: error: ‘struct
suokko: /DRI2BufferPtr/DRI2Buffer2Ptr/
Terman: suokko: ah, yes, thanks!
Terman: I added it to my compilation notes now, so it doesn't matter if I forget about it again
nanonyme: The fact that it hasn't been fixed in ddx would imo hint towards plans that would make the fix unnecessary.
suokko: Terman: You could commit it to your local repository and the just do fit fetch && git rebase origin when updating it
nanonyme: Possibly an ABI change in X server 1.7.
Terman: suokko: I understand too little about git to be comfortable with something like that: I did something like that in the past with some other repo and then ended up deleting the whole repo and cloning it again
suokko: Terman: and in git you can always do git checkout -b new_master origin/master to get rid of local changes
suokko: And possible problem with local commit is that you get conflict and don't notice it
MrCooper: nanonyme: it builds and works for me with xserver Git... if someone understands the problem with xserver 1.6.x, a patch would be appreciated
suokko: MrCooper: Is there some standardway to detect which xserver we are building against?
MrCooper: there are version macros e.g., maybe take a look at what the intel driver does
suokko: I think that problem can be fixed with one typedef
suokko: and #if
kdekorte: nanonyme, have you rebuilt mesa today and if so are you seeing the problems with xmoto yet?
jcristau: suokko:
suokko: kdekorte: Can you get piglit and run glean/scissor test there?
suokko: I hate autotools! They jsut can't ever work way that I want :/
kdekorte: suokko, where can I get piglet from
suokko: http://cgit.freedesktop.org
suokko: airlied: Can we get CP_PACKET1 to accepted packet formats for kernel?
kdekorte: suokko, piglet wont compile
suokko: kdekorte: http://nopaste.com/p/amrrg0WcN
suokko: And you need to add typedef to half float
kdekorte: patch doesn't apply
kdekorte: I see why
suokko: I have old version
suokko: typedef unsigned short GLhalfARB;
suokko: That should go to glwrap.h
kdekorte: suokko... ok finally got it to run
kdekorte: Everything fails
kdekorte: for the scissor test
suokko: Can you upload the result?
kdekorte: the result file? or the output?
suokko: result fail has useful info often
suokko: and it can be turned to html file
kdekorte: The result file http://nopaste.com/p/aTIp1s66lb
kdekorte: The output of glean http://nopaste.com/p/aLzRDE20ab
nanonyme: MrCooper: Someone wanted to add a new element into DRI2BufferPtr but this change was reverted because it broke the ABI for 1.6 which isn't allowed. The solution was to have the new ABI in DRI2Buffer2Ptr and offer a legacy one in DRI2BufferPtr.
nanonyme: As far as I've understood.
nanonyme: However, there's no reason for not breaking the ABI with 1.7.
MrCooper: I know, but this doesn't explain why it works with xserver Git
nanonyme: It does.
MrCooper: nope
nanonyme: Git master is the thing that will become 1.7, isn't it?
suokko: http://nopaste.com/p/aUxH23K6V
nanonyme: So if it works with git master, it would just imply that X server 1.7 will have the ABI change for DRI2BufferPtr.
suokko: oop. this one http://nopaste.com/p/aZ1O8V6zob
nanonyme: Works, I guess.
marvin24: what's the meaning of:
marvin24: File r300_swtcl.c function r300_swtcl_flush line 671
marvin24: Rendering was 38 commands larger than predicted size. We might overflow command buffer.
marvin24: ?
nanonyme: suokko: Though wouldn't just definining DRI2Buffer2Ptr to be DRI2Buffer2Ptr for X server smaller than 1,6,99,0,0 have sufficed?
nanonyme: Erm.
nanonyme: DRI2BufferPtr to be DRI2Buffer2Ptr even.
suokko: nanonyme: That is sure way to break stuff later
nanonyme: Maybe.
suokko: marvin24: That means there is emitted something more than prediction code knows about
marvin24: suokko: ok, I can read - can this cause problems/crashes?
suokko: marvin24: crash is possible
suokko: What application you did run?
suokko: kdekorte: It looks like scissors are never set for you
kdekorte: suokko, they worked fine prior to 82ff3190de3cd6cf4a514bac00ae02597abfb963
kdekorte: and I can revert that and they work fine again
kdekorte: airlied gave me a couple of things to try late last night (for me), but none of them worked
kdekorte: running make realclean and make again to see if it is something here, but don't think so
suokko: kdekorte: is ctx->DrawBuffer defined there ?
nanonyme: kdekorte: Did you pull latest commits?
nanonyme: airlied pushed a fix upstream for scissors.
kdekorte: nanonyme, yea I have latest it doesn't work
nanonyme: Strange.
nanonyme: Wonder what makes it not work for you but makes it work for me.
kdekorte: I've rebuilt everything clean
suokko: kdekorte: frpintf(stderr("%d.%d %d-%d\n",x1,x2,y1,y2); near to clamping
suokko: and let see if they are ever even set
suokko: and we could even compare to values when patch is reverted
kdekorte: suokko, did that last night and they did seem to be set
suokko: Whatwas difference to reverted patch?
kdekorte: Drawbuffer is not null
marvin24: suokko: glxgears
nanonyme: kdekorte: Did you also also put the old way of calculating them back so you could compare the rectangles?
kdekorte: no I did not
kdekorte: I should
kdekorte: give me a few mins
nanonyme: If you have them both in, could at least tell where it goes wrong.
marvin24: suokko: still a bug in the swtcl patch
nanonyme: suokko: Did you mean comma instead of (?
suokko: marvin24: yes. Can you recompile mesa so that you have changed DEBUG_CMDBUF to 1 in radeon_comon.c? And then run RADEON_DEBUG=all glxgears 2> debug.log ?
suokko: nanonyme: yes
nanonyme: suokko: Any idea if it is impossible for libdrm vs libdrm_radeon differences to affect scissors?
suokko: If it changes what will be emitted to gpu
nanonyme: Hrm.
suokko: Like if in legacy code somehow the last dword is overwritten or something like that
marvin24: suokko: http://nopaste.org/p/avdFPeLZbb
suokko: marvin24: thanks
suokko_: marvin24: Can you give me link to text version of the paste?
marvin24: suokko_: you mean: http://nopaste.org/p/avdFPeLZbb/txt
kdekorte: suokko, I think I have some good data here... and the new calcs are definitily off
suokko_: kdekorte: Which values have changed?
kdekorte: the x and y values are all lower... they are all wrong
kdekorte: old method 792 228 809 264
kdekorte: new method 783 140 799 175
kdekorte: it appears the new values are not accounting for the drawables x,y offsets
nanonyme: So in the first delta(x) = 17, delta(y) = 36, second delta(x) = 16, delta(y) = 35
kdekorte: priv 9 88
kdekorte: old method 792 228 809 264
kdekorte: new method 783 140 799 175
nanonyme: Off by one.
kdekorte: output is x1,y1,x2,y2
nanonyme: Old values have consistently deltas bigger by one than the newer ones.
kdekorte: priv is drawable x and drawable y
kdekorte: yeah the off by one is an issue too
nanonyme: No, there actually isn't any other issue, probably...
suokko_: so new values are one smaller than old?
nanonyme: Deltas are, yes.
kdekorte: yes... and pretty much by the x,y values in the drawable
suokko_: btw, gpm is nice package if you break your xserver ;)
nanonyme: Mostly the only useful data in the scissor coordinates as far as I've understood is the deltas. :)
kdekorte: suokko_, I think I'll have a patch here in a minute
nanonyme: Since those give the height and width of the rectangle.
suokko_: kdekorte: btw, You can't ouch the common code because it willbreak all odler generations
nanonyme: kdekorte: Are you absolutely sure you compiled with this commit? http://cgit.freedesktop.org/mesa/mesa/commit/?id=a7f8b329aa75f9a34d31d01b5bf6094b764bd8a9
suokko_: They work well with that code
kdekorte: nanonyme, pretty sure
nanonyme: It's *exactly* the fix for the off-by-one issue.
kdekorte: it is not off by 1... it is off by much more
nanonyme: Yes, it is.
nanonyme: 17-16=1, 36-35=1
kdekorte: how is 792-783 an off by 1?
nanonyme: That's irrelevant.
kdekorte: 792 is the old method, 783 is the new method
nanonyme: You can't compare absolute coordinates.
nanonyme: The new and old values don't directly relate to each other but their deltas do.
kdekorte: ok reset git... again
nanonyme: As in oldx2 - oldx1 is supposed to be the same as newx2 - newx1.
kdekorte: everything looks right at to the git patches
nha: ... because absolute coordinates depend on where your window is, and that's not deterministic
suokko_: marvin24: Are you suer you have the latest mesa?
kdekorte: scissors are screwed
nanonyme: nha: Thank you. :)
nha: kdekorte: r600?
kdekorte: yes
nha: k, just making sure
marvin24: suokko_: mmh - 30 minutes old
kdekorte: suokko_, ok I have an r700 only patch that fixes the scissors
nanonyme: scissors aren't broken for my rv670. :P
suokko_: ok. log just looks like from code before 570d4e375a327787441c2c7c4ae698e8993a5d6b
kdekorte: http://nopaste.com/p/aXJW2kpPC
kdekorte: how about that?
kdekorte: nanonyme, can you try that patch
nanonyme: As I said, they work for me as is.
kdekorte: nanonyme, can you try with the patch and see if it breaks it for you...also when you run xmoto is it in the top left?
nanonyme: Testing whether a hack breaks them sounds a bit silly to me.
nanonyme: Is what what? :p
kdekorte: no not really if you are running xmoto fullscreen you won't see the issue.. it affects scissors in a window
nanonyme: Ah, you didn't at any point say it's specific to it being in a window.
kdekorte: I'm just using xmoto default setup... so never occured to me till right now
suokko_: kdekorte: ok. i wonderif dri1 scissors are also broken for older cards
kdekorte: the piglet tests still all fail...
kdekorte: but display looks right
suokko_: kdekorte: It is off-by-one
kdekorte: positive or negative?
suokko_: -1 to x1 and y2 probably
kdekorte: nop... got them all to pass now
suokko_: good
suokko_: So I wouldguess dri1 might be broken forall cards
kdekorte: http://nopaste.com/p/a9Dx7EvT4
kdekorte: airlied, said they were working... I only have an r600 to test with... so just giving you what I have
nanonyme: is still puzzled why it works in full-scren but not in window4
kdekorte: nanonyme, so if you don't run xmoto fullscreen do you see the error?
kdekorte: try with my patch
nanonyme: Lemme see.
suokko_: nanonyme: drawable start from 0 in fullscreen
kdekorte: nanonyme, yup agree with suokko_
kdekorte: suokko_, you see the same issue on your cards?
suokko_: kdekorte: I have broken my X so I'm using console only
kdekorte: crud... was hoping you would see it on non-r600 so that it could be determined if it should go into radeon_common or not
nanonyme: kdekorte: I get a hunk failed.
nanonyme: Agh, stupid me.
nanonyme: Lemme try again.
suokko_: nanonyme: Can you test r300 dri1 if scissors are brokenthere too?
nanonyme: Well, still doesn't apply though.
nanonyme: suokko_: Good point, thanks for reminding. Forgotten I have a laptop with rv350. ;)
kdekorte: I have a feeling it needs to go into radeon_common UpdateScissor
nanonyme: Possible.
kdekorte: The more I look at it, the more wrong updateScissor looks to me since it doesnt account for the drawable location
nanonyme: airlied said he pretty much used what Intel did.
kdekorte: And their driver works so well?
suokko_: intel doesn't support dri1
nanonyme: suokko_: Iirc you commented on the double decrementation yesterday?
suokko_: That was what airlied did fix yesterday
nanonyme: In one place.
nanonyme: Or actually several places but not where you commented. :)
nanonyme: Namely http://cgit.freedesktop.org/mesa/mesa/commit/?id=d0cb1036aa98d35ae5233d326fbb0ba592a26e26 and http://cgit.freedesktop.org/mesa/mesa/commit/?id=a7f8b329aa75f9a34d31d01b5bf6094b764bd8a9
suokko_: http://nopaste.org/p/aPrHkFe9P
kdekorte: ok, I have an ALTERNATE patch that is common
suokko_: That might work fordri1 for all cards
suokko_: :)
nanonyme: That's an interesting call.
kdekorte: http://nopaste.com/p/a1cNTz3m3
kdekorte: anyway, maybe someone like agd5f can make a call on the better scissor patch... I've done what I can
kdekorte: Anytime you need a +1 or a -1 usually something is wrong someplace else
kdekorte: BTW, all the piglet tests pass with my second patch as well
nanonyme: kdekorte: You might be breaking DRI2 though. suokko_'s patch is careful to only affect DRI1.
nha: it's piglit :P
nanonyme: We wouldn't know since we have no r600 DRI2.
nanonyme: nha: I wasn't referring to piglit. :)
kdekorte: nanonyme, true... but I have no way to test.. that is why I was looking for someone not on r600 to run xmoto in a window to see if the buttons showed up
suokko_: marvin24: I think I found the bug http://nopaste.org/p/aAjwH2Y63
kdekorte: if they don't it is a scissor issue
suokko_: But y patch doesn't work
suokko_: I just noticed the problem that clamping is wrong
nanonyme: kdekorte: There's actually two things we'd want to test with non-r6xx/r7xx users. 1) is there an issue for them with DRI1 2) is there an issue for them with DRI2.
kdekorte: nanonyme, well I'll leave it up to the maintainers now... I've given what looks right and works for me
nanonyme: Right, can't test. My Fedora Rawhide is a tad broken on the laptop atm.
suokko_: http://nopaste.org/p/aYuyHKJyo <- This should make dri1 and dri2 scissors happy
suokko_: I guess I have tofix my X now
suokko_: Especially because I already hate screen for missing features
nanonyme: curses
nanonyme: radeon_common.c:243: error: ‘GLcontext’ has no member named ‘Drawbuffer’ # how interesting...
nanonyme: Ah, it's probably Dr_Jakob's drm_api change he said he'd do.
MrCooper: nope, radeon_common.c is not in the Gallium tree
nanonyme: I know...
nanonyme: Wonder what changed then.
nanonyme: And yeah, you're right.
MrCooper: Drawbuffer looks like a typo for DrawBuffer
suokko_: yep
suokko_: typo
suokko_: nanonyme: /b/B/
kdekorte: suokko, yup that works here too
kdekorte: but I would suggest instead of the kernel_mm you might think about !radeon->radeonScreen->driScreen->dri2.enabled
suokko: kdekorte: They are synonyms
kdekorte: the rest of the code uses the dri2.enabled check so just for consistancy
nanonyme: MrCooper: Blah, stupid me.
nanonyme: The same symbol was used on a different line, just didn't spot it.
rnoland: notes that r600 is rather broken right now...
rnoland: i might need to reboot though...
kdekorte: suokko, do you have rights to commit that patch or do we need someone else to do it?
suokko: kdekorte: I have to first test that I didn't cause any off-by-one errors
suokko: And that requires me to clean my self compiled libdrm/mesa that had broken changes
kdekorte: piglet fails with your patch
suokko: Off by one I guess
kdekorte: suokko, you need a +2 on the max_x and max_y in the dri1 area
kdekorte: then piglet passes
kdekorte: not +2 , but +1
suokko: kdekorte: thanks
nanonyme: I wonder where the difference comes from.
kdekorte: nanonyme, from the block above it...
kdekorte: I think in dri1 it is drawable x + startx + endx and in dri2 it is startx + endx - 1.. but just a guess
suokko: It seems to me that there is difference in dri1 and dri2 how buffer size is reported
nanonyme: suokko: Very likely.
suokko: I still have some scissorsfailures in dri1 :/
kdekorte: suokko, which card?
suokko: r200
kdekorte: that one might need a +1 or -1 somewhere...
kdekorte: did you add the +1 to the max_x and max_y already?
suokko: yes. it looks like stencil clear path is broken
marvin24: suokko: there is an error in your patch (rmesa not defined), can I move the definition to the start of the function?
suokko: marvin24: yes
marvin24: suokko: well, I moved the if() below the definition, but nothing changed :-(
marvin24: maybe I need to restart X ?
suokko: marvin24: There is no need
suokko: You can test .progs/demos/gears to make sure
suokko: But I think I found one more problem in that
marvin24: same
kdekorte: marvin24, can you post the error?
marvin24: File r300_swtcl.c function r300_swtcl_flush line 671
marvin24: Rendering was 38 commands larger than predicted size. We might overflow command buffer.
kdekorte: marvin24, I can give you a patch to try
kdekorte: marvin24, try this one http://nopaste.org/p/aWcZDrOKj
kdekorte: marvin24, any luck with that patch?
marvin24_: it looks the same as the one I allready applied
kdekorte: but it should compile
marvin24_: yes, I fixed the error myself before
kdekorte: ah I didn't see that you had done that
marvin24_: something is miscounting here
marvin24_: arrr - I just lost connection to the remote machine
marvin24_: time for lunch
suokko: marvin24_: I have to move the prediction to right place in case flsuh is caused bystart function
marvin24_: suokko: sorry, but I don't understand anything about this prediction stuff, except that most are wrong
kdekorte: I have a simple clutter app that draws a single actor with a texture. In direct mode the texture is chopped diagonally in half. In indirect mode it is correct.. any idea where I should start looking at this issue?
suokko: marvin24: This is hax to make it work http://nopaste.org/p/a8NiMj5bT
nha: suokko: thanks for fixing those prediction warnings
suokko: nha: Did it fix all?
nha: and thanks to whoever finally came up with the correct fix for scissors
nha: suokko: haven't tested blendFunc yet because it takes rather long, but I'm about to
suokko: And scissors are still broken for dri1 ;)
nha: well, they work for dri2 anyway
kdekorte: they work in dri1 for r600, unsure about others
suokko: yes. I'm nowtesting dri1 but I found that r200 clear in dri1 seems like ignoring scissors
nha: I need another monitor :/
suokko: nha: Or piglit in fbo mode ;)
nha: working on a single monitor feels so restrictive :/
nha: suokko: hell yeah, that would be awesome
nha: though I don't actually need the second monitor for piglit, I just run piglit on one computer and switch back to another
suokko: Then it would be even possible to run piglit remotely without login to xserver with kms
nha: but for serious debugging and development, a second monitor would sure be nice
suokko: I agree
nha: headless OpenGL would be cool
nha: headless OpenGL that works even while an X server is running would be even cooler
suokko: Only problem would be hard lock for remote debugging
nha: hard locks are a problem for any kind of debugging ;)
Dr_Jakob: nha: peglgears works on the i915
marvin24_: suokko: my test machine is not reachable at the moment, will try it in a few hours
suokko: nha: Do you know if scissors have ever worked in r200 dri1 for clear?
marvin24_: maybe someone else has the same problem and can test faster
Dr_Jakob: nha: and probably r300g
suokko: nha: Remote reboot from hard lock would be hard to setup
nha: suokko: not sure; I have never run piglit there myself (I should get that old card out of its dustbin some day...), and the report that I do have is from a very old version that didn't have a scissor-clear test
nha: suokko: ah, I was thinking about my setup where at least all machines are within reach
nha: Dr_Jakob: that's cool; yet another argument to push our Gallium driver forward, I suppose
nanonyme: nha: Are any more arguments seriously needed? ;)
kdekorte: Not sure it affects anything, but found something really dump
kdekorte: dumb
kdekorte: /* The BASE_ADDRESS and MIP_ADDRESS fields are 256-byte-aligned */
kdekorte: -#define R700_TEXTURE_ALIGNMENT_MASK 0x255
kdekorte: +#define R700_TEXTURE_ALIGNMENT_MASK 0xFF
nanonyme: Looks like a fix, yes.
suokko: kdekorte: 0xFF=255 and (value +0xFF) & ^0xFF aligns it to 256 bytes
kdekorte: yes, but 0x255 != 0xFF
suokko: yes :)
suokko: That migth affect something
kdekorte: need to add the headers to the Makefile, right now have to make clean to get header changes compiled in
kdekorte: suokko, ha... that mask isn't used anywhere..
suokko: How is texture alignment done?
kdekorte: still looking into that
marvin24_: that's why I love ccache
mattst88: who runs TiRDC?
mattst88: that is, who posts updates?
bridgman: I have good news and bad news
bridgman: the good news is that I'm getting nearly 3000 fps with glxgears on an rv620
nanonyme: o.O
bridgman: the bad news is that what appears in the glxgears window is data from the last time I played openarena
mikkoc: my rv620 can't even start glxgears...
[Enrico]: bridgman: omg with radeon driver?
bridgman: and as I drag the glxgears window around my display it acts as a window into the last image from openarena, ie "are you sure you want to quit" etc...
suokko: bridgman: I suspect scissors
DanaG: Now that... is funny.
nanonyme: bridgman: Just out of interest, was there any corruption there? ;)
suokko: But I had some weird problems whole day today :/
nanonyme: As in, in the data from OpenArena.
suokko: Now my 2D is very slow. Even typing has lag
bridgman: no corruption, but I was running openarena with indirect rendering last time
nanonyme: Ah, right.
nanonyme: Well, wishful thinking, I guess.
suokko: bridgman: http://nopaste.com/p/avF0955Qgb
nanonyme: I still think it's strange I haven't had any corruption in my glxgears during all this time.
suokko: Just in case exa sets scissors too
bridgman: patch didn't apply, will have to stare at it blankly for a while I guess
bridgman: that always helps
suokko: I wonder why it doesn't apply. There is no changes to radeon parts after I created that in my local branch
bridgman: it failed on line 234 of radeon/radeon_common.c but I don't see a problem when I look at the code
suokko: ok. I will commit it because itworks in dri2 mode too (piglit test passes)
bridgman: sounds good
bridgman: beats manually editing the code ;)
suokko: And dri1 r200 just doesn't support scissors correctly ;)
suokko: dodges
marvin24: suokko: your latest hack against the prediction problem also didn't fix it
bridgman: building...
suokko: marvin24_: Can you give me log from the latest patch with CMDBUF set to1 and debug all?
bridgman: down to ~1700 fps with glxgears, still displaying from old buffer (backbuffer maybe ?)
marvin24: suokko: http://nopaste.org/p/afRxwU47M
nanonyme: Hmm.
nanonyme: wonders if the libdrm_radeon he's using seriously affects this: he's been getting ~1200 fps with glxgears with rv670 no corruption from old buffers
suokko: nanonyme: Can you try to compile mesa without libdrm_Radeon?
kdekorte: I have a question about textures, can anyone help me... I'm in radeon_texture.c radeonChooseTextureFormat
nanonyme: suokko: Doing that now.
kdekorte: and the textures that are coming up corrupted seem to have a type of GL_UNSIGNED_BYTE, I was expecting to see something like GL_UNSIGNED_INT_10_10_10_2
kdekorte: if I set libgl always indirect on, it never seems to call radeonChooseTextureFormat and the textures are correct
suokko: kdekorte: It should call itin aiglx
kdekorte: I have some printfs in that function that never come out when in indirect mode
kdekorte: unless they are coming out somewhere else
nanonyme: Same speed, can't try the corruption thing because openarena doesn't start in indirect mode for me.
nanonyme: No corruption from direct in any case.
nanonyme: (I do have suokko's scissor patch though)
suokko: kdekorte: in indirect mode opengl comands are handled in xserver side and it load dri driver in boot time only
nanonyme: Oh, lol. It went upstream already. :)
kdekorte: suokko, ok thanks for that tip...
suokko: There is a error. AIGLX loads it in server start not boot ;)
nha: suokko: blendFunc is fixed as well, so all problems are fixed
nanonyme: Still no corruption. :/
suokko: nha: swtcl is still broken
nha: ah, I haven't tested that
suokko: and I don't understand how code runs that way :/
suokko: nha: I have hax tht didn't work for some weird reason
suokko: http://nopaste.org/p/aN0cLMqVP
glisse: bridgman: this is feature a window which allow you to see in the past...
nha: suokko: that "Lock the flush not to do prediction" looks bogus
suokko: Why?
nha: what do you want to achieve there? Shouldn't the prediction be reset to what it was before after the flush?
nha: or otherwise, what is the meaning of a negative emit_prediction?
suokko: nha: negative means that I don't want to make flush run prediction
suokko: Flushis called from many places but that is only place where prediction shouldn't be run but delayed until the shader and others stuff has been updated
nha: I'm sorry, but that looks totally bogus
nha: also the logic in r300_swtcl_flush
nha: why do you run prediction when it's > 0, but when it's < 0 you reset to 0
nha: that just seems wrong
suokko: nha: jsut the same reason why it is set ot negative in Start function
suokko: So that prediction is not run in flush if it is called from start function
nha: finally, why is the prediction stored in a global variable anyway? I thought the point was to compute the predicted size and then verify that enough space is left in the cmdbuf
bridgman: glisse; right now it works like a pile of old newspapers
nha: using a negative value in such an extremely unintuitive way is a bad idea, it will only lead to more bugs down the line
suokko: nha: ot catch the bugs
suokko: nha: I'm not going to commit it I just tough about that could be easy way to tes if I understand what is going wrong
bridgman: do we think we know when 6xx/7xx 3d stopped drawing, or is it worth me bisecting ?
kdekorte: bridgman, stopped drawing what?
suokko: bridgman: you are only one
nha: suokko: I dunno... somehow, this looks extremely fragile to me; how do you verify whether the prediction was correct?
kdekorte: I'm running 3d right now from about 10 mins ago
kdekorte: bridgman, there were scissor issues that suokko and I fixed eariler today
suokko: nha: I set the prediction to calue that should cs->cdw in end of emit
suokko: So when there is call to flush that cs->cdw can be checked against predicted end position
nha: the whole point of this endeavour is to make sure we don't run out of bounds of the CS, right?
suokko: nha: yes
suokko: And another point is to flush before we allocate dma regions
nha: what does that have to do with the emit size prediction?
suokko: We have to decide if we ant to flush or render before we allocate dma regions or start emitting any state
suokko: Alsoanother check that is missing if we are running out of memory space and should flush because of that
nha: so.
nha: there should be a function that looks like void emit(...) { check that things are fine; do all the emit; check whether our prediction was correct; }
nha: the prediction itself can (and I would say, should) be local to that function
suokko: nha: except that swtcl rendering pipeline doesn't allow it
bridgman: ok, I'll do a make clean and see if that helps
suokko: It is broken to many parts that are called from core mesa
bridgman: failing that I guess I'll go get a chicken to sacrifice or something
bridgman: is it chicken or goat for mesa ?
nha: that doesn't sound very reassuring :/
suokko: nha: yes. r300_draw.c is a lot easier to understand and change
bridgman: 3d draws ok after make clean, back down to 965 fps on rv620
bridgman: lucky chicken
EruditeHermit: bridgman: hi
kdekorte_: I've been getting some texture corruptions that look like this.. http://filebin.ca/fczk/texture_test.tar.gz
kdekorte_: Oh that is the code... the image is here: http://imagebin.ca/view/s5Qxj8bM.html
kdekorte_: I believe this is the same corruption that quake3 is seeing in its menus
kdekorte_: Test case is pretty simple and just depends on gtk and clutter 0.8
kdekorte_: If I run in indirect mode, the problem goes away.
kdekorte_: I also believe their might be an alpha color image here since the black part of the image should be transparent
suokko: airlied: Does CP_PACKET1 have any future? http://nopaste.com/p/avdRR7Nyq
airlied: not that we've ever found
airlied: its been deprecated sine r200
suokko: I was jsutthiknig because there is some states in r200 that have non-continues registers with signle register writes
suokko: So I guess it is work around for poor register ordering
airlied: you'd save one CP dword
airlied: so I won't be adding support for it
airlied: it also can't address the whole register space
suokko: Maybe it was used in old cards for partial state updates so only changed registers have to be emitted but complexity is too much for gains there
airlied: it comes from r128 I think, so safe to ignore
suokko: It would be more important to have the hash table to store large state objects for fast reuse :)
MostAwesomeDude: suokko: Hey, stop reinventing Gallium.
suokko: Where did I reinvent gallium? the hash table?
MostAwesomeDude: Constant state objects, among other thigns.
MostAwesomeDude: *things, even.
MostAwesomeDude: Gallium lets st use CSO to bind Gallium state to driver-specific state.
nha: MostAwesomeDude: so, when is r300g going to be on par with classic in terms of testcase correctness?
MostAwesomeDude: A smart driver (read: all of the current ones) would put its registers, etc. into the driver-specific state, so all it has to do later on is emit the state object it's given.
MostAwesomeDude: nha: When I sit down and make it happen, probably?
suokko: MostAwesomeDude: Does CSO support way to make the state transfered to kernel space so we can just reschedule it with IB2? (and no validation required)
MostAwesomeDude: suokko: That'd be on the driver side, and no, I can't see a simple clean way to do that with CS.
nha: CSO is a purely userspace thing
suokko: ok
Dr_Jakob: suokko: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_state.h#n89
nha: pre-created kernel side state objects are an entirely different beast
MostAwesomeDude: Not sure if want, realy.
MrCooper: nha: how is r300g supposed to get on par if people keep ignoring it? :}
MostAwesomeDude: MrCooper: Osmosis?
EruditeHermit: its the red headed step child
nha: MrCooper: don't look at me, I ported the compiler
nha: (though to be honest, the hookup is still not really complete :})
MrCooper: yeah I appreciate that, improved things quite a bit here
MrCooper: anyway bedtime, bbl
tormod: hi, updated to latest git, and get "Forbidden register 0x4EA0 in cs at 213" on my M26
nha: had a similar report a short while ago on IRC, but I don't remember what happened to it
suokko1: R500_RB3D_DISCARD_SRC_PIXEL_LTE_THRESHOLD
nha: is that an Xpress 200?
suokko1: tormod: kms?
tormod: suokko1, kms yes
tormod: nha, M26 is ~ RV410
nha: so it makes sense that it doesn't have an R500_* register
suokko1: Problem is more like that register doesn't know about that register
nha: maybe we should ping bridgman about whether that RV410 has this register despite its <500 name (IGPs ar weird) and thus the kernel needs to be fixed
nha: or if the register doesn't exist, the userspace driver shouldn't write into it
suokko1: At least agd5f committed that change
quotemstr: What's the best-supported plain PCI video card I can get? I really don't care about 3D performance, but I'd love modern features like xrandr 1.2 support in the driver.
quotemstr: Is a Radeon 7000 any good?
suokko1: quotemstr: radeon 8500-9250
suokko1: but anything up from radeon 7000 should work if you can find one in good shape
quotemstr: Hrm, thanks.
quotemstr: Looks like I can grab an 8500 for $85.
quotemstr: Or a 9250 for $60?!
tormod: suokko1, is there a commit that I can revert?
suokko1: tormod: 18e0fea55bbc41ce81397f22aa2c91e4feefee55
tormod: suokko1, thanks
suokko1: quotemstr: 8500 was original high performance card but 9250 is newer card. see wikipedia http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units#Radeon_R200_.288xxx.2C_9xxx.29_series
tormod: suokko1, do you know if many cards will be broken, or it just mine?
quotemstr: Ah, thanks. Also -- does the drive support ordinary non-xrandr Xinerama?
suokko1: tormod: Looks like all r4xx IGPs
suokko1: quotemstr: last I heard xinerama didn't work
tormod: suokko1, thanks. I just uploaded the stuff to Ubuntu xorg-edgers, and maybe I should upload a fix.
suokko1: atleast not out of box
quotemstr: Which means a limit of two monitors, right?
quotemstr: (Since AFAIK, xrandr multihead can't span multiple video cards)
suokko1: quotemstr: There was some solution but I don't remember which
suokko1: xephyr maybe
suokko1: No it is not that
quotemstr: Isn't that just an updated Xnest?
suokko1: But I think that KMS has better chance with multi card setup. i don't know what is state but multi-card systems wi lbe supported
quotemstr: That's good to hear. Maybe my venerable G450 will work again. :-P
suokko1: airlied: see above about missing safe register in KMS
quotemstr: Can a dual-link DVI connection drive two separate displays?
airlied: quotemstr: no
quotemstr: Thanks.
meoblast001: hi
meoblast001: i'm trying to install drivers for my X1300
meoblast001: http://codepad.org/ndhGMXle < that's my configuration
meoblast001: what should i change it to be for hardware 3D rendering
suokko1: meoblast001: Remove xorg.conf? Default settings should give you 3D
meoblast001: ok
meoblast001: and the backups?
meoblast001: they're all NVIDIA backups anyways
meoblast001: for driver i uninstallee
meoblast001: uninstalled*
tormod: meoblast001, or just omit "radeonhd" so you'll use radeon
meoblast001: hm :/
suokko1: It looks like you had fglrx installed so it might be causing problems if it is not cleaned all the components
meoblast001: rendering was outragously slow
meoblast001: why the heck would ubuntu install that
tormod: for radeonhd I think you have to turn on DRI explicitly
suokko1: meoblast001: pasting log file heps a lot more than config
meoblast001: i just want to run the most updated free software driver
tormod: ubuntu will not install fglrx unless you ask it to
meoblast001: i only have the fglrx modaliases
meoblast001: time to restart xorg
suokko1: tormod: Do you have plan to provide r600 drm modules in ppa?
meoblast001: neverball is rendering at 2 FPS
tormod: suokko1, I haven't looked so much into r600, I don't have the hw to try out
meoblast001: either A) i'm CPU rendering, or B) the X1300 was made in 1987
suokko1: meoblast001: Can you paste your xorg.log?
meoblast001: ok, it's paste friendly, right?
tormod: meoblast001, my X1300 works out of the box in Ubuntu since forever
suokko1: meoblast001: It is huge and I mean you need to paste link to one of pastebins ;)
meoblast001: but it doesn't have any secret info does it?
meoblast001: such as keyboard input of some sort
meoblast001: i'm paranoid about that stuff
suokko1: meoblast001: No. It has only your hw setup and modules that xorg is loading
suokko1: And also log what driver is trying to do to make 3D work and what fails there
meoblast001: http://codepad.org/kNAL3FEM
tormod: suokko1, btw where do one get the r600 modules nowadays?
suokko1: tormod: Alex's repository and branch
tormod: from linux-core in his drm tree?
suokko1: btw, If yo uhave time it would be nice if you improved build instructions. http://xorg.freedesktop.org/wiki/radeonBuildHowTo
DanaG: It's mutually exclusive with KMS, though -- might wanna' make a secondary PPA.
meoblast001: why is it using radeonhd?
suokko1: tormod: Is That normal Ubnut defaul config to first try radeonhd?
tormod: normal Ubuntu does not have radeonhd installed
suokko1: meoblast001: I think you want to remove xorg-xserver-video-radeonhd package
tormod: if it is installed it should default to it I guess
meoblast001: ok
meoblast001: although it wasn't working before i installed it
meoblast001: xorg-xserver-video-ati vs xorg-xserver-video-radeon
suokko1: meoblast001: video-ati is wrapper for video-radeon (2 older drivers too)
meoblast001: ok
tormod: suokko1, I might look at this later. for the wiki I don't remember my password :)
suokko1: tormod: There is password remind feature :)
meoblast001: i'll restart and give you guys my log
DanaG: yeah, it is silly, and confusing, having two drivers to choose between.
tormod: suokko1, ok lame excuse :)
tormod: DanaG, is the r600 stuff build-exclusive with KMS? or just run-time?
DanaG: I'm not exactly sure, but I know the r600 3D branch drm modules don't support the "modeset" parameter, I believe.
meoblast001: which log do i read
meoblast001: .1 or .0?
suokko1: tormod: There isn't yet working KMS for r600
suokko1: meoblast001: ls -lt and hich one is newer :)
suokko1: probably 1
tormod: ok, but I guess one can use the same libdrm/mesa/ati packages and just replace the kernel modules
suokko1: It is only drm support for classic dri1 3D
meoblast001: 0 is
suokko1: yes
DanaG: Hmm, you could make it a drm-r6xx-r7xx-3d package, with diversions.
meoblast001: new output http://codepad.org/pq6s0mar
suokko1: it works xorg-edgers is good source for user space driver and then jsut needs the kernel modules
tormod: I can maybe offer a drm-r6xx-r7xx-sources package that will produce modules with module-assistant
suokko1: [drm] failed to load kernel module "radeon"
tormod: or somebody makes a dkms (I am not into that yet)
suokko1: That means your kernel module aren't working
meoblast001: so do i blame NVIDIA?
DanaG: noooo, use dkms, not m-a!
suokko1: meoblast001: i think you might have fglrx.ko somewhere
meoblast001: how do i find out?
suokko1: locate fglrx.ko
tormod: meoblast001, dmesg output please
suokko1: and dmesg output helps too
tormod: DanaG, be my guest :)
EruditeHermit: tormod: can I make a request? Can you update the jaunty packages?
meoblast001: no output, but it finished quite quickly
meoblast001: how do i have it search recursively
EruditeHermit: tormod: also, what ./auto-xorg-git commands are you using to generate, ati, libdrm, and mesa packages?
tormod: EruditeHermit, absolutely not now, it's way past bedtime
suokko1: find /lib/modules -name fglrx.ko
EruditeHermit: tormod: can you give me the commands?
meoblast001: nothing
tormod: EruditeHermit, libdrm needs some handholding now, better download the source, keep debian/ and update the rest from git
suokko1: meoblast001: What aboud "dmesg |grep drm"?
tormod: EruditeHermit, ../xorg-pkg-tools/auto-xorg-git -p mesa -d origin/ubuntu -g -H ../xorg-pkg-tools/hooks-karmic -t "~"
meoblast001: nothing
suokko1: and full dmesg would help too if there is some other conflicting stuff
tormod: EruditeHermit, ../xorg-pkg-tools/auto-xorg-git -d origin/debian-unstable -g -H ../xorg-pkg-tools/hooks-karmic ati
EruditeHermit: tormod: I had trouble with libdrm building libdrm-radeon1
meoblast001: suokko1: should i try a live CD?
tormod: EruditeHermit, look at the source, diff -Nurp it with your own debian/ tree
suokko1: meoblast001: I think that full dmesg output might help
tormod: meoblast001, what repos do you use?
suokko1: meoblast001: live cd would hlep to know if clen installation would work
meoblast001: tormod: default
EruditeHermit: tormod: ok, will try that, thanks
tormod: meoblast001, default what?
meoblast001: default repos for US
tormod: meoblast001, Jaunty?
meoblast001: yes
meoblast001: is the command pastebinit | dmesg?
suokko1: Where did you get your kernel then? 2.6.30 is not standard Ubuntu kernel
tormod: the other way I guess
meoblast001: i thought so
suokko1: dmesg | pastebinit
meoblast001: i got mine from FSFLA
tormod: suokko1, nice catch, he has messed up his installation and won't admit it
suokko1: meoblast001: Others version numbers also look like not default Ubuntu packages so you migth hve to clean a lot of stuff to get default system that will work well
meoblast001: :(
tormod: meoblast001, just reinstall Karmic, look to the future :)
meoblast001: but what about my files?
tormod: they are on your backup disk aren't they?
meoblast001: i'm lucky i have 1 hard disk
tormod: if you've got space, make a separate partition for testing Karmic
meoblast001: fml
suokko1: meoblast001: It would be best if you try a livecd to see if it works out of boc and if it work you can install clean version. Install program has partition resizes supportso you can add new partition for new instalation
tormod: meoblast001, if it does not work out of the box, please file a bug with "ubuntu-bug xserver-xorg-video-ati" and subscribe me to it.
meoblast001: crap
meoblast001: all my live CDs are 8.04
meoblast001: all my others are alternative
DanaG: libre-meolibre? what's that?
DanaG: Oh wait... maybe it's the firmware-linux package issue!
tormod: meoblast001, you can up/downgrade to the correct versions with for instance: sudo apt-get install xserver-xorg-video-ati/jaunty
meoblast001: i made a deb of my kernel
meoblast001: used the custom name meolibre
DanaG: hmm, does it have ATI stuff enabled, and all that? and DRM as module, not builtin?
meoblast001: 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
tormod: you have your own little kernel, good luck with that :) night
DanaG: Try a default kernel?
meoblast001: default kernel has nonfree stuff
tormod: like what?
meoblast001: firmwares i think
suokko1: meoblast001: see topic
DanaG: Oh, it's that whole firmware debate, again?
suokko1: We can't support 3D without firmware
DanaG: Hah, well, unless you're using CoreBoot, nothing can be 100.00000000000000% Free.
MostAwesomeDude: Well, we've been using firmware for a long time, it's just never been separated out with request_firmware() before.
meoblast001: are these firmwares free software?
MostAwesomeDude: Free as in beer, and speech, but we don't have the tools to generate them, so no.
DanaG: I have the sudden urge to insert a "your mom" joke. But I won't.
tormod: the non-free stuff is in separate packages, linux-firmware, linux-restricted-common and what not
DanaG: =þ
meoblast001: wow
suokko1: meoblast001: THey are free but problem is that debian thinks they don't come "in preferred from of editing"
meoblast001: waste of freaking money
meoblast001: i should have just went with intel
MostAwesomeDude: meoblast001: Chill.
DanaG: Mmmm, politics.
MostAwesomeDude: meoblast001: Ever had an Intel wireless card?
meoblast001: yes
suokko1: meoblast001: Intel has same blob firmwares. They just are in a rom chip that is harder to control what is in there
MostAwesomeDude: You think those have free and open firmware?
MostAwesomeDude: What suokko said. Intel chips don't require a firmware upload to be booted.
meoblast001: not sure, that's on my laptop which i don't use much anymore
DanaG: My Intel wifi card needs binary firmware.
MostAwesomeDude: My Intel, Atheros, and Broadcom Wifi chips all need firmware.
MostAwesomeDude: Oh, and my ZD1211. Can't forget those. Great chips.
DanaG: They sure beat the scalding-hot Realtek chips, that's for sure.
MostAwesomeDude: Honestly, the firmware on Radeons is not like on GeForces. It's very specific.
MostAwesomeDude: It's used to boot and run the CP, which has one purpose in life: Grab stuff from a ring buffer in main memory, and run it on the card.
MostAwesomeDude: We know how to program it, we know how to program the GPU. We just aren't privy to the super-nitty-gritty details of how that little chip works.
DanaG: CP... command processor?
meoblast001: anyone want to buy an X1300?
MostAwesomeDude: But I sincerely doubt there's magical hidden functionality in there. And I don't doubt that we could, if we wanted, rip it out of fglrx or the Windows driver and compare just to be sure.
MostAwesomeDude: DanaG: Yeah.
DanaG: hmm, does r600 still exit() on compiz cube-rotate?
meoblast001: how do i get free firmward for my radeon?
MostAwesomeDude: meoblast001: You mean, as in, firmware that you can compile yourself?
meoblast001: yes
MostAwesomeDude: Dunno. Good luck.
meoblast001: firmware i can modify, study, share, and run
suokko: meoblast001: You are free to create one or modify our current one
meoblast001: why can't i compile the current one?
MostAwesomeDude: meoblast001: Because we have no compiler for that chip, nor source, nor any idea whether it was compiled from a high-level language or assembled from a low-level set of opcodes.
meoblast001: and that is because ATI is holding back on us?
MostAwesomeDude: Maybe. "Holding back" implies that they're intentionally witholding information.
meoblast001: how could they not intentionally do it?
MostAwesomeDude: They may legally be forbidden from sharing information.
meoblast001: what about this SDCC?
MostAwesomeDude: It wouldn't be the first time.
MostAwesomeDude: Poulsbo is fail largely because the core was not made by Intel.
MostAwesomeDude: SDCC has nothing to do with it. The chip might not be able to support compiled C.
meoblast001: oh
meoblast001: MostAwesomeDude: what graphics processing solution do you think is right for me?
MostAwesomeDude: meoblast001: I suggest a discrete graphics card.
meoblast001: such as?
MostAwesomeDude: Well, ATI/AMD and nVidia are the main producers of those cards.
MostAwesomeDude: If you're looking for an integrated solution, VIA and Intel also make graphics chipsets.
meoblast001: i want something that doesn't require me to get a new board
MostAwesomeDude: Then go get a graphics card.
meoblast001: but i want it from a company who doesn't see me as just dollars in their pockets
MostAwesomeDude: Hm.
MostAwesomeDude: I'm afraid that Red Hat doesn't make graphics cards. :3
meoblast001: i'm a human being and demand to be treated like one
suokko: wonders that is there really any company that isn't after customers money
soreau: wonders if meoblast001 has a girlfriend
meoblast001: never have
soreau: Don't believe in same sex relationships?
soreau: runs
meoblast001: no, i'm just not gay, and women don't like me
meoblast001: brb, have to restart
_moep_: crap same radeon bug :(
suokko: _moep_: Which bug?
_moep_: #22562
meoblast001: so what am i supposed to do about graphics?
MostAwesomeDude: meoblast001: Frankly, you're just going to have to accept that no modern graphics chipset runs without some kind of uploaded voodoo code.
MostAwesomeDude: GeForces require more, not less, magic.
meoblast001: modern
meoblast001: what if i want something older
meoblast001: if i can develop my game, i'm good
meoblast001: i don't need fancy new stuff
airlied: I don't think any ati/nvidia/mga card works without microcode
mattst88: airlied, I'm getting undefined reference to xf86VGAarbiter* with xserver git
mattst88: using libpciaccess from git
airlied: mattst88: did you autogen?
mattst88: ah, possibly not