rainbyte: hi
mattmatteh: hi
rainbyte: I have a question...
rainbyte: I'm testing the latest drivers with GEM activated, DRI2 and the other new features
rainbyte: 2D and XV work ok, but I would like to help debuging 3D
rainbyte: (some apps are a bit unstable)
rainbyte: I would like to know how to start with this (I am not a xorg developer)
cxo: it would help if you knew which driver you were using
rainbyte: I'm using xf86-video-intel 2.6.1
rainbyte: but I can upgrade to git
rainbyte: also I'm using mesa 7.3
cxo: its quite difficult to debug this crap because of all the levels of indirection, i suggest start with gdb and run your apps and see what happens
rainbyte: ok, i'll try that
rainbyte: I think I saw a page of the xorg wiki that shows how to debug the drivers
rainbyte: but I can't find it now, maybe it was from other wiki
rainbyte: cxo, maybe you know where can I find that information
cxo: well there is kgdb
rainbyte: cxo, I found it, the link wasn't ok the last time but know it is working, thank
rainbyte: *+s
cxo: join the driver mailing list if you want to help
rainbyte: yes, I did it
rainbyte: and also I have joined to the irc channel
rainbyte: I asked there without answer
rainbyte: I'm interested in this because I would like to work also on the AMD/Ati drivers for my HD2400 (after recovering my desktop pc, because it is not here now)
cxo: its a pain in the ass rainbyte
cxo: the linux video/3d drive stack is horrible
cxo: hopefully gallium3d will replace most of it
cxo: Apps -> libGL -> Xorg driver -> Kernel drivers (DRI, DRM) -> hardware
cxo: problem is that there are no rules to where what should go
rainbyte: yes, I thought that Intel drivers were working ok, but I really Catalyst
rainbyte: xD
cxo: so basically you could write the entire driver in the kernel and just have return calls all the way to userspace
rainbyte: *prefer
cxo: so each developer wants to put different things in different places
rainbyte: that's a problem
cxo: which makes a total mess of everything
rainbyte: but, at the end with all this movement
rainbyte: only kms and gem/ttm will stay in the kernel
cxo: Nvidia has the best driver because they dont rely on all this crap
cxo: they have it all, in the blob,
mattmatteh: hates blobs
rainbyte: yes, I knew that
mattmatteh: likes working thought :S
mattmatteh: s/thought/though
rainbyte: they have other driver architecture
cxo: ATi's catalyst driver tries to use all the linux services, DRI, DRM, etc..
cxo: and because its such a mess, it too fails miserably
rainbyte: they could try to implement other architecture for their drivers
rainbyte: but that would be slow
rainbyte: cxo, and what about if AMD/Ati helps to code the opensource drivers but make some kind of closed source libriry for special features
rainbyte: something like the intel_hal.so
cxo: Nvidia's driver is a complete port of their Windows driver, it uses almost nothing from Linux
cxo: I think gallium is the only saving grace Linux has
rainbyte: cxo, but it needs time
rainbyte: I think that making a binary library for AMD/Ati opensource drivers would be a solution
rainbyte: it would speed up the development of this new technologies
cxo: i understand what you are saying. If the open source driver doesnt know how to do X, ask the ati driver to do it
rainbyte: and they can protect their top secret information with that closed source library, that would be optional
cxo: in implementation its very complicated, because the driver architecture and memory model could be very different
rainbyte: well, they can port important parts of Catalyst
rainbyte: it would be new fresh and stable code
cxo: there would have to be some sort of interface between the drivers
rainbyte: intel_hal.so
rainbyte: The driver source contains references to a currently-unavailable binary named "intel_hal.so". It is entirely optional, and the advantages are not clear; ostensibly they are increased performance and/or additional features.
rainbyte: the open source code indicate that it contains or contained (at least) Macrovision support and some minor, optional 3D optimization routines.
rainbyte: we could use UVD and 3D optimizations in that library
rainbyte: cxo, I think that the main problem of fglrx is compatibility and stability, both would be solved in this way
rainbyte: AMD/Ati would have and stable driver for workstation users with all the optimizations needed for their work, and normal users would have basic 3d, xv and 2d with the opensource driver and UVD or 3D optimizations with the library
rainbyte: I think that this is similar to what Intel is trying to do with libva
cxo: fglrx issues are because they very crappy libGL.so
cxo: ^they use
rainbyte: mmm, maybe
rainbyte: cxo, I would do waht Via is doing
rainbyte: working directly upstream
cxo: if you build against mesa libgl, you are off to the races
cxo: but its almost never going to happen because every vendor thinks they can do it "better" with their own opengl
rainbyte: I don't think that they will opensource the critical info of chrome9 chips, but they will work on a binary libva library after, I'm pretty sure
rainbyte: I would like to ask Bridgman if making this kind of library is posible
rainbyte: maybe on the forums
rainbyte: cxo, what do you think, would it be better to post on the "Ask ATI" dev thread or a new thread in the Open-Source AMD/ATI Linux forum?
cxo: ask ATi, is good, bridgman checks that
cxo: you can start a new thread, and link to it
cxo: i think thats best
rainbyte: ok
rainbyte: http://www.phoronix.com/forums/showthread.php?t=6585&page=57
rainbyte: It is ready, we have to wait the answer from Bridgman
rainbyte: cxo, do you have his phone number? maybe I can call him to ask
rainbyte: xD
cxo: well just call ATi, and ask to speak with him
rainbyte: hehe, good idea
cxo: His name is John
cxo: John Bridgman
rainbyte: yes, i read it in his Phoronix profile
rainbyte: all the info is there, except the UVD specs
rainbyte: xD
rainbyte: cxo, other thing..
cxo: ?
rainbyte: do you think that would be posible to implement some kind of DirectX compat layer on top of Gallium?
rainbyte: you know, for wine and port some apps
cxo: yes
cxo: Thats basically one of the purposes of gallium
cxo: Gallium has two purposes 1) Unified driver<-> OS interface 2) Unified library<->driver interface
rainbyte: mmm, that's good, when I read the articles I though that but I wasn't completely sure
rainbyte: sometimes the info given to the end-users it is not clear
cxo: http://www.tungstengraphics.com/technologies/gallium3d.html
rainbyte: I wonder if this would be legal
rainbyte: maybe that's the real problem
cxo: its legal
rainbyte: mmm, the guys from Tungsten added more info
rainbyte: some time ago it wasn't so clear