soreau: Had bad luck last time I tried something like that was more than a year ago
EruditeHermit: yeah I forgot how too
EruditeHermit: but hang on
EruditeHermit: xrandr --output LVDS --mode 1024x768
EruditeHermit: or whatever you want your mode
soreau: Alright, bbs with verdict
soreau: $ xrandr --output VGA-0 --mode 1280x1024
soreau: xrandr: cannot find mode 1280x1024
EruditeHermit: hmm hang on
EruditeHermit: read that
soreau: Not much help
soreau: EruditeHermit: Thanks anyway though
soreau: I wonder if there's a bug filed about this already and where to look if there is one
EruditeHermit: soreau: bugs.freedesktop.org
Coadey: soreau: thanks for the help earlier bbl
EruditeHermit: soreau: stick with DRI1 for now
EruditeHermit: soreau: suspend is not working for me in DRI2 so I am in DRI1 too for now
vehemens: radeon_screen.c uses RADEON_SCRATCH_REG_OFFSET for r600. doesn't appear to matter however.
nanonyme: vehemens: How's that?
vehemens: which part?
nanonyme: How so it doesn't matter?
vehemens: don't think that code path is being used. i could be wrong however.
nanonyme: Actually to me seems RADEON_SCRATCH_REG_OFFSET is used for both < R600 and higher in the file. *shrug*
vehemens: but not in drm
nanonyme: Hmm, so you mean radeonCreateScreen is never called or that it always fails before those lines or what?
nanonyme: is completely unaware what vehemens did to trace the codepath so is a bit confused
vehemens: greped the code
nanonyme: Yeah but how did you come to the conclusion that the code path isn't being used?
vehemens: educated guess
nanonyme: That's not a conclusion you can make by just grepping, really.
vehemens: hence "doesn't appear to matter"
nanonyme: To me it appears that the line is part of the line that sets screen->scratch to a value and screen->scratch is being used in radeon_bo_legacy.c to get boml->current_age.
vehemens: well then, it might matter.
nanonyme: Seriously, grep doesn't tell anything in that case, the actual context is in the previous line than what grep gives.
gimzo: Hi, Just asking is it possible to have ddccontrol working? I have R400 (radeon x700) and ddccontrol worked with fglrx, doesn't work with radeon. Thanks
AStorm: gimzo, what does that do?
gimzo: controls the (supported) monitor over ddc/ci
AStorm: uh? like the driver does?
AStorm: or does it do something more?
AStorm: ah, brightness/contrast and stuff? tried xrandr yet?
gimzo: this controls monitor itself, IE things you usually control using buttons on the monitor
gimzo: and it can (on samsung monitors) switch monitor profiles and turn on/off monitor itself (and it's scriptable so very useful with remote control)
AStorm: gimzo, hmmh
AStorm: I guess you should ask some dev about it
AStorm: but there are other priorities than neat features
osiris_: glisse: with legacy memory manager we are hitting an infinite loop when we are out of memory (radeonRefillCurrentDmaRegion tries to allocate new bo, if it fails it flushes the cmdbuf and tries again)
riri: hello, still a problem get get 2D accel on a 2400 HD card. It should work (someone with the same driver/xorg and the same xorg.conf has accel, but with a 2600 HD card
riri: Xorg.0.log: http://pastebin.org/4158
nanonyme: Also the same kernel modules?
riri: arf, don't know, but my drm module is loaded
riri: I can give the output of lsmod?
riri: or dmesg
nanonyme: AStorm: I disagree, I think KMS is a very neat feature. ;)
suokko: riri dmesg and modinfo radeon might help
nanonyme: riri: I'm not by computer atm but are you using kernel 2.6.30 with stock DRM modules?
nanonyme: If not, try that.
riri: 2.6.30, whatdo you call stock DRM modules ?
suokko: riri radeon.ko and drm.ko modules for your kernel
nanonyme: As in, that you haven't compiled kernel modules yourself from somewhere else.
riri: ho yes, stock kernel modules
riri: radeon is not loaded
nanonyme: And yeah, what suokko said.
riri: going back after loading it
riri: with updated dmesg :)
riri: arg, forgot to launch irssi in screen
suokko: I thought that xserver would load drm modules if they aren't loaded already
riri: Xorg.0.log http://pastebin.org/4159
riri: dmesg http://pastebin.org/4160
riri: modinfo radeon http://pastebin.org/4162
riri: Xorg.0.log says Direct rendering is disabled, but do not says what
riri: maybe xorg.conf too http://pastebin.org/4163
AStorm: nanonyme, yeah, but KMS is a major feature
AStorm: while DDC control is a minor one
nanonyme: 15:01 < AStorm> but there are other priorities than neat features
nanonyme: Well, true, you can apparently interpret that in a different way too.
AStorm: sure, porting the driver to a new framework doesn't count as feature for me
riri: ho, I use the framebuffer (with vesa fb) for the console before X is loaded. Can this disturb X?
nanonyme: I suppose it *can* but whether it actually does, no idea.
AStorm: I've used this setup myself
AStorm: on various machines
AStorm: (with various radeon cards)
nanonyme: X and fb probably have learned to cooperate pretty well, yes.
AStorm: it did explode in the past
AStorm: but that was a long time ago
nanonyme: riri: Is the other person who got it to work with the same setup as you running the same distro, btw?
nanonyme: Trying to rule out distro hacks.
suokko: riri: what about /dev/dri/card0 ? Is it created and does your user have permission to use it? (probably you should be in group video)
riri: nanonyme: yes I found his post yesterday on the distro forum, saying last radeon driver update was giving him good performances
suokko: And does someone know if mtrr warning in dmesg could cause problems?
nanonyme: suokko: If you noticed from the log, it doesn't even *try* to open the dri device.
riri: /dev/dri/card0 is rw for video, and I'm in this group
nanonyme: Now a good question is why.
suokko: So kernel part should be working ... there is something wrong in ddx driver probably
riri: what's ddx?
nanonyme: X driver, that is in your case the radeon driver.
nanonyme: I'd try compiling an installing a release version and seeing if it behaves any different.
suokko: riri: What distro are you using?
riri: arch linux
nanonyme: suokko: Build Operating System line is a bit of a spoilsport there. ;)
riri: but I have the same problem with ubuntu or fedora (tested)
riri: not: unless i disable the glx module, Xorg freeze (not the process, just the screen) at startup, with nothing interesting in the log file
riri: in fact, it seems to be so slow that program can't get cpu time (seen with htop on the console)
suokko: IS it possible that hd2400 would need some quirck?
riri: it would be nice to know :)
nanonyme: Technically yes, in practise I'd be surprised if it didn't already have the quirks it needs since it sounds like an old card.
nanonyme: riri: It's not AGP, is it?
riri: yes it is
riri: AGP v3 (8x)
riri: if I remember well
nanonyme: Could also be an AGP quirk required then.
nanonyme: (that is, if it needs any)
nanonyme: riri: But yeah, as I said, I'd try to compile a release version of xf86-video-ati and see if it tries to start dri.
suokko: riri: you can get source from http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
riri: I can try
riri: fresh distro install, I've to install some things to compile (and get the sources with git)
suokko: Then it requires small configuration to use alternative driver location if you don't want to overwrite /usr files
riri: I suppose there's a little howto somewhere (maybe in the source tree) to do this config?
nanonyme: riri: Actually I didn't recommend installing the git version but just compiling and installing a release version yourself to make sure it's not just that your distro's version is somehow broken.
nanonyme: 6.12.2 would probably be fine.
nanonyme: (you can always install from git too though if you wish)
suokko: riri: http://paste.debian.net/42646/ that is what I have (I use --prefix=/opt/local in configure)
suokko: 2nd path is my distro driver location for all others drivers
riri: ho, that's simple
nanonyme: You also need to set it up in xorg.conf though.
nanonyme: Iirc ModulePath or something similar inside Section "Files".
nanonyme: Xorg log gives a sample of what the path should be like.
riri: nanonyme: suokko pastebin shows that
nanonyme: Oh, right.
nanonyme: Missed that.
nanonyme: must be going blind
nanonyme: suokko: I'd do ModulePath "/opt/local/lib/xorg/modules,/usr/lib/xorg/modules", btw.
nanonyme: Iirc those are not additive but the second overrides the first.
suokko: oops. yes. I just have the first one commented out now because I'm not using self compiled driver
suokko: (just a memory aid if I compile ddx for some reason)
nanonyme: Yeah, you can have both.
riri: I have to get all source trees mentionned in http://www.x.org/wiki/radeon ?
nanonyme: First is preferred over the second.
nanonyme: riri: Likely not.
nanonyme: You might need to install development packages for your existing X.org components though, unsure how Arch works that out.
suokko: riri: Very unlikely with arch because there shoudl be new enough packages
suokko: but something like apt-get build-dep xf86-video-ati should install everything
riri: nanonyme: on arch, no special dev package (included)
suokko: I don't know packman syntax
nanonyme: Then it should just work, likely.
nanonyme: suspects he's finally getting the hang of inline Assembly
riri: GL/glxint.h is missing, but I've GL/ headers from mesa
riri: I'm missing some X packages I'm sure
riri: error reported for radeon_accel.o of course :)
nanonyme: riri: try installing glproto.
riri: hmmm, I should try a release version
riri: the git version does not compile (at least with my gcc 4.4)
nanonyme: What's the build error?
riri: In function ‘radeon_dri2_create_buffer’
nanonyme: Rename all the instances of DRI2BufferPtr to DRI2Buffer2Ptr inside the file.
riri: 8 substs
riri: worked, and built
riri: ok, giving it a try....
riri: ok, back, Loading /opt/local/xorg/lib/xorg/modules/drivers//radeon_drv.so
riri: but still: (WW) RADEON(0): Direct rendering disabled
riri: http://pastebin.org/4167 (a new line, line 410 for KMS tough)
riri: taking a smoking pause, back soon
suokko: (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead
suokko: Just noticed that in logs
suokko: nanonyme: Is hd2400 IGP?
nanonyme: suokko: He/she said it's AGP.
riri: AGP card, not integrated, 512Mo RAM
nanonyme: Right. Hard to say sometimes.
suokko: How to enable verbose xorg.log?
riri: -logverbose n in the man page
riri: defaults to 3, I don't until which number I can give
suokko: But anyway. I have guess that DRIFinishScreenInit call might be failing
suokko: riri: You could try to run x with logverbose put to 7 or something
suokko: Then there might be more verbose log to make it easier to find which function call is failing
osiris_: ok, VBOs proved to be working. in sauerbraten it gives up to 15 more FPS depending on the scene, in painkiller up to 8 fps
osiris_: I believe it could give more FPS when we had texture, color and depth buffer tiling implemented
osiris_: agd5f or glisse: are all KMS performance regressions resolved already?
riri: Xorg.0.log http://pastebin.org/4168
riri: does not seem to give more info, maybe I could go up to 9?
riri: I could add message in my own built driver, if you tell me what to put and where
suokko: I'm jsut now trying to trace what is happening in intialization to understand why dri is disabled
glisse: airlied: this what should be done according to doc
glisse: osiris_: i only see a problem if the bo allocation request is bigger than what we can allocate
suokko: still has huge overhead for memory allocation (cache control) with r200 agp card in kms mode
suokko: riri: What does xorg log include if you run it glx module loaded in?
riri: I restart X with it
suokko: glisse: Is there any git tree that includes all the latest kernel changes? (like your pool allocator)
glisse: suokko: don't know any
glisse: you need to apply patch manualy
glisse: not hard
glisse: git am patchfilename
suokko: I know but it is hard to find all the patches from mailing list
riri: xorg.log with glx enabled: http://pastebin.org/4169
suokko: (Specially knowing which patches are already included to vanilla kernel)
riri: with a black screen
suokko: Did it freeze in statup?
riri: but screen freeze only
riri: programs are started after X init (gnome desktop)
suokko: When does it freeze?
riri: at startup
suokko: I mean is it first rendering something or jsut black screen?
riri: after the vt switch, the screen stay black
riri: on another distro, with gdm, gdm is displayed, but the screen is corrupted
riri: I get the same thing on fedora
riri: without a dm (simple xinit), just a black screen
suokko: Sounds like your card needs some special handling
riri: which info can I give information to help developpers, and how?
suokko: riri: Option "AGPMode" "4" mgiht help
suokko: You can try it
suokko: or if that doesn't help then Option "BusType" "PCI" might also help
riri: I remove other options? (AccelMethod, DRI, RenderAccel)
riri: ok I try
suokko: first one just sets slower agp mode to test if it helps and 2nd disables agp
riri: AGPMode did not changed anything
riri: forcing bus type to PCI permited me to start X with the glx module
riri: arrrrhhhh, moving windows is weird :)
riri: xorg.log http://pastebin.org/4171
suokko: riri: Can you open bug report to https://bugs.freedesktop.org/enter_bug.cgi?product=xorg with lspci -vvvnn and xorg.log from pci mode and agp mode?
suokko: I think there is some hardware bug that has to be worked around.
riri: suokko: ok
suokko: (Component is Driver/Radeon)
riri: bug created
riri: hmmm, diner time :)
riri: many thanks for time spent on my problem
riri: Alex Deucher said me to set the BusType to PCIE
riri: and it's ok
riri: xdriinfo says: Screen 0: r600
riri: agd5f: for the forced PCIE bus type (http://bugs.freedesktop.org/show_bug.cgi?id=22943), the driver should work with the default no? If so, do I have to open another bug report?
agd5f: riri: it should work by default. that's why I asked about the apg aperture
riri: ho sorry
agd5f: riri: although agp is always trouble
riri: remembering 128, but not sure 100%
riri: I'll add a comment on the bug after reboot
riri: I believe you :)
AStorm: hey, what was the xrandr line to copy an output?
BialyTygrys1: anyone had a problem with ibm t60 and x1300 under fedora 10?
BialyTygrys1: problem is when i close the laptop and then try to wake it up
BialyTygrys1: only vertical strips show and nothing else
BialyTygrys1: also when i watch avi swf and so on horizontal strips show from time to time
BialyTygrys1: under win xp everything was fine
AStorm: apples, oranges
AStorm: give xorg.log and hope that some dev is available
Esmil: For a long time I had this kernel error: http://pastebin.org/4215 when trying out kms enabled kernel. Just for kicks I made this silly change http://pastebin.org/4216 and suddenly everything works. X, Compiz, glxgears and all, so I'm guessing that flag isn't set although it should be..
airlied: glisse: docs where?
glisse: airlied: basicly it says that if you got border or some other stuff active you need to align texture on pow2 size
glisse: let me find the page
glisse: airlied: page 210 in r5xx spec
glisse: when wrapping or mirroring ....
glisse: so if mipmap it needs to be padded to power of 2
Insight: Are there any FreeBSD users / developers in here?
glisse: Insight: i think rnoland and adamk are BSDer :)
Insight: Rnoland is in here?
Insight: Ah, I see him, thanks
glisse: welll zzzzZZZZzzz &
airlied: glisse: cool thanks
Insight: Are there any small tasks (code cleaning, documentation) that need to be done?
kuaera: I was wondering, with the release of Mesa 7.5 and its rudimentary OpenGL 2.0 support, if it is likely the open source ATi driver would gain OpenGL 2.0 support within the year?
bobbens: kuaera: they way I understand it, the ati driver will get opengl 1.5 and later only through gallium3d/gem and friends, no idea when that will be ready, but I'm no ati coder :)
vehemens: seeing engine fault with an error: [drm:pid1489:r600_cs_packet3] *ERROR* bad DRAW_INDEX_IMMD
suokko: Insight: I think all code needs some extra comments if you want to add some
suokko: (more comments would make it easier for new developers to write code)
Insight: Thanks, I'll dig right in
kuaera: bobbens: Well, I think Mesa 7.5 has OpenGL 2 through Gallium3D
vehemens: i may be misreading the code, but shouldn't r700RunRender use "numIndices = vb->Primitive[i].count + 1"?
boghog: no clue, but I do have problems rendering indexed VBOs on my rv770 :D
boghog: which I don't have when I use non-indexed geometry i should add
boghog: or had anyway, haven't tested it since a few days ago
vehemens: the change allows engine to run. i missed at least one other correction however.
vehemens: getting into a n versus n-1 issue. the asic doc isn't all that clear.
vehemens: the other change seems to be "lastIndex += numIndices - 1"
spstarr: listens to Game Show theme songs and reminisces
spstarr: listens to Game Show theme songs and reminisces
Leftmost: Is there a timeline in mind for the next release of -video-ati?
bridgman: I'm not aware of a plan, but I expect it will be in time for inclusion in the next round of distro releases
Leftmost: Hmm. Ubuntu at least seem to think so. They're using a git snapshot in Karmic.
bridgman: I haven't checked the distro schedules but it's probably coming up to the right time for a release
bridgman: I believe the release planning process consists of slapping one's forehead, exclaiming "yeah, we haven't done a release for a while", and making a release ;)
bridgman: it's not clear to me that releases do any good these days; they used to encourage distros to pull in new code, but my feeling is that these days they just encourage the use of old code (the last release)
Leftmost: Well, a lot of distros are presumably somewhat uncomfortable about snapshotting and moreso about live packages.
Leftmost: It'd be nice if some of the support was more pluggable (I have an RV740 card, so I'm interested in that support :)) but that's a pipedream.
bridgman: pluggable ?
amarsh04: noticed that Debian unstable just released xserver-xorg-video-radeon 1:6.12.2-3
Leftmost: Requiring the modification of a config file somewhere, rather than modification and recompilation of source.
bridgman: occasionally that's possible, but we normally change enough from one chip to the next that the config file would be huge
bridgman: that said, it probably wouldn't hurt to put devicd IDs in a config file; occasionally that's all it takes
Leftmost: I believe that's the sum of the RV740 changes.
Leftmost: Except for some quirks, I think, none of which apply to my card.
bridgman: for display, yes - but AFAIK there are other changes for the 3D engine
bridgman: the SIMD configuration is different from anything we have done before
bridgman: I'm just looking through the changes... looks like about 50 lines of new code
bridgman: for the specific case of rv740 most of those could have gone in a config file if the config file was big enough ;)
bridgman: but at some point it becomes easier to just tweak the source and rebuild
DanaG: Oh yeah, any major new stuff since the last news of glxgears?
DanaG: On R600, I mean.
bridgman: lots of little fixes; most of the demos run now
bridgman: everyone's trying to get textures working; right now every detail looks correct except for them actually *working*
bridgman: there's still frequent "distortion", ie stuff gets drawn in the wrong place
bridgman: smells like unintended re-use of an old buffer or something
bridgman: once those are fixed, next step should be speeding up back-front copy and then it should start to be useable
bridgman: some of the demos actually look pretty good; singlebuffer, reflect, couple of others
boghog: and my indexed VBOs dont work!
bridgman: not as good as nexuiz will look though ;)
bridgman: yeah, I saw the comment earlier; does the change vehemens suggested help ?
bridgman: or do they "not work with extreme prejudice" ?
boghog: haven't been able to try it yet, but I will once I get my testapp working again
boghog: the problem looked as though they werent indexed properly, the vertices were right but the triangles were drawn between the wrong ones :p
bridgman: yeah, that sounds kinda out-by-one-ish
bridgman: it's rough when you mix engineers and computer science folks
bridgman: half of them start at zero, the rest start at 1
boghog: i actually tried to work around it by offsetting the indexes in my app by 1 but couldn't really get that to work
boghog: i would test it right now except i started refactoring some stuff and it's going horribly wrong :p
boghog: wishes he had put it in svn or git
DanaG: "right now every detail looks correct except for them actually *working*" -- really awesome quote.
bridgman: it's been pretty frustrating; there was talk about rewriting the texture code from scratch in the hope that something would accidentally be different and make it work ;)
DanaG: oh yeah, another goal to work for: rss-glx screensavers. =P
bridgman: yeah, the killer app for OpenGL
vehemens: bridgman: what's the time table of the "little fixes" being placed in git?
bridgman: the frustrating part is that textures were working before we ported across to radeon-rewrite code base
bridgman: each little fix will go into git within one second of us figuring out what to fix ;)
bridgman: it's the figuring out part that is harder to predict ;)
bridgman: but so much of the low level code changed with radeon-rewrite that it's not really feasible to bisect the changes
bridgman: if we had been in master before the radeon-rewrite changes it would have been easier
vehemens: no comment :>
bridgman: I don't know enough about git to know whether it's practical to (a) merge the old 6xx code into a copy of old master, (b) merge new master on top, (c) bisect that composite branch
bridgman: anyways, we're going to try to accomplish the same thing manually next week; taking the state-related changes and pushing them back into the old working driver to see if it still works
vehemens: it doesn't appear to be that broken. after all, i got something to work.
bridgman: texture related ?
bridgman: that's my other big fear, finding out that textures have been working all the time and that we just expected more from the demos ;)
vehemens: maybe a locking or ordering problem. just tried running both engine and gears, and gears are showing up in engine.
vehemens: kinda neat in a way
bridgman: yeah, that's the wierd one
bridgman: but it should be a good clue for finding the problem
Leftmost: Out of curiosity, is 3D for R600 and R700 generally the same or are there significant differences? (Knowing next to nothing about low-level 3D implementation...)
bridgman: generally the same
boghog: fwiw texturing was indeed not working for my own app either
bridgman: 7xx has some extra shader instructions, a few hardware blocks have been taken out and moved into shaders, a few registers moved
bridgman: mostly a completely different implementation of the same programming model
bridgman: maybe not "completely different", but "different"
bridgman: design of the individual blocks was more compact, so ~2.5x as much hardware without making the die that much bigger
Leftmost: Interesting. Thanks.
spstarr: mr bridgman
bridgman: hi spstarr