Vitls: Hi all. I hope all are ok. Where I can to find all xorg.conf driver options for 'radeon' driver?
EruditeHermit: Vitls: man radeon
Vitls: hm... oops :-) simple way. tnak you.
Vitls: have a nice day/night
EruditeHermit: MrCooper: hey
EruditeHermit: MrCooper: do you know of any app that tests OpenGL 3.0?
zhasha: MostAwesomeDude: why do you insist on having all includes for foo.c in foo.h?
MrCooper: zhasha: e.g. if all prototypes are in a single header, any prototype change means rebuilding everything
zhasha: MrCooper: I mean in his last patch he moved a couple of #includes from radeon_drm.c into radeon_drm.h
zhasha: even though they don't technically need to be there
MrCooper: ah, nm me then :)
zhasha: and though it might just be hypocrisy, I like to have #includes only where they're needed, preferably outside of headers, so as to keep the dependency graph small
YoG: hi, how can I set tv overscan for my 9600xt card?
PuffTheMagic: what repos do I need for kms... radeon-gem-cs3 dont seem to build anymore
PuffTheMagic: is that still the right ati drivers repo
pike_: hmm i dont suppose there is any way to reset a freenode password?
pike_: oops sorry guys wrong chan
zhasha: PuffTheMagic: IIRC the KMS changes were merged to master
Hystoriker: hello all. i have a problem with my ati x300. it is not supported by fglrx under kubuntu jaunty anymore, so i need the radeon-driver. but when i try to run an openglscreensaver, i only get 10fps or even less. also there is a blinking in some parts of the screen
YoG: hi, can someone help me setting tvout on a 9600xt card?
tsamolotoff: Hey guys! So, two days of free-time now) Would you suggest compiling rc4 to solve dri2 vsync problem of yesterdays?
nanonyme: glisse: You complained about cache coherency at one point, right?
PuffTheMagic: do what drm repo has the latest kms drm code?
agd5f: PuffTheMagic: linus or airlied's kernel trees
nanonyme: wonders how they differ atm
PuffTheMagic: well libdrm didnt compile for me just now
agd5f: YoG: you can adjust the tv-out attributes with xrandr
agd5f: Hystoriker: make sure you have the mesa 3d driver installed
nanonyme: PuffTheMagic: Be a bit more specific. What did it say?
agd5f: PuffTheMagic: libdrm is in git, the kernel modules are in the kernel
PuffTheMagic: agd5f: i know where they are
PuffTheMagic: the main repos
PuffTheMagic: i just didnt know if i should be using drm-next
PuffTheMagic: or some other airled drm repo
agd5f: PuffTheMagic: drm-radeon-kms
Hystoriker: agd5f: sorry for my incompetence, how do i find out?
agd5f: Hystoriker: check the renderer string in the glxinfo output
Hystoriker: agd5f: OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL
Hystoriker: so i guess i have it installed
tsamolotoff: Hystoriker: Am I blind? Is it 3 yrs old?
agd5f: Hystoriker: you should be all set. you might try a mesa git snapshot as there have been a lot of improvements since most distros last released
Hystoriker: tsamolotoff: might be, it is the one that is shipped with kubuntu 9.04
nanonyme: tsamolotoff: Unless the date means something else.
Hystoriker: agd5f: so i run the mesa driver, i have a 3d-accelartorcard and still the opengl fps when running an openglscreensaver is below 10?
agd5f: ignore the date, it hasn't been bumped in ages
agd5f: Hystoriker: depends on the app, some might be hitting unaccelerated features
Hystoriker: i see, that must be true for the opengl-support under kde then, at least in that version on kubuntu jaunty
YoG: agd5f: I'm doing that, but the screen appears larger than than the tv screen (I can't see the whole screen on the tv)
PuffTheMagic: hmm libdrm fails linking with libGL.la
Hystoriker: i can live without an openglscreensaver, but there are other things that are a bit mor annoying. eg using an opengl-slideshow in digikam, where there is a lot of blinking all the time
PuffTheMagic: which i dont seem ot have
agd5f: Hystoriker: like I said, there have been a lot of improvements in git
zhasha: why would libdrm need to link to libGL
PuffTheMagic: Xorg is failing to load dri module
PuffTheMagic: what is wrong here
PuffTheMagic: i just rebuilt mesa and libdrm
PuffTheMagic: and the ati driver
ferret_: look in Xorg.0.log and dmesg for more detail
PuffTheMagic: there was no detail in it
PuffTheMagic: it just said it fails
PuffTheMagic: nm i know what the issue is
soreau: Despite the fact that compositing (compiz) and gl works on my dri2 install, glxinfo still reports Software Rasterizer. Why might this be?
fpoibaf: I noticed in the radeon man page that Option "EnablePageFlip" is supported only on R/RV/RS4xx and older hardware
fpoibaf: would enabling it on R5xx improve performance?
tsamolotoff: nanonyme: Now(2.6.31-rc4) there're some nasty lock-ups when starting any app or clicking kicker while glxgears is running ... I thought it's inherent to Ubuntu only...
glisse: nanonyme: i always complain when AGP is involved
nanonyme: glisse: Heh, I think I can go with that, still haven't managed to get a single 2.6.31 to boot on my system.
glisse: nanonyme: what is your sustem ?
nanonyme: glisse: iBook with a PowerPC and AGP. (rv350 GPU)
nanonyme: There's some segfault when booting and it talks of a cache coherency check.
dileX: cool, kms and dri2 works now w/ 2.6.31-rc4. needed to update libdrm (2.4.12+git20090715.9aed44b-1~dileX+1) and xserver-xorg-video-radeon (1:6.12.99+git20090723.2afc46f~dileX+1). NOTE libdrm: in debian/rules added --enable-radeon-experimental-api in "configure-section". (luckily no upgrades to mesa, xorg-server, etc. but will test later)
dileX: (oops, glxgears segfaults)
Maestro123: IRQ's not enabled, falling back to busy waits: 2 16
Maestro123: drmRadeonCmdBuffer: -22
Maestro123: what is it?
Maestro123: drm from git video 4830
agd5f: Maestro123: you are using the wrong drm kernel modules
agd5f: you need the ones from my r6xx-r7xx-3d branch
Maestro123: x11-drm-9999 from x11 overlay gentoo ( /etc/make.conf -DRM_LIVE_BRANCH="r6xx-r7xx-support" ) no?
agd5f: Maestro123: no
Maestro123: I will try your
rnoland: agd5f: does that mean that the git ddx will not build without libdrm_radeon now? or is it just that he has it installed but out of date?
agd5f: rnoland: it will build with the latest libdrm radeon
rnoland: agd5f: is libdrm_radeon required though?
agd5f: if you have an older version it won;t work
nanonyme: s/will/should/ # maybe?
agd5f: no, it's not
rnoland: agd5f: ok, cool
agd5f: builds fine without as well
nanonyme: Maestro123: You can probably hand-edit the ebuild to use the right repo if you want to use it.
nanonyme: Probably want to save it in an overlay though so it won't get wiped on next sync. :3
Maestro123: I will try
Maestro123: tell me the exact address (URL)
tsamolotoff: So, can anyone tell me, why there lock-ups shortly after a new 3D app was started (sometimes there's sound stuttering in ioquake3 and other)
dileX: Maestro123: Clone:
mcgrof: was radeonhd the right list for that patch?
agd5f: mcgrof: probably not
mcgrof: Is being held until the list moderator can review it for approval.
mcgrof: I suck
mcgrof: oh yeah the other from address was used
Maestro123: agd5f, 3d and even then was already working well? In CS, you can play will be? =)
agd5f: Maestro123: ?
Maestro123: 3d on r7000
Maestro123: 3d on r700
mcgrof: Maestro123: you just hitting your keyboard with your head?
agd5f: Maestro123: most demos work, there are still some issues
nha: osiris_: I fixed that piglit compile error
osiris_: nha: great, thanks
nanonyme: suspects he asked whether r600 is mature enough to play counterstrike but can't be sure
nanonyme: And assuming this implies Wine, I'd assume the answer to be no.
MostAwesomeDude: Probably not.
nanonyme: Decoding speech is soemtimes a bit cumbersome. :p
nanonyme: thanks God he isn't an AI, humans are way too complicated to understand
_Groo_: eyah all
_Groo_: can anyone tell me how do i check if im running gallium?
nanonyme: If you have to ask, you probably aren't? ;)
MostAwesomeDude: _Groo_: (a) you aren't. (b) glxinfo will tell you in the VERSION and RENDERER fields.
nanonyme: MostAwesomeDude: How's the renderer string different for Gallium, btw?
MostAwesomeDude: nanonyme: "Gallium 0.3 on R580" or something along those lines. Lemme go check.
MostAwesomeDude: Yep, that's what it does.
_Groo_: MostAwesomeDude: so doing this does nothing? ./configure --with-dri-drivers=r300,swrast --prefix=/usr --enable-gallium-radeon --with-state-trackers=glx,egl,dri,xorg
MostAwesomeDude: _Groo_: Well, they're not going to get installed by default. You'll have to use LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH to load them.
_Groo_: MostAwesomeDude: hmm ok, is gallium in a shape i can use it for normal day use?
_Groo_: MostAwesomeDude: aka, kwin3d, compiz, heneral games?
_Groo_: can you point me to a wiki which shows me how to load the gallium drivers?
nanonyme: MostAwesomeDude: Oh, I thought they just get installed in a different directory. :(
nanonyme: _Groo_: Probably not.
nanonyme: (disregarding softpipe which I recall someone got working quite well in some game)
_Groo_: nanonyme: gonna test them layer then
nanonyme: But yeah, I wouldn't know exactly since I haven't yet managed to get a working KMS+ttm set up. *grumble*
zhasha: nanonyme: step 1. install fedora
nanonyme: zhasha: Doesn't work.
_Groo_: nanonyme: groo is happilly using is evil rs485 with dri2/kms
_Groo_: nanonyme: igp? 200m?
nanonyme: zhasha: PowerPC and AGP.
zhasha: even better
kdekorte: I don't think that KMS works on anything above r500 either
nanonyme: zhasha: I'm aware it doesn't work, just doesn't help to give silly advice like that. Currently KMS+ttm doesn't work with Fedora 11 and Rawhide/Linus' tree kernels don't even boot.
_Groo_: kdekorte: actually r600/700 is preliminary 3d working now... just get mesa/ddx/ddr and linus master
_Groo_: i mean drm not ddr
_Groo_: and i meant have not it...
kdekorte: _Groo_, yeah I have 3D working on my other machine
kdekorte: I was hoping the fix for the slow memcpy would appear this week.. but guess not
stikonas: _Groo_: Have you tested kwin compositing on dri2? It does not work for me...
kdekorte: Are textures working on r6xx yet? (I'm out of town and don't have my r6xx machine to test with)
boghog: anyone know which commit fixed the black screen issue?
boghog: at least for doublebuffered visuals
_Groo_: stikonas: yes i did, its working here, i also opened bugs regarding that problem, but is fixed now.. its was fbo related
_Groo_: kdekorte: no textures in any dri2 so far
stikonas: probably my X server must be blamed
_Groo_: textures are need for wow, lol ;) and googleearth
stikonas: oh, it is working now :)
_Groo_: stikonas: im using x from master
kdekorte: boghog, it was the fix got glx to ignore 32bit visuals I think
stikonas: I am using X git version from June
_Groo_: stikonas: that could be the problem yes
boghog: kdekorte, hmm ok
stikonas: _Groo_: it is working now
suokko: boghog: the fix was 5ed440400573631f540701f3efd479d8c1592007
kdekorte: boghog, I think it was this one... 5ed440400573631f540701f3efd479d8c1592007
stikonas: probably some recent mesa commit fixed it
osiris_: I'm not sure I understand the PVS memory model restrictions (page 69 r500 accel guide). do these instruction meet the criteria: MUL OUTPUT, CONST, INPUT; MAD OUTPUT, CONST, INTPUT, TEMP; ?
osiris_: nha or agd5f ^^^
_Groo_: stikonas: like i said, started wroking after dave fixed the fbos
nha: osiris_: both those instructions are fine
nha: osiris_: what do you need this for?
boghog: ah I see
osiris_: nha: I'm continouing vertex shader cleanup
nha: osiris_: oh.
nha: osiris_: are you sure we're not working on conflicting things?
nha: I thought you were done there :/
nha: see http://cgit.freedesktop.org/~nh/mesa/log/?h=r300-compiler, particularly the commits labelled vertprog
osiris_: nha: heh, looks like you've done what I was going to :)
nha: as long as there was no duplicated effort ...
nha: I was pulling the vertprog stuff into my changes since it now shares infrastructure with the fragprog path, and while I was there, I though hey! why not clean up that mess a little
osiris_: I've just started doing it, so I haven't wasted much time
osiris_: nha: will do something else then. I can choose:
nha: osiris_: I actually hope to be through with the refactoring effort tonight, though not with the hooking up to Gallium part
osiris_: ARB_texture_rg, ARB_occlusion_query, VBOs
nha: if I had a wish, I would say VBOs first, ARB_occlusion_query next, since I believe that's the order of importance
nha: VBOs should be widely used and give a very nice speedup
boghog: vbos were broken in my app :(
boghog: but thats on r7xx
osiris_: nha: ok, will do VBOs now
osiris_: nha: do you know any test apps I could test vbo perf?
nha: for performance, I don't know
nha: probably best to benchmark a number of games that use VBOs
nha: that phoronix-test-suite can be quite handy, once it's actually set up
kdekorte: osiris_ are you doing VBOs in gallium? or in the old stuff?
osiris_: kdekorte: in classic mesa
kdekorte: for the r6xx/r7xx chips?
osiris_: kdekorte: for r300-r500
DanaG: is getting his hands dirty, so to speak, trying to figure out why a kernel won't boot... by looking at the assembly code it's currently running.
kdekorte: Well, I got one of those too...
_Groo_: osiris_: gonna test that code as soon as it hits mesa :D vbos go!
_Groo_: see/ya all later
MostAwesomeDude: nha: Looking nice with the compiler cleanup. Lemme know if you need help with hooking it up to Gallium.
agd5f: osiris_: IIRC, r5xx supports more vertex instructions than r3xx/r4xx as well
MostAwesomeDude: And more constants.
osiris_: agd5f: yes, it supports loops and branches
agd5f: kdekorte: the texture code is in place, but the sample instruction doesn't work for some reason and I haven't been able to figure out why yet
MostAwesomeDude: Somebody more intelligent than I, should really go and figure out why r300g textures keep gettin' corrupt and icky.
zhasha: MostAwesomeDude: I suspect we emit them incorrectly :P
kdekorte: agd5f, is it one of those things where you need to set a stencil or some other object as well as the texture?
agd5f: kdekorte: no
MostAwesomeDude: zhasha: I think we're setting up the texture offsets wrong somehow.
zhasha: but... but I checked that code several times
agd5f: kdekorte: it works if you swizzle the exported components to 0 or 1 or export a constant value
agd5f: the sample instruction just doesn't seem to work. so presumably it's some other bit of state that's bad that's affecting it
kdekorte: agd5f, I was looking at the xv code for r600 for ideas how it worked.. so do you need to scale the components?
agd5f: kdekorte: what do you mean?
zhasha: MostAwesomeDude: r300_texture.c - line 84
kdekorte: like make the texture components a floating point value between 0 and 1
kdekorte: but I'm just talking out of my ass... I have no clue how it works
zhasha: are we sure tex->size is initialized
zhasha: and what's even in tex->size?
agd5f: kdekorte: the tex coords are always normalized in the 3d driver
MostAwesomeDude: zhasha: Heh, you're right.
zhasha: yay, I'm useful
MostAwesomeDude: Lemme go mess with that.
MostAwesomeDude: zhasha: Just took a look at it. It's fine.
MostAwesomeDude: It starts out at 0.
MostAwesomeDude: The problem is miptree offsets; check out progs/demos/lodbias for a great example.
tzaeru: anyone tried Neverwinter Nights on the drivers, and noticed apparent lack of many textures? (Possibly due to GLSL not working, I guess)
tzaeru: useful, only error it manages to give is "Names Differ: PLC_WAmAr_1 ABP_wamar_1" :]
nanonyme: Shouldn't it in theory be checking for the extensions and failing for them?
suokko: nanonyme: It could also forgot to check opengl version
nanonyme: Meh, isn't OpenGL version a bit rough way to check for things? :p
tzaeru: uh-huh, in this lack of GLSL, it beats me as of why the ATI properiety driver package suggests using FOSS :3
MostAwesomeDude: agd5f: If you're not too busy, could you confirm my understanding of miptrees on r300?
nanonyme: tzaeru: That's likely not ATi's recommendation. :)
suokko: nanonyme: there is some core opengl features that should be present if driver supports some version :)
agd5f: MostAwesomeDude: I can try
nanonyme: suokko: Sure, games just seem to (usually?) depend on not the core features but extensions.
tzaeru: nanonyme, true :)
tzaeru: bloody open source hippies.. ^_^
nanonyme: ATi's recommendation would be not to use X server 1.6 or kernel versions above 2.6.28, I guess. :3
MostAwesomeDude: Basically, the initial offset has to be 64-aligned (done by BO allocator), and then each mip level has to be 64-aligned.
MostAwesomeDude: And the pitch is always the minified pitch from the previous texture.
tzaeru: nanonyme, that's another issue, why le hell does X or kernel updates break driver compatibility :| annoying..
MostAwesomeDude: Finally, pitch always has to bo POT, and all levels below the first have to be POT.
nanonyme: tzaeru: Have you done programming ever?
tzaeru: yes. a lot, actually.
nanonyme: tzaeru: Noticed that sometimes an external library you're using changes dramatically and you need to port your code to support the changes?
agd5f: MostAwesomeDude: sounds about right. see radeon_mipmap.c in mesa
MostAwesomeDude: agd5f: I did, but I'm not understanding what it's doing right that I'm doing wrong. :3
tzaeru: nanonyme, yeah, but I also know that drastic API changes need a really, really freaking good reason to ever do.
tzaeru: forcing a constant upkeeping of perfectly good and working drivers due to the underlying library's API changes sucks.
nanonyme: tzaeru: It doesn't still mean it would take any less man-power to port software for the changes even if the API/ABI changes are justified.
agd5f: MostAwesomeDude: they have to be laid out a certain way in memory, I don't remember the order off hand
MostAwesomeDude: agd5f: Alright, thanks.
agd5f: MostAwesomeDude: I think it's largest to smallest. osiris_ or nha may remember better
tzaeru: nanonyme, well, I've never followed X's developement, but I still find it hard to imagine what could possibly be a problem mighty enough to render dozens of working drivers incompatible :3
nanonyme: tzaeru: Changes between X server versions like 1.5 to 1.6 was very much one such thing.
nha: agd5f / MostAwesomeDude: it is largest to smallest, and there are a lot of subtleties with the precise alignment. I also tend to forget the details
MostAwesomeDude: nha: Ah. We should really write it down. :3
Maestro123: This instruction will come for me?
nanonyme: tzaeru: No one promises version changes of that magnitude don't break drivers. The solution is not to upgrade if you want to play safe. :3
nanonyme: Check compat first, upgrade later.
tzaeru: nanonyme, I wouldn't have upgraded, ever, if some silly new software didn't absolutely need the newer stuff :|
tzaeru: and thanks to that, I'm pretty much stuck with half-working drivers, when things -used- to work. durr. oh well..
nha: MostAwesomeDude: Yeah. Texture layout is one of the reasons I'm afraid of large driver changes like moving to Gallium (shader compiler being the other major one, but I'm working on that :})
agd5f: Maestro123: http://jbridgman.livejournal.com/
osiris_: agd5f / MostAwesomeDude: all levels are aligned to 32 byte offset. for all cards except rs6x0 and rs740 minimum rowstride is 32 bytes, for rs6x0 and rs740 minimum rowstride is 64 bytes
nha: gotta love those IGP chips...
MostAwesomeDude: osiris_: So for each level, the mip offset of the next level is just rounded up to 32?
MostAwesomeDude: Huh. I'll try that.
soreau: Is it normal for glxinfo to show the render string as software raterizer even though everything dri2 is working fine?
Maestro123: 2.6.28 need?
stikonas: soreau: I think that no
agd5f: Maestro123: yes 2.6.28 or .27
stikonas: soreau: it should look likt this: Mesa DRI R300 (RS400 5955) 20090101 x86/MMX+/3DNow!+/SSE2 NO-TCL DRI2
soreau: I know what it's supposed to look like
soreau: I'm just wondering where this bug is on my system
Maestro123: agd5f,my kernel is 31 =)
stikonas: soureau: maybe LIBGL_DEBUG=verbose glxinfo can give some useful info?
tzaeru: I wonder how much work it is to implent GLSL in few days. of course, no prior experience with driver programming sure helps
agd5f: Maestro123: you'll need an older kernel then :)
soreau: stikonas: I think you're right http://pastebin.com/m2c7d9cf1
nanonyme: tzaeru: Only Gallium3D drivers are going to have that.
soreau: If I run it as root, it returns properly
soreau: I remember airlied helped someone with this problem, but he had to use a different user or something
soreau: airlied: Do you remember what was causing this? glxinfo returns SW rasterizer, running it as root shows correct renderer string though
tzaeru: nanonyme, in http://www.x.org/wiki/RadeonFeature it is listed as a Mesa 3D feature, and that for R300 chipset someone had actually started that..
stikonas: soreau: can you pastebin "ls -l /usr/lib/dri/"?
airlied: soreau: /dev/dri/card0 has the wrong perms
soreau: ls -l /dev/dri/card0
soreau: crw-rw---- 1 root video 226, 0 2009-07-24 08:56 /dev/dri/card0
stikonas: soreau: are you in video group?
nanonyme: tzaeru: It's doable, yes, just much less effort with Gallium3D. I haven't yet met someone who has thought implementing it for classic Mesa makes any sense.
soreau: stikonas: It is apparent that I am not :)
stikonas: so that's your problem :)
tzaeru: nanonyme, I guess, if things ever get finished (...) and working..
soreau: stikonas: airlied: That did it, thanks for your help =)
nanonyme: tzaeru: Imo it's just a matter of time.
tzaeru: yeah. well. Right now, I have less than 2 weeks to finish a software that would take use of GLSL
nanonyme: tzaeru: Then probably a good way to steer towards either closed drivers on Linux or Windows.
tzaeru: yeah, just changed, hopefully I don't need to reconf kernel too <3
nanonyme: While I'm confident the open drivers continue progressing at good speed, putting two-week-deadlines might be a bit of shooting oneself in the foot. :3
tzaeru: I hope they do, so that in near future they could be as good choice as the closed ones.
stikonas: it will probably take a few more months to get somthing useful out of gallium :(
tzaeru: there's a bit too much breaking of depencies and compatibilities with mainstream open source in common :|
tzaeru: hurr. now X freezes whole comp if I try to launch it D:
MostAwesomeDude: stikonas: It'd go faster with help. :3
stikonas: MostAwesomeDude: I've absolutely no experience in drivers programming
tzaeru: but Gallium's a library! go work on Gallium ;p
tzaeru: I've just been on 8 month vacation, tried to find good open source projects to work on
stikonas: tzaeru: gallium3d has mostly working core, but it neads state trackers aka drivers for hardware
stikonas: and I'm not even a computer science student
MostAwesomeDude: stikonas: No, most of the state trackers are fine, but drivers are another thing.
tzaeru: mmh.. so, if I'm not all wrong, main purpose of Gallium3D is to work as a layer between graphic drivers and graphic libraries such as OGL?
tzaeru: so that the drivers only need to support Gallium, and nothing else? :3
stikonas: tzaeru: yes, but there are no stable drivers for Gallium now
MostAwesomeDude: stikonas: Pfft. softpipe is pretty stable.
MostAwesomeDude: i915 works mostly. r300g is starting to get there too.
tzaeru: the amount of layers and such in between the end-user product and hardware sure gets dazzling sometimes
stikonas: not suprising...
stikonas: and not too useful
stikonas: softpipe can only be used as a reference rendering
stikonas: but not for anything real
boghog: i wish I could help (and want to), but despite being pretty comfortable with C I know nothing about how all this X graphics stuff works internally and what is involved with programming drivers
tzaeru: as far as I know of how the graphic stuff works, I am very, very glad I am not part of developing it :)
tzaeru: the actual amount of different pieces of software, layers and such is just.. durr.
magyar: hi, will radeon module work better with a 4890 card?
masa-: boghog: same thing here..
masa-: btw what is r300g?
boghog: yeah, ive been reading about dri, drm, ddx, uxa, exa, xaa, dri2, gallium, mesa, ttm, gem for over a year and I still have no even a vague idea of how it all fits together :p
magyar: anyone here using a 4890 card?
stikonas: gallium is a new 3d driver architecture
tzaeru: boghog, with the binary ati drivers, it's very simple. software makes OGL call, which is translated to X, which gives it to driver, and driver uses it's inbuilt interfaces to tell to card what to do!
tzaeru: the binary drivers make it a bit simpler :-3
boghog: the binary drivers dont use dri or anything right?
boghog: or am i mistaken
tzaeru: they have similar stuff built inside them
tzaeru: actually they don't work at all if dri is enabled.
boghog: ah well, I'll just keep lurking in here and maybe one day I'll develop a decent understanding
tzaeru: if you want to torture yourself, you can always check what the functions exactly do from the sources :P
osiris_: airlied: I've partially implemented VBOs for r300 but didn't seem to get any perf boost. how do I check that the bo's aren't uploaded every time a rendering operation is happening?
agd5f: osiris_: printf?
airlied: osiris_: just make sure you aren't getting dma buffers
osiris_: but where is the code that uploads the data?
airlied: are you in kms btw?
airlied: so then the upload is done in the bufmgr_legacy code
nanonyme: boghog: When it comes to radeon drivers, you can just drop out UXA from that category and remember that XAA is getting deprecated and that these drivers only use the GEM API, innards of memory manager are TTM, and Gallium3D goes inside Mesa.
osiris_: airlied: bufmgr_legacy? where's that stuff?
agd5f: osiris_: radeon_dma.c and radeon_bo_legacy.c
ndim: If I want to check whether the issues I am seeing on this mobile X1400 with Fedora 11 are still there with the hottest bits fresh off the press, which packages do I need to build from git?
ndim: xf86-video-ati for sure. But what about kernel, mesa, etc. pp.?
airlied: ndim: everything really
airlied: glisse: btw what is the round to power of 2 stuff about? in the CS checking code?
ndim: airlied: OK, so testing takes a lot of work and there is no way for a quick test. Thanks for the info.
boghog: gentoo makes it easy to get the lastest stuff using the X11 overlay, but then again it makes other things less easy :p
osiris_: airlied: while trying to benchmark VBOs I encountered a bug that I have seen previously only on KMS: a segfault in the middle of copying vertex data to dma memory
osiris_: looks like the memory is freed behind our back
ndim: Hmm. Some guy claims to have ported the HDMI audio stuff from radeonhd to radeon, but only posted it on the radeonhd mailing list?
osiris_: how's that possible?
EruditeHermit: the number of GLXFBConfigs was reduced
EruditeHermit: in DRI1
nanonyme: ndim: Why didn't he port it for KMS? :/
nanonyme: Needs to be eventually done anyway.
mpyne: Is there something I can do to debug OpenGL output not showing up at all with r500 in current git?
mpyne: besides the obvious LIBGL_DEBUG that is
ndim: nanonyme: No idea.
nanonyme: ndim: I mean, I was under the impression most of the point of not porting it to radeon is that radeon's going to use KMS anyway and you have to do the HDMI audio in DRM there.
ndim: nanonyme: I guess the fact that the guy is posting his port only to the radeonhd list shows that he does not completely understand the big picture.
ndim: Well, neither do I :)
nanonyme: coughs at 16k+ line single commits
nanonyme: Luckily I don't have to touch the Intel driver code, ever. Sounds dangerous. :p
nha: so, there is one regression in my r300-compiler branch that I know of
nha: but it's 2:30am, and sleep-induced decrease of thought velocity has a negative impact of debugging effectiveness, so...
nha: looking forward to comments on my TGSI rant ;)
soreau: Alright, now that I have dri2 working how do I get 1280x1024 working? The max reported available is 1152x864 currently
adamk: soreau: Have you tried adding a modeline for 1280x1024 to the xorg.conf file?
soreau: adamk: No, I have not tried that yet. Though I didn't have to for.. anyway I'll try it ;)
soreau: adamk: Adding the mode line of 1280x1024 effectively did nothing
soreau: Can anyone say why my max resolution is 1152x864 with dri2? I tried adding a modeline for 1280x1024, but the max is still the same
soreau: X log seems to show 1280x1024 was ok
soreau: but xrandr says there is no such mode
EruditeHermit: soreau: what happens if you remove as much as possible from xorg.conf??
soreau: It can't hurt. Lemme try going commando
soreau: nope. still the same deal
soreau: EruditeHermit: I just don't understand why it would be acting this way. I've never had 1280x1024 not available on this card until now using dri2
soreau: and X log seems to think 1280x1024 is just as fine as the rest
soreau: Here's the output of xrandr --vebose http://pastebin.com/m6e93f12
soreau: verbose even
soreau: And X log http://sprunge.us/FedZ
soreau: Other than this issue, everything else's running great
EruditeHermit: soreau: can you locate which commit caused this?
EruditeHermit: you had dri2 working before with correct resolution right?
EruditeHermit: dunno then
soreau: I just installed dri2 stuff on my gentoo partition and got it working, but I've had this card for years and every distro gives the max option of 1280x1024
EruditeHermit: its a bug I guess
EruditeHermit: just use dri1 for now
soreau: But at least I know now I can run without xorg.conf and no problems there
soreau: EruditeHermit: Hmmm.. could I somehow test if it's dri2 causing it? Like disable dri2 and just use dri1?
soreau: How can I do this. I have 2.6.31_r3 with kms installed
EruditeHermit: or nomodeset=1
EruditeHermit: try both
soreau: Can I put it in grub.conf?
nanonyme: Hmm, compiling piglit seems to be challenging. :)
EruditeHermit: in the grub line
EruditeHermit: soreau: yes
EruditeHermit: the kernel line
EruditeHermit: put both because I can't remember which one actually works
nanonyme: soreau: I'm not sure if disabling it works in Linus' tree.
soreau: Me neither ;)
nanonyme: radeon.modeset=0 should work if something does though.
soreau: nanonyme: I'm using 2.6.31_r3 from vanilla-sources in gentoo
EruditeHermit: well for someone else it required nomodeset=1
EruditeHermit: so try both
EruditeHermit: it can't hurt
EruditeHermit: back later
nanonyme: kicks at piglit
nanonyme: And I also hate search machines for giving me incorrect search hits...
ssieb: thought just "nomodeset" was all that was needed (works for me)
nanonyme: ssieb: In Linus' tree? Might be. Unsure what exactly is supposed to set it off nowadays.
soreau: Well this is interesting
soreau: EruditeHermit: nanonyme: With nomodeset=1 the kernel started up with dri2. With radeon.modeset=0, it threw a message right before loading the kernel 'unknown option 'radeon.modeset=0' ignoring' but then proceeded to boot without kms. Using dri1 now, I do in fact have 1280x1024 as max
soreau: So it does have something to do with dri2/kms ;)
nanonyme: soreau: Actually it should be giving unknown option.
nanonyme: The parameter isn't to the kernel but the radeon kernel module.
soreau: I just thought it was cute, that's all :)
nanonyme: Kernel is absoluetely clueless as to what it means. :3
soreau: I see
nanonyme: I wish it gets seven soon so I can put my stereos on.
ssieb: nanonyme: sorry, didn't know it was changing...
nanonyme: soreau: Imo slightly icky though that it still seems to load ttm & folks even if you tell it radeon.modeset=0. :/
nanonyme: (considering I always want to replace it with r6xx-r7xx-3d DRM anyway)
Coadey: wonders if someone can offer advice on xrandr showing "DVI-0 disconnected" when a CRT without EDID is connected via DVI-to-VGA adapter: http://etherpad.com/dvidisconnected
nanonyme: No offense but why are you tolerating a CRT without EDID? Displays aren't that expensive and living without EDID is quite a bit of a pain since you have to push in all modelines you want.
nanonyme: (figuring them out might sometimes be untrivial)
Coadey: Because this is a Wells Gardner arcade monitor (closer to a TV than a multisync PC monitor)
Coadey: I do have the modelines and everything sorted out, which is of course necessary sure.. They work fine on a different CRT where I tested everything before the install
nanonyme: Iirc there was some way to force the connector active in xrandr, don't remember how though.
ssieb: DVI *is* disconnected
ssieb: you're using the VGA connector
Coadey: This is an X1550 with just a single DVI port. It has a DVI-to-VGA dongle (I've tried two different ones).
ssieb: yes, but that means that both logical connections go through the same physical connector
ssieb: there are separate VGA signal pins in the DVI port
ssieb: you are using the VGA output of the card, not the DVI one
Coadey: When I put a different CRT on the same dongle, it works OK.
ssieb: it claims to be using the DVI?
Coadey: And works like aces
ssieb: that's really wierd...
Coadey: I presume "(EE) RADEON(0): No encoder assigned to output!" would explain a video signal that appears to have no sync on it?
soreau: So anyway, I have this bug where the max res on kms/dri2 on radeon 9600 rv350 is 1152x864. When disabling dri2 with radeon.modeset=0, dri1 is initialized and the max is 1280x1024. Is there a bug report already, or do I need to file one?
soreau: 2.6.31_r3 kernel and all X components from git/x11 overlay on gentoo/xfce
Coadey: I think most folks are lurking Soreau, been quiet for an hour at least
soreau: Coadey: Can you show the output of 'xrandr --verbose'? (I still don't know what you're trying to ultimately accomplish)
Coadey: Oh I posted xrandr output, Xorg logs and other info at: http://etherpad.com/dvidisconnected
Coadey: I'm trying to resolve the problem with this CRT monitor not being seen as "connected", although it clearly is (by way of a DVI-to-VGA adapter). Another VGA CRT is recognized as "connected" OK.
Coadey: I'm sure it's a failure of DDC seeing it; but the "NoDDC" options have no effect, and I don't know how else to "force" it to understand it's connected.
soreau: idk, tried: xrandr --output