On Thu, Dec 13, 2012 at 10:59 AM, Stéphane Marchesin <stephane.marche...@gmail.com> wrote: > On Wed, Dec 12, 2012 at 3:49 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> This is interesting, personally I'm fine with getting this merged. >> That said, there was a i965g driver upstream before (though it never >> worked right IIRC and was probably gen4 or maybe gen5 too only due to >> its age), the problem is unless you manage to get the intel guys >> interested you'll always end up with something which just isn't very >> useful to most people, as you will always lag behind the non-gallium >> driver in features, performance and conformance (with the primary >> benefit of supporting other state trackers but most folks are just happy >> with GL variants). > > Well, if you focus on one family, you can actually do something > useful. For example i915g gives me GL 2.1 on pineview and has much > higher vertex performance than the classic driver. The maintenance on > it is also extremely low. So long-term, I think a i965g driver is a > good thing to have in the tree for that reason. You could even rename > it "snbg" or something, to point out that it's gen6 only. I plan to support other GENs (depending on which of them I own or have access to). But it may be a good idea to rename it if i965g is confusing.
The name of the DRI module could not be changed though. > Stéphane > > >> But if there's no interest we can always nuke it (again) in the future I >> suppose. >> btw is there a specific reason why it's gen6+ only? I'm just curious as >> I thought that despite some differences they still could share quite >> some code. >> >> Roland >> >> Am 12.12.2012 23:41, schrieb Chia-I Wu: >>> Hi list, >>> >>> I've been working on i965g, a new pipe driver for Intel GEN6 (and >>> later), for a while now. I would like to know if there is any >>> interest in it and if it can be merged upstream. The code is >>> currently available here >>> >>> https://github.com/olvaffe/mesa/tree/i965g >>> >>> The project was started for my own fun and for self-learning. It was >>> later sponsored by LunarG. While it is still new, it does work for >>> many of mesa-demos. Right now it passes 6884 of 7547 piglit >>> quick-driver.tests. I also tried it with gnome-shell, OpenArena, and >>> Nexuiz, and they all seem to work. >>> >>> The driver is written from scratch. However, it follows classic i965 >>> driver for many of the design decisions. It comes with its own toy >>> compiler to translate TGSI tokens to GEN instructions. The compiler >>> still lacks several functions (register spilling and most TGSI >>> indirections), but more importantly, almost no optimization is >>> performed. It thus generates much worse code comparing to that >>> generated by classic i965. >>> >>> I rebased the code tonight and cleaned up the history. The branch now >>> has 24 new commits on top of master >>> >>> winsys/intel: new winsys for intel >>> i965g: new pipe driver for Intel GEN6+ >>> i965g: add debug flags settable through I965_DEBUG >>> i965g: hook up pipe_screen param and fence functions >>> i965g: add functions to translate pipe enums to HW enums >>> i965g: hook up pipe screen format functions >>> i965g: hook up pipe screen resource functions >>> i965g: add command parser >>> i965g: hook up pipe context flush function >>> i965g: add functions to manage shaders >>> i965g: hook up pipe context state functions >>> i965g: hook up pipe context blit functions >>> i965g: hook up pipe context transfer functions >>> i965g: hook up pipe context query functions >>> i965g: add GEN6 GPE >>> i965g: add GEN6 3D context >>> i965g: hook up pipe context 3D functions >>> i965g: add support for timer/occlusion/primitive queries >>> i965g: hook up pipe context video functions >>> i965g: hook up pipe context GPGPU functions >>> i965g: add a toy shader compiler >>> i965g: compile VS and FS with the toy compiler >>> i965g: support the new driver in various targets >>> i965g: add to --with-gallium-drivers >>> >>> It is quite self-contained. If preferred, I can send the patches to the >>> list. >>> >>> Oh, and my account on fdo is disabled because of my own mistake[1]. I >>> contacted some of the developers in the thread but did not get any >>> response. Could anyone help me with that, or how do I have it >>> re-enabled? >>> >>> [1] http://lists.freedesktop.org/archives/mesa-dev/2012-July/023901.html >>> >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev