Hi guys, I'm wondering what the DRI project's view is on reverse engineering drivers. Is this acceptable or even common practice? Even if other DRI developers may have signed NDA's with the same company? I've been reading the documentation about relationships with companies, but I haven't been able to find anything about this --- GrifGone is now known as Griffon26 To give a more concrete example, would it be acceptable to reverse engineer ATi's drivers to get the pixel shaders and HyperZ working in the DRI driver? --> sshack (~sshack@S0106000f66368f75.gv.shawcable.net) has joined #dri-devel Morning. --> mmu_man (revol@lyon-2-62-147-20-26.dial.proxad.net) has joined #dri-devel <-- _everslick has quit (Read error: 54 (Connection reset by peer)) --- idr_ is now known as idr Griffon26: My *personal* opinion (i.e., not the general DRI developer opinion or IBM's opinion) is that it depends. Griffon26: If by "reverse engineer" you mean disassemble their drivers, I'd say, "Hell no!" --> _everslick (~clemens@L1205P25.dipool.highway.telekom.at) has joined #dri-devel idr: so what options, if any, do you think there are to get those features into the open source drivers? Griffon26: Not sure. Griffon26: Afterall, there's a reason the features aren't already supported. :) idr: yeah, I was wondering about that ;) Griffon26: The "best" way is for developers to go through ATI's "process" to get the existing dev kit and just keep asking for HyperZ & shader info. Griffon26: I don't know if any of the ppl already in the dev program have asked about that in the last 6 month or so. but seriously, you'd say "hell no" to reverse engineering. Is that because it would damage relations with ATi or because of the DMCA or something like that. I still have some reading to do in that last area. you see, if reverse engineering were an option, the person who was going to do it would have to stay away from NDA's on the same hardware Griffon26: There are enough legal problems surrounding disassembling people's code that I'd like to see us avoid it. ok, that makes sense Griffon26: The dmca doesn't apply in Canada. I'm from .nl, but still I think you could sanely do what compaq did with the original ibm bios. one person reverse engineers, another person writes code. Griffon26: Where abouts? My wife's family is from Haarlem. idr: I now live in Eindhoven Griffon26: Cool. I seem to recall passing through there on the train. :) =] better hope that wasn't the train from the airport to Haarlem ;) oh. eh. Guess I should introduce myself. Griffon26: No. We were coming from Aachen (Germany). * sshack puts on his nametag. idr: Ah, quite possible then, yes Hi, I'm steve and i'm looking for some low hanging fruit to hack on in the r200 driver. sshack: There is some, that's for sure. sshack: Hang on... idr: You've got cubemaps almost working, right? sshack: Yeah, that's (finally) done. oh. When did you finish it? sshack: EXT_blend_func_separate and EXT_blend_equation_separate should be pretty easy. sshack: They may require some additions to the kernel module, though. whee. sshack: There's also point sizes (!= 1.0). That's a little less low hanging, though. Alright. I'm still learning the codebase. sshack: Okay. The blend extensions should be the lowest hanging, then. So i'm guessing ati doesn't want to give out hyperz or vertex/fragment shader docs? right sshack: They haven't previously. Like trying to get blood from a stone. sshack: Most of the documentation needed for ATI_fragment_program is in the r200_reg.h and ATI_fragment_program spec. There's just a tiny bit missing. :( Oh goodie. Is the i830 source a good reference for how to implement EXT_blend_func_separate? sshack: I think the existing code in the R200 driver should provide a good basis. Okay. sshack: Basically, there are two registers, R200_RB3D_ABLENDCNTL and R200_RB3D_CBLENDCNTL, that need to be programmed instead of R200_BLENDCNTL. sshack: Right now R200_BLENDCNTL gets the value that would go to R200_RB3D_CBLENDCNTL. I can't even find R200_BLENDCNTL in the r200 directory sshack: grep for CTX_RB3D_BLENDCNTL. found. sshack: You might want to post a message to dri-devel (or ask here during the meeting in 2 hours) about what needs to be done to the drm. I'll do that. So essentially this is search and replace and then muddle with some stuff in drm? sshack: Not exactly. idr: would the meeting also be a good place to ask about people's feelings about reverse engineering? Griffon26: Yeah. ok idr: Alright. I haven't done any hw drivers in 2 years, and that was scsi stuff. sshack: My guess is that a new state atom will need to be added for the blend state (like the hw.ctx atom). Okay. sshack: Actually... * idr thinks about it for a second. I probably want to know way more about the hardware than I currently do. idr: do you have an idea how hard it would be to port the texcoord3f part of your patch to the r100 (to get 3D textures) ? marcheu: It should be fairly straightforward. (everyone is asking the oracle, it seems, so why not me) marcheu: I think it will take more than that to get 3d textures or cubemaps working on r100. I seem to recall that there are some registers specs missing. :( --> _MacGyver_ (~MacGyver@port-212-202-171-163.dynamic.qsc.de) has joined #dri-devel idr: I ported the part that was already in r200, it seems to compile fine idr: I'm talking about the part toggled by ENABLE_HW_3D_TEXTURE idr: btw, I don't think r100 has cubemaps, that's why I'm thinking about splitting things marcheu: I sure thought it did anholt: em, did what ? r100 having cubemaps anholt: if you say so, I'll try to let it in and see marcheu: No, it can do cubemaps. Look at http://www.delphi3d.net/hardware/viewreport.php?report=336 nice ! that means I cant do a straight port with minimal work :) marcheu: I had it mostly working at one point, but I couldn't quite get it. marcheu: My patch should still be in the dri-devel archive on marc. idr: no problem, I'm subscribed to the list marcheu: It was some months ago when I did it. idr: (doubt), what patch ? ok, I'll google for it idr: what was it specifically ? it was a patch for cubemaps on r100 ? marcheu: http://marc.theaimsgroup.com/?l=dri-devel&m=104508787614041&w=2 How many hw lights does the r200 series do? idr: thanks, I'll look at this marcheu: It's from Feb 2003, so the patch probably won't apply. <-- jg has quit ("bye bye...") activity! I'm going to go get some lunch, but I'll be back for the meeting. --> idr_ (~idr@bi01p1.co.us.ibm.com) has joined #dri-devel <-- idr has quit (Read error: 104 (Connection reset by peer)) <-- _MacGyver_ has quit ("Leaving") What time is the meeting here? 2PST? I think 2300 CET that would be in 1 our and about 20 minutes... idr_ said this: "or ask here during the meeting in 2 hours" when it was 20:58 CET Right, so about 2PST then :-) <-- mmu_man has quit ("Vision[0.9.6-0203]: i've been blurred!") <-- sunny has quit ("pop") --> sunny (sunny@sunny.cloaked) has joined #dri-devel --> willmore (~willmore@ool-4354a17a.dyn.optonline.net) has joined #dri-devel --> pinchartl (~pinchartl@lmepool1.ugr.be) has joined #dri-devel hi Oh, crud, we're back to DST. The one time I'm ontime and I'm early.... hehe --> anholt_ (~anholt@c-24-21-18-195.client.comcast.net) has joined #dri-devel --- ChanServ gives voice to anholt_ anybody got a spare ati x800 xt lying around I can use? Wanna start fiddling with DRI, but I have a GeForce =] hah, like a card that costs 500$ can be considered spare <-- anholt has quit (Read error: 104 (Connection reset by peer)) hehe --> hfb (~hfb@lsanca1-ar2-4-60-000-117.lsanca1.dsl-verizon.net) has joined #dri-devel seriously there's cheaper cards with quite good capabilities that would be better to start with I wanna buy it, but I can't. The shops don't have it yet. Not to mention you can't even buy it yet. well, I don't buy it just for DRI, also for games 3dlabs, voodoo5, r2xx... Griffon26: Get r300 working first. I postponed buying a good vidcard when I bought my comp Then i'll buy you an x800 :-) granted if you're a gamer you'd ignore everything i just said except r200 hehe <-- hfb (~hfb@lsanca1-ar2-4-60-000-117.lsanca1.dsl-verizon.net) has left #dri-devel ("Client exiting") and yeah, no point in working on an r400 when we can't even do the r300 yet and can't even do vertex shaders or hyperz on r200 but it would be a shame to have to buy an r200 or r300 first... maybe I can pick up an old card somewhere 9200se's are $74 CAD. They'll be giving them away in cracker jack boxes in a month or so. yeah, if you don't aim for the 256M version the 9200 is dirt cheap --> sroland (~sroland@217-162-12-183.dclient.hispeed.ch) has joined #dri-devel --- idr_ is now known as idr You can get 128MB 8500 cards on eBay for ~$50. --> idr_ (~idr@bi01p1.nc.us.ibm.com) has joined #dri-devel * idr_ wonders why he keeps getting disconnected... --> idr__ (~idr@bi01p1.co.us.ibm.com) has joined #dri-devel <-- idr has quit (Read error: 54 (Connection reset by peer)) I'm not into all of this stuff yet, but how much knowledge of one chip can you reuse for the next if you compare r200 and r300 for instance? WTF? Griffon26: The chip knowledge is somewhat useful. What's more useful is knowledge of the driver architecture. of the open source driver you mean Griffon26: Of course. :) --- idr__ is now known as id5r --- id5r is now known as idr I was wondering if I were to buy another card to get started, if it would be more useful to take an r300 than an r200 definitely. if you'd like to start on a card that's probably easier than r[34]00 i can recommend a couple... Griffon26: Well, there's no driver or documentation AT ALL for the R300, so it will have a pretty steep "getting started" curve. ah, ic --> nh (prefect@pD9EBEA5A.dip.t-dialin.net) has joined #dri-devel I get the feeling that the discussions about the the next generation graphic API make people who would like to help the DRI project wait until those issues are resolved. I've seen lots of posts on the dri-devel mailing list, with many interesting points, but there hasn't been any roadmap yet. does anyone have an idea of the schedule ? sadly that's not a valid conclusion to make pinchartl: I don't think things are far enough along for there to be a schedule yet. there's plenty of work that can be done independently of knowing what the final product will look like * idr agrees. Seems like the best idea would be to get a card with an R200 to first get to know the existing driver and then to continue with the undocumented parts of the R200 (I assume this card does have HyperZ for instance?) in fact most of the "final product" work is a matter of what code belongs where, rather than what the code actually _does_ ajax: I know about that, but I'm not sure everybody is aware. a major change in the graphic API looks like something that will break everything Griffon26: All of the Radeons have some form of HyperZ. ajax: right. it's probably more a matter of where to split code and put new API, right ? <-- idr_ has quit (Read error: 60 (Operation timed out)) Ok, sounds like a plan. Thanks all for helping me form a clearer picture of how to get started. Griffon26: No problem. btw, I plan to by an AMD64. are there still issues with that platform ? ooh! yes! fix the bugs, you'll be a hero hehe how usable is it ? does 2D work properly ? i know of people using 2D on it so it can't be that buggy 3D still has some issues though afaik ok which card should I get ? pinchartl: A lot of the problems are related to 32-bit / 64-bit issues in the kernel interface. and of course there are no r300 or nvidia drivers for amd64 yet, so stick with the 9200 or below if you want to work on DRI unless you're completely insane and want to hack on r300 ;) ajax: Nvidia has drivers, but they're not very well tuned for that platform yet. hacking on r300 on an AMD64 is insane :-) I'll try to get an r200 idr: i stand corrected then. i knew ati didn't do amd64 yet. hmm.. what range of cards is that what about r250 ? pinchartl: see the ATIRadeon page on the wiki, it covers what cards have what chips but basically, the 9200 is the rv280, which is the highest r200-series chip, and we only support through thr r200 series 9500-9800 are r300 or r350 ajax: the wiki states that the rv250 is a heavily modified r200, so I didn't know if it was supported heh. there's a reason i was suggesting the 9200 ;) pinchartl: AFAIK, it is programatically identical the the R200. The hardware changes just reduce the performance. ok reduce? nm me Griffon26: You're right...SIGNIFICANTLY reduce. :( They basically took out half the rendering pipelines AND reduced the clock. yeah. actually the model numbers (as opposed to chip numbers) are a pretty good indicator of relative speed you overestimate my knowledge of radeon cards, but thanx anyway =] rv250 == radeon 9000, so slower than a 9100 or 9200 ajax: That's not true. The 8500 (non LE verion) is by far the best performer of the whole R200 family. The 9000, 9100 (which is just a renamed 8500LE), 9200 all perform worse. really? hrm. ajax: Actually, the FireGL 8800 performs slightly better than the non-LE 8500. someone should note that on ye olde wiki then what are the main differences between the Radeon and FireGL ? pinchartl: IIRC the 8800 is has a slightly higher core & memory clock (25MHz higher, I think). The main difference was different opitizations in ATI's drivers. and here i thought they doubled the pipelines or something ajax: Nope. Both Nvidia and ATI do that. They make versions of their cards with drivers tweaked for CAD performance and sell them for 2x or 3x. Nvidia calls them Quadro and ATI calls them FireGL. hehe I always thought the main difference was the price cute. <-- idr has quit (Read error: 54 (Connection reset by peer)) --> idr (~idr@32.97.110.142) has joined #dri-devel <-- nh has quit (Remote closed the connection) right, so. 4pm CDT. here's my question. is anybody opposed to moving the bug tracker from sourceforge to fdo's bugzilla? i _really_ dislike sf's bug system compared to bugzilla ajax: The SF system is pretty bad. i wonder if i should ask this on the list instead or if i should just assume lazy consensus and bug a sitewrangler ajax: Probably. I doubt there will be much opposition. --> agd5f (~agd5f@dsl093-100-212.wdc2.dsl.speakeasy.net) has joined #dri-devel Ok, here it goes. I haven't started on DRI yet, but I plan to and I was wondering what the feeling of the developers is wrt reverse engineering binary drivers. Maybe it is not desirable because it could harm relations with the companies producing the drivers, maybe there are legal problems (e.g. DMCA), maybe there are other things I haven't thought of. Griffon26: there's plenty of work to be done without the need to reverse engineer the binary drivers. your time would be better spent fixing bugs and getting document things to work the list has been asked ok, I understand, but I'm still interested to know if rev eng is a no no or if it is acceptable with certain restrictions depends what you mean by reverse engineering --> fxkuehl (felix@dialin-212-144-006-177.arcor-ip.net) has joined #dri-devel if you mean "hrm, what does this register do when i write to it", then there's not really an issue at all I mean using a binary driver, feeding inputs, watching outputs fair use pretty well covers the poke-and-hope approach (in my highly not-a-lawyer opinion) to find out the relation between 'high-level' interfaces and registers Griffon26: I think as long as you're not disassembling their driver it should be fine. idr: so disassembling _would_ be a problem? if on the other hand you mean disassembling the driver, then the EULA probably strictly prohibits that and we should honor that --> sshack_ (~sshack@S0106000f66368f75.gv.shawcable.net) has joined #dri-devel disassembling a graphic driver is in my opinion too difficult to even be considered. I spend months disassembling binaries to try to get wine to run safedisc protected games, and it wasn't pleasant to do. Griffon26: I have read about folks getting into hot water for doing that. read the EULA on the driver you're thinking about disassing alright if it says "you may not reverse engineer this" - and it probably does - then don't not sure about the legal aspects, but it's not worth it anyway Here's a question, and I don't know the answer. Is it "okay" to instrument the kernel portion of the driver for r-e purposes? It's distributed as source, afterall. idr: what do you mean by instrument ? idr: pretty sure that'd be clean, unless the source license prohibits it... pinchartl: Like, have it dump all of the data the *_dri.so portion sends it. but i doubt the source license _could_ prohibit it without tainting (at least in the linux case) Okay backlog read. idr: are you talking about the ATI or NVidia binary drivers ? pinchartl: ATI, but the kernel part of Nvidia's drivers are also (by necessity) distributed as source. --> bronaugh (~bronaugh@S0106525405f26ac3.wk.shawcable.net) has joined #dri-devel idr: no it's not. it's distributed as a binary with a thin source glue --> andreas_s (~andreas_s@pD902E096.dip0.t-ipconnect.de) has joined #dri-devel pinchartl: Which? How'd they pull that off? idr: where's the problem . ? pinchartl: The problem is versioned kernel symbols. again i think you'd have to read the license. xgi's drm module, for example, appears to be mit-licensed idr: Glue library iirc idr: for each kernel symbol they need, they have a function provided as source that gives them the symbol. the rest is binary pinchartl: Oh brother. idr: I assume that ATI did the same ati's module doesn't taint the kernel, iirc, so it's either GPL-compatible - in which case modification is okay - or they're lying about the license ok nvidia's module _does_ taint, which means you'd need to check the source license very carefully I've read about a binary module exporting a license string of the form "GPL\0 is not the license this module is released under." or something like that to avoid tainting the kernel ajax: Since we have no Nvidia docs, I'm not sure how much good it would do anyway. ahh. ati.com. I remember when that was something /entirely/ different. that wasn't ATi, was it? ajax: With ATI, we know most of the stuff. We could look at what's sent into the kernel and pick out the stuff we don't understand. * ajax checks the docs on the fglrx module... hmm.. have I jumped into an r300 discussion? or hyper-z? idr: that's what I meant =] pinchartl: That is evil! ajax: ati's module does taint the kernel idr: yes it is --> nh (prefect@pD9EBEA5A.dip.t-dialin.net) has joined #dri-devel it was even more funny IIRC, something like "GPL\0 except for some files" ;) jor: in that case i need to check the license anyway ;) pinchartl: Not only is it evil, I'm not sure it's legal! marcheu: except files in the "GPL" directory, iirc :) marcheu: which contained no files. "incidentally" marcheu: "GPL\0 Except for the bits that matter". idr: I doubt it's legal either. hah. ati.com just made firefox die. great. idr: there was noise on kerneltrap.org about it, iirc. got it, just a sec, I'll have a link bronaugh: Not surprising. :) <-- sshack has quit (Read error: 110 (Connection timed out)) http://marc.theaimsgroup.com/?l=linux-kernel&m=108300930000222&w=2 Anyone know how to unpack an rpm? sshack_: trying to check the EULA? =] sshack_: it's a cpio archive. sshack_: Try using rpm2cpio. also, I seem to remember that the "open" layer of nvidia kernel module is os-independent rpm2cpio | cpio -i --make-directories oh right, that's because ati.com sends rpms with broken mimetypes ajax: x-pn-realaudio? :) bronaugh: oh man. I'm afraid ATI's driver taints the kernel. I just checked the sources, and they wrap a binary module in a thin source code bronaugh: yep. clueless. hehe MODULE_LICENSE("Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY"); nice of them to be honest. Right. the ati stuff definately taints. sure, but it's the license that matters, not just the taint status I really don't understand why video card vendors think they're so special. sshack_: They must have learned it from the movie industry. :) sshack_: they pretend not to be allowed to release sources because of 3rd party IP issues, but I don't believe them pinchartl: Neither do I. here we go then: b) the recipient is not entitled to discover through reverse engineering or reverse compiling or other such techniques or processes the trade secrets contained therein or in the documentation. That's what all the hw vendors used to claim. Now you see everyone except video cards having open source drivers. oh and broadcom. Who tries the exact same trick. bummer ajax: Yeah. ajax: how do they define trade secrets ? ajax: where do those kinds of clauses hold up? in what countries? Can we just bother them at conventions? where "therein" is the whole fglrx package ajax: in what countries do those laws contradict "fair use" type laws? bronaugh: technically that contradicts fair use in america pinchartl: Point. In canada we can reverse engineer to make a compatible product. depending on which lawyer you believe... but then there's this wonderful DMCA thing... so we could legally reverse engineer in order to make a compatible driver. sshack_: Keep in mind that all the video card makers that have Linux drivers share a lot of code with their Windows drivers. I'm sure that MS has some sort of evil licensing to make it painful for them. nuh-uh. DMCA says RE is allowed for interop purposes ajax: it's amazing how money allows people to contradict fair use in the US :-) idr: Perhaps. and what if someone is allowed to reverse engineer it in his country, can everyone then use it everywhere without problems? ajax: but I'm sure it's just grey enough so that you can get SLAPP'd Griffon26: Yes. and _must_ you have accepted the license in order to get to the binaries in a legal way? unfortunately the EUCD (european DMCA) is well on its way in Europe. and software patents too :-( Griffon26: yes section 1201(f) of the DMCA is where you want to look Has anyone tried just asking? what if someone installs the drivers on his computer and then lends his computer to somebody else who reveng-s the drivers? Or am I going too far here? =] sshack_: of course. that's step 0. How did tungsten get their docs? could they get the rest if they asked? griffon26: what you're looking for is clean-room reverse engineering. btw, the binary module of the ATI's driver is only 200kB, which is not that big compared to the NVidia drivers. it would be possible to get some knowledge by reverse engineering griffon26: essentially, what's done with that is that you reverse engineer it, and produce a specification of how the chip works -- but no code. then another person implements using that spec. This is what compaq did. it's how Phoenix originally made a workalike of the IBM BIOS. compaq or phoenix? bronaugh: yeah, but the license forbids the rev engineer to get the drivers himself 1201(f) says that, if you legally obtained a copy of the software, then you may RE for interop purposes. I can't remember. so, what defines legally? i just snagged the fglrx drivers from ati.com, going through their web page Griffon26: Essentially, we're laundering the information. i don't recall seeing any license agreements in the process ajax: That's legal. Griffon26: the license might not be valid under 1201(f), and under national laws in many countries ajax: Legal would be defined as the common and expected method of gaining access to foo pinchartl: exactly. I'm actually rather peeved at ATI. of course, consult your lawyer first. they're being very chintsy with their specs. So what happens when we try talking with ati? --> mmu_man (revol@lyon-1-62-147-18-174.dial.proxad.net) has joined #dri-devel to my knowledge, people _are_ talking with ati wait and/or see, in that case When I tried contacting them they treaded me like some little developer snot and told me to go away. ajax: Who? and what's the progress? show of hands... who's talking with them? ;) I talked with them. No longer though. sshack_: wish i could tell you. not that i'm under NDA or anything but that i simply do not know. "do not know who". What I have heard in the past is that, because they've gotten so many queries, they only talk to "proven" developers. and I don't think I ever got high up enough in the chain to talk with anyone who had any idea/authority about specs. idr: Sounds fair. We had a project that ati would have loved to use as pr. idr: yes, that's been my experience too. At least they're better than nvidia. mmm... the copyright notice in firegl_public.[ch] doesn't seem to cover the other files. idr: Okay, so Why doesn't tungsten graphics have all the docs needed? --> hfb (~hfb@lsanca1-ar2-4-60-000-117.lsanca1.dsl-verizon.net) has joined #dri-devel sshack_: Probably because nobody is paying TG to work on the R200 driver anymore. :) They gotta pay their bills, afterall. sshack_: they might. realize that not everything TG does necessarily goes into DRI Right. I know. plus the stuff ati released is not complete for every whizbang feature mmm... the firegl driver seem to have been written by a division of SONICblue Inc. just enough to get by maybe not for linux <-- hfb (~hfb@lsanca1-ar2-4-60-000-117.lsanca1.dsl-verizon.net) has left #dri-devel ("Client exiting") agd5f: Yeah, I figured that. pinchartl: Yeah, I noticed that. Doesn't sonicblue do mp3 players? sonicblue used to be S3 ahh. sshack_: now it does. not sure about before sshack_: They also made the ReplayTV. I wonder if that has an ATI chip in it. I know it runs Linux... agd5f: I forgot all about that. when S3 fell apart different parts ended up in different places doing different things any bits end up at ati? like the texture compression patents maybe? =] probably not <-- andreas_s (~andreas_s@pD902E096.dip0.t-ipconnect.de) has left #dri-devel ("Client Exiting") Speaking of texture compression, has anyone heard anything (other than marketing rubbish) about ATI's 3Dc? first i've even heard of it Griffon26: A friend of mine is an IP lawyer and I asked him about it. I posted a note to dri devel or mesa a few months back. ajax: http://mirror.ati.com/products/radeonx800/3DcWhitePaper.pdf Okay, besides legal bs. What are the blockades to getting radeon docs? agd5f: I'm not subscribed to any list yet. I'll check the archives if you have something a little more specific I can search for. Griffon26: http://marc.theaimsgroup.com/?l=dri-devel&m=107704096508208&w=2 thx he was of the opinion that as long as the hardware was doing the processing and not the code, we'd be ok since the patent was related to process not data structures or protocol agd5f: Useful. He also found the law firm handling the patent and gave me their contact info hm. I just had a look at the firegl binary module. If further investigation confirms that reverse engineering would be legal, I would be happy to help by reverse engineering selected parts of the driver But more importantly he gave you a very simple guideline to follow. Don't do exactly what they're doing in their patents. Easy enough. pinchartl: I suppose we'd have to investigate for our countries idr: 3dc looks pretty straightforward algorithmically Griffon26: obviously I htink we can advertise s3tc as long as the driver just passes on to HW ajax: Yeah. ajax: I'm anxious to find out 1) Are there any patents that prevent open-source implementations? 2) How is the functionality exposed to applications in OpenGL? only sucky part is that it looks like they expect you to use the shader engine to unpack the normal vector, which means we're stuck behind r300 problem #1 hmm... a bit of searching at the USPTO should do. bronaugh: good luck. searching patents is almost impossible bronaugh: *Maybe*. If there are patents, they may still be pending. you really have to know what you want before hand ajax: Yeah. I don't think it's supported on anything except the R420. However, it would still be interesting to implement for sw Mesa. guess one could simply contact ATi, ask them if there are patents (pending or otherwise) on 3Dc idr: good point, mesa should be able to accept 3dc textures. bronaugh: And if they don't respond (which most companies *won't* to such questions)? start making a squawk it looks like they have a GL extension for it, let's see if i can find it documented anywhere better yet, start a small project that implements 3Dc, inform ATi of it, and see what happens. sacrificial goat, if you will. bronaugh: Silence does not equal approval. Look at the JPEG patent fiasco. How long has JPEG been in use? 12 years? This is why I hate the computer industry. Even used care sales are more honest than this. sshack_: No, that's why you should hate the legal industry. :) or software patents idr: No. Because it's the people who run the industry who _hire_ these lawyers. sshack_: But it's the legal industry that made all the rules that make this mess possible. idr: now there's a JPEG patent fiasco? shit.