Nightwulf|work: hi all
Che-Anarc: Are the radeonhd drivers better than ati-drivers? I'm having some problems with video playback on hd 3650 else everything else as far as 3d / opengl with ati-drivers is fine.
MostAwesomeDude: Che-Anarc: You mean fglrx.
Che-Anarc: yeah
MostAwesomeDude: But no, no acceleration on either of the open drivers yet.
Che-Anarc: Thanks.... guess I'll have to wait for a newer ati release... its just the refresh lines on the playback that are annoying... its apparently a known issue? :-s
MostAwesomeDude: fglrx == suck
MostAwesomeDude: Yes, known issue. :3
Honk: video playback works fine without accel on my 2900xt with radeonhd =)
ndim: Does anyone have an idea where the __user and DEPRECATED macros are being defined, and what their purpose is?
libv: are we using them in the driver?
ndim: Yes.
ndim: src/radeon_drm.h
libv: oh, right... stuff we inherited
ndim: Which causes build failures on rawhide-aka-F10 but not on F9.
ndim: Whyever.
libv: hrm...
libv: drm/drm.h:# define DEPRECATED __attribute__ ((deprecated))
libv: drm/drm.h:# define DEPRECATED
libv: drm.h:#ifndef __user
libv: drm.h:#define __user
libv: on an opensuse 10.3
libv: so...
libv: redhat is shifting more stuff around in the drm headers which are breaking things all over?
libv: or are we wrongfully including radeon_drm.h?
ndim: Oh.
ndim: First time we had any kind of direct dependence of that kind to external headers.
libv: this is in /usr/include/drm/drm.h
ndim: Now I know where to look for the issue.
ndim: Thanks.
libv: ndim: you know how we try to not include headers inside headers?
libv: and why we try to keep the list of includes per file as limited as possible?
libv: and why we also try to not use typedefs in things like RHDRec
libv: so that we are not wholesale hit by things like this
libv: and that damage is limited to only a few files
libv: in this case rhd_dri.c and rhd_cs.c, as i'm working on CS atm
libv: not sure how wide and far radeon_drm.h is spread in the case of master
libv: not many drivers have such a policy for header inclusions :)
libv: but then, the developers of this driver do have experience
ndim: Now that I know where to look and what to look for, I will find a solution.
libv: (although -unichrome is notsonice in this respect)
libv: (yet)
libv: ndim: :)
libv: just use #define DEPRECATED
libv: and #define __user
libv: it's what drm.h does anyway
ndim: Funny thing is... -D__user -DDEPRECATED didn't help. But whatever... I know what to dig for now.
libv: actually... let's hack radeon_drm.h directly
libv: and add the following
libv: #ifndef __user
libv: #define __user
libv: #endif
libv: #ifdef __GNUC__
libv: # define DEPRECATED __attribute__ ((deprecated))
libv: #else
libv: # define DEPRECATED
libv: #endif
libv: if the fallout is too big
libv: in case of CS, i'll just do it for the two files that need this
ndim: sed -i 's/ __user / /g; s/ DEPRECATED;/;/g' src/radeon_drm.h
ndim: :)
libv: :)
ndim: I guess radeon_drm.h should just include drm/drm.h when it is using stuff defined there?
libv: but drm.h should already be included before this radeon_drm.h is included
libv: as said before, don't include in includes :)
libv: as that's asking for fallout all over the tree in the long run :)
ndim: In library headers maybe. But some driver internal header including a library header?
ndim: Hmm.
agd5f: actually emmes switched to using radeon_drm.h directly. we used to use a local version in the ddx
libv: agd5f: using the in-tree version directly, or using the one in the system headers directly?
agd5f: libv: in tree
libv: ndim: you'll find that drm.h is already included where radeon_drm.h is included.
libv: ndim: dri.h includes xf86drm.h which includes drm.h
libv: and for rhd_cs.c that becomes xf86drm.h -> drm.h
libv: *git-pulls drm*
libv: weird... this still has those macros
ndim: I have no idea what is happening here either.
ndim: I am currently examining the mock chroots in which I build the stuff locally - but the F10 chroots used by the Fedora buildservers have the same issue.
ndim: as my local F10 chroot.
libv: ndim: some of the included headers are no longer including drm.h either directly or indirectly?
marcheu: ndim: __user means that it's user space data. you must not remove it
ndim: marcheu: In kernel code maybe, but the radeonhd runs in userspace 100%.
marcheu: ndim: oh really, what's that CS branch about ?
libv: marcheu: there's drm code in master as well :)
ndim: but userspace code.
libv: and my direct cp stuff is still not in the main tree :)
marcheu: ndim: you still can't remove the __user
libv: marcheu: i wouldn't remove __user either... we need to track down where the include of drm.h is missing from now
libv: and possibly include xf86drm.h or drm.h directly there
ndim: That is what I am doing.
libv: ndim: :)
marcheu: that header is shared with the kernel, if you remove __user the kernel can't keep track of what's user space
ndim: Digging around in the F10 chroot.
marcheu: but yeah, when compiled from user space it's probably emptied
ndim: marcheu: I am removing that in the spec file which builds radeonhd packages - that cannot break anything but that radeonhd userspace binary.
ndim: And nothing is committed to anywhere yet.
ndim: OK, I have tracked it down... to magic.
ndim: :)
MostAwesomeDude: ndim: Yay?
ndim: MostAwesomeDude: Reworse engineering magic now.
libv: ndim: eh?
MostAwesomeDude: "reworse?"
libv: ndim: so it magically works now?
ndim: libv: The only conceivable reason for the difference in F9 and F10 builds so far, according to the hard evidence, is magic.
ndim: I have compiled with -save-temps on both systems, and compared the resulting radeon_accel.i files.
airlied: ndim: F10 now installs the drm headesr from the kernel.
ndim: Both include drm/drm.h
airlied: not the drm headers from libdrm.
airlied: that may cause a difference..
ndim: airlied: Yeah, that is the difference.
ndim: The kernel version does not define __user or DEPRECATED for obvious reason.
ndim: OK... CPPFLAGS='-D__user="" -DDEPRECATED=""' helps.
zhasha: Hey, I've been trying to figure this out from various wikis and such so forgive me for asking a stupid question
zhasha: in the case of radeonhd, what is the function of the r300 dri driver from mesa3d?
airlied: zhasha: it accelerates 3D
zhasha: whats the function of radeonhd then?
Obscene_CNN: to allow the use of 3d acceleration
zhasha: very confusing indeed :P
airlied: zhasha: its a 2D driver.
airlied: and card init .
zhasha: so GL extensions and such is in the mesa r300 driver?
zhasha: no wonder i couldn't find anything in the radeonhd tree
airlied: zhasha: yes 3D is done client side, the GL app loads the driver.
zhasha: so say someone wants to help out with bringing the radeon(hd) driver up to gl 2.1, one would really have to work on mesa and not the radeon(hd) code
airlied: zhasha mostly..
airlied: we do most of thE GL work in #radeon
zhasha: as you can probably tell i wont be coding anything this low level for a long time :P
airlied: zhasha: MostAwesomeDude is trying to work towards getting GL 2.0
zhasha: yeah, he told me
zhasha: but theres still work to be done on the memory manager for fbos
airlied: that'll happen in radeon first.
zhasha: do we even have gl 1.4 support yet?
airlied: radeonhd will have to port it when its done if they awnt.
airlied: zhasha: nope, MAD is trying to add the missing bits for that.
airlied: fog and something else.
zhasha: why is it we even have radeonhd if i may ask. radeon supports all cards and radeonhd is well for all i can see, slower
airlied: zhasha: don't know, Novell need to spend their time on something I suppose
zhasha: so its really not doing anyone any good?
Obscene_CNN: each driver has their strengths and weakness
airlied: it has places it works apparantly.. I'm not one to comment due to bias :)
zhasha: do you work for novell, airlied?
Obscene_CNN: I was able to get radeonhd to work with my hardware first
MostAwesomeDude: zhasha: We're missing fog coords and point smoothing from GL 1.4.
MostAwesomeDude: Technically, we're missing a *lot* of kinds of smoothing.
zhasha: man it's been way too long since I've toyed with a fixed pipeline
ndim: With radeonhd, I can get a bug set different from radeon. Comes in really handy when one works and the other does not. Black screens, kernel panics, total system hangs... especially popular in connection with DRM :)
MostAwesomeDude: airlied: Isn't most of the FBO stuff in GEM/bufmgr?
airlied: MostAwesomeDude: you need DDX to support the memory manager
airlied: zhasha: nope the other one.
MostAwesomeDude: airlied: But, I mean, aren't FBOs constructed by Mesa?
airlied: MostAwesomeDude: the FBOs are all client side, its more the infrastructure needed behine the scense
MostAwesomeDude: Ah.
libv: airlied: and you're spending your time on what, exactly?
zhasha: heh, I'd be happy to help out, it's just that i don't know jack **** about this subject :P
airlied: writing a memory manager, porting 2D/3D drivesr to it, porting modesetting to the kernel, fixing bugs in radeon, releasing F10, backporting radeon to RHEL5..
libv: right... and you're spending your time on radeon why... exactly?
zhasha: why would you port radeon to RHEL5?
ndim: zhasha: To have support for certain classes of hardware.
ndim: That one seems obvious. :)
airlied: libv: because it drivers all the chips I have to work on.
zhasha: sorry I still don't get it
libv: zhasha: it makes way more sense to keep a driver backwards compatible, with less features where needed, than it is to do backporting btw
libv: zhasha: this is how driver like -sis, -unichrome and -radeonhd work
zhasha: okay then. carry on
libv: in as far as the former two still see active development
airlied: I had to backport EXA, that isn't possible with a few build system tricks.
libv: airlied: why not use radeonhd for r500+
airlied: libv: because it provides no advantage whatsoever?
libv: heh, and you are making sure that it stays that way instead of actively cooperating?
MostAwesomeDude: libv: radeon *has* to be ported to KMS+GEM; if radeonhd is to be ported, that is double the work and I would expect the radeonhd, not radeon, devs to have to pick that up. OTOH I'm silly. :3
libv: MostAwesomeDude: still doesn't explain why airlied is not even trying to work on radeonhd
airlied: libv: because it provides no advantage over working on radeon
MostAwesomeDude: libv: I can't remember, but I don't think that Fedora ships radeonhd, which would mean that it'd be unpaid work for him.
airlied: MostAwesomeDude: no we do ship it
airlied: MostAwesomeDude: we don't maintain it
MostAwesomeDude: Ah.
airlied: but Fedora has community maintained radeonhd... ndim packages it I think
libv: airlied: but there were so many instances in the past where it did have obvious advantages over radeon
MostAwesomeDude: Sorry, trying to listen to presentation and debug GLSL dump at same time...
libv: airlied: like before you added r5xx+ support to radeon
MostAwesomeDude: libv: You speak truth. I used -avivo and -radeonhd until -radeon started to offer r5xx acceleration.
airlied: libv: radeonhd had no accel.. I needed accel, I knew accel would work from radeon, I didn't need another wheel to write.
airlied: porting atombios to radeon was a lot easier than porting accel to radeonhd.
airlied: as Alex proved, it took a lot longer to do that.
Zajec: airlied: you said you work on KMS+GEM for radeon... do you have any progress / ETA on any one of them?
libv: airlied: alex his port of radeon accel was actually done in a matter of days
MostAwesomeDude: Zajec: It works, except when it doesn't. :3
libv: airlied: while it took in the order of months to get similar modesetting functionality into radeon
Zajec: :P
airlied: libv: I had it working in two days, I didn't release it for months
Zajec: MostAwesomeDude: can we expect this in stable kernel soon? .28 maybe?
airlied: a big difference..
libv: airlied: you had what working in two days?
airlied: but that was due to legal issues between AMD and RedHat..
MostAwesomeDude: Zajec: Don't ask me, I have no idea.
airlied: libv: yes atombios to get CRT/DV was two days.
libv: airlied: vga out?
airlied: LVDS took a few more... as I had no hardware
libv: airlied: with all the pitfalls taken neatly off of radeonhd too as i recall :)
airlied: libv: so what I reused MIT code, it is how this stuff works..
airlied: its called open source..
libv: still... wasn't exactly a matter of days
airlied: Zajec: F10 beta has initial GEM/KMS
libv: and at least in the accel case, it is easy to spot where what code came from too
Zajec: airlied: what about vanilla?
airlied: Zajec: not until after Intel GEM/KMS goes to Linus.
Zajec: airlied: ok, thanks :)
libv: in any case... "no advantage" holds very little water.
airlied: and probably need to do a proper 3D driver port.
airlied: Zajec: so far the 3D driver is just emulating the old memory manager
libv: and it's clear to most that there is quite a bit more than "no advantage" in this whole story
sim__: Hi all. Does ATI Radeon Mobility HD3650 supported by radeonhd ?
libv: sim__: yes, but we still have some modesetting issue on some panels
sim__: Ok. I tried radeonhd, but I've got a blank screen so far. Xorg said : Unknown card detected: 0x9591:0x1179:0xFF1E
Zajec: sim__: check my answer :)
Zajec: sim__: checking up-to-date version if first thing you should do
libvde: sim__: sounds like that bug alright :)
libvde: sim__: egbert managed to reproduce it during our companies big conference last week, but we have had no access to the hardware since
libvde: iirc, register dumps showed nothing different, so it is a timing issue
awosy: is there any note on a new release of the driver? (with 3D support? )
libvde: awosy: the driver has been moving too much for us to make a hasty release :)
sim__: Ok Hope this will be fixed soon. I'm using radeon driver with basic support
libvde: awosy: we need to fix up some issues before we release
awosy: i know work is being done :)
awosy: just wanted to have an update about it
awosy: would be nice to have some kde4 effect running with the radeonhd driver
sim__: I just saw your answer Rafal, gonna try now, Thx !
Zajec: awosy: somewhere on Phoronix you can find that R600 documentation should be avaiable in September for public
Zajec: hm, guee he didn't manage to read :)
Obscene_CNN: whats the equivalent r6xx core to a RS780V/M780V
libvde: Obscene_CNN: i think from a 3d pov it is a rv610 or HD2400
libvde: from a modesetting pov it is an rv620/635 with some extra restrictions and specialities as it is igp
Obscene_CNN: thanks
libvde: Obscene_CNN: from a performance pov it actually compares quite favourably to a rv610
libvde: rs780/790s are the most powerful IGPs out there
Obscene_CNN: thats good to hear
Agiofws: hello
Agiofws: anyone running ati drivers latest fglrx with 2.6.26 ?
LinuxDonald: Agiofws that here is the channel of the opensource radeonhd driver
Agiofws: fglrx-driver - non-free AMD/ATI r5xx, r6xx display driver
LinuxDonald: fglrx diver is closed source
Agiofws: i know
Agiofws: does radeon hd provide 3d acceleration ?
yangman: Agiofws: for r5xx chips only. X1xxx series cards, basically
Agiofws: yangman, 2600HD is ?
Agiofws: RV630: Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600
Agiofws: so no support
Agiofws: cool
Agiofws: !