March 2009 - Wine-Devel - list.winehq.org

[RFC] Port of Stefan Dösinger's ARB_vertex_program fixed-function vertex pipeline replacement to 1.1.18

by Paul TBBle Hampson

Hi. I've rebased the arb_vertex_program ffp vertex pipeline patchset to 1.1.18. This time I managed to get the fog correct, and all the d3d9 tests pass. I also did some benchmarks this time in both 3DMark 2000 and 2001SE, and have attached the results. Generally there's a fairly large slowdown in the fixed-function code, particularly in 3DMark 2000. Some of 2001SE's tests appear unaffected, which isn't surprising since some of them are D3D8 shader-based tests, not FFP tests. The fillrate tests appeared unaffected too. This is on a Core 2 Duo machine with an nVidia 8600M GT, if it makes a difference. I wasn't watching too carefully, but I did't notice any visual artefacts in the tests. As I understand it, Stefan's not got the time or inclination to work on this at the moment, and my knowledge of ARB vertex programs and the D3D fixed-function pipeline is rather limited, so in all likelihood getting this going faster will require someone to get stuck into gen_arbvp_ffp_shader and its callees in arb_program_shader.c and get it feature-complete and sufficiently optimised to be on-par with the ffp-based vertex pipeline. I guess a GLSL-based vertex pipeline might be desired too...? Then people can add features such as vertex-blending, and get No One Lives Forever 2 and bug #6955 cleared up. As before, the code is entirely Stefans, but bugs may certainly have been introduced by me. Since it now passes the unit tests, it might be reasonable to actually consider this for mainline, with a registry key or env var to force a specific choice of fixed-function vertex pipeline. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

March 29, 2009

Re: GSoC 2009

by Ben Klein

2009/3/29 Tim Felgentreff <timfelgentreff(a)gmail.com>: > > Owen Rudge wrote: >> If you have had exposure to Microsoft source code, then I believe I'm >> right in saying that you are not able to work on Wine, I'm afraid. > I have written to the Software Freedom Law Center about this, but the License > included with the Windows Research Kernel is actually pretty permissive (even > allowing me to copy a small number of lines of code, actually. Which I wasn't > going to do anyway though). It's not just about licensing, it's also about keeping Wine Wine. We don't really want people to say "this is how it's done in Windows, I've seen the source!", we want *proper* tests backing up patches and new implementations. At least, that's my interpretation of the SoC rules :)

March 29, 2009

Re: 16bit code generation

by Hin-Tak Leung

--- On Sat, 28/3/09, Austin English <austinenglish(a)gmail.com> wrote: > > I don't know how well native linux openwatcom works as > a cross-compiler, however, but that probably doesn't matter > for this discussion? > > Quite the opposite, that's exactly what we WANT to use. Given that 1) win32 openwatcom works, 2) presumably it works correctly under wine (or relatively easy to check that if it isn't), then any difference in behavior/code-generation between win32 openwatcom under wine and native linux openwatcom working as a cross-compiler is either a bug or inconsequential, then it should be relatively straight forward to check? It is not a trivial amount of work - compiling a bunch of random code under win32 openwatcom and cross-compiling and compare, and account for any difference if there is any - but would work well as a 3-month GSoC project?

March 28, 2009

Re: 16bit code generation

by Austin English

On Sat, Mar 28, 2009 at 5:15 PM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: > > --- On Sat, 28/3/09, Austin English <austinenglish(a)gmail.com> wrote: > >> It's also not known how well it works under Linux. There >> was talk >> about detecting if a user has it installed, then compiling >> 16 bit code >> in that case, but no one's worked to see if OpenWatcom >> works when >> ran/installed natively. > > But win32 openwatcom works under wine's cmd. :-). Right, but A) AJ doesn't want that and B) that doesn't allow us to (selectively) build the win16 tests the same time as the rest of the test suite. > I don't know how well native linux openwatcom works as a cross-compiler, however, but that probably doesn't matter for this discussion? Quite the opposite, that's exactly what we WANT to use. -- -Austin

March 28, 2009

Re: 16bit code generation

by Hin-Tak Leung

--- On Sat, 28/3/09, Austin English <austinenglish(a)gmail.com> wrote: > It's also not known how well it works under Linux. There > was talk > about detecting if a user has it installed, then compiling > 16 bit code > in that case, but no one's worked to see if OpenWatcom > works when > ran/installed natively. But win32 openwatcom works under wine's cmd. :-). I don't know how well native linux openwatcom works as a cross-compiler, however, but that probably doesn't matter for this discussion?

March 28, 2009

Re: GSoC 2009

by Tim Felgentreff

Owen Rudge wrote: > If you have had exposure to Microsoft source code, then I believe I'm > right in saying that you are not able to work on Wine, I'm afraid. I have written to the Software Freedom Law Center about this, but the License included with the Windows Research Kernel is actually pretty permissive (even allowing me to copy a small number of lines of code, actually. Which I wasn't going to do anyway though). > I worked on the control panel last year, and was in the process of > converting some winecfg pages to separate applets - indeed, there's some > outstanding work in my git repository that needs finishing/merging (but > I have had a lack of time to work on this year, sadly.) Assuming you > aren't barred from contributing for the aforementioned legal reasons, > then there is lots more work that can be done on improving Wine > configuration and so on if you're interested in that. Theming and the > test suite are also areas which could do with work though, and you may > be able to make a more substantial project out of those areas. Thanks, then I will have a closer look at the test suite and at the themeing stuff and maybe apply for a project in one of these areas. Regards, -Tim

March 28, 2009

Re: [3/4]winemaker: add workspace-parse function

by Francois Gouget

This one is wrapped also (which is only logical). There are two other problems: * there's the same case sensitivity issue as in the project parsing code. Using search_from() in the same way should fix it. * also it assumes that the project file is in the current directory. In other words, the following does not work: winemaker Chap03/HelloWin/HelloWin.dsw -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

March 28, 2009

Re: [2/4]winemaker: add project-parse function

by Francois Gouget

This one is wrapped too. But the main problem is that it does not handle case fixes. This can be fixed by applying the attached patch on top of it. With this, if you go test with the Programming Windows 98 samples, the following scenario works: cd Chap03/HelloWin winemaker HelloWin.dsp -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

March 28, 2009

Re: GSoC 2009

by Owen Rudge

Hi Tim, > I'd like to help out with wine during the summer of code. I have never done > any dll development apart from a little messing with the windows research > kernel, so I'd rather work on something else. If you have had exposure to Microsoft source code, then I believe I'm right in saying that you are not able to work on Wine, I'm afraid. (I seem to recall reading somewhere that it might be OK for you to work on, say, client apps if you've only seen kernel code, but I might be wrong - somebody else will no doubt know better.) > I would love to work on control panel applets or the wine config tool as in the > project ideas, however, theming and the test suite would be two other things > I'd be interested in. It would be great if you could give me some pointers as > to where my help would be appreciated most so I dig a little deeper into that > for a couple of days before I write my proposal. I worked on the control panel last year, and was in the process of converting some winecfg pages to separate applets - indeed, there's some outstanding work in my git repository that needs finishing/merging (but I have had a lack of time to work on this year, sadly.) Assuming you aren't barred from contributing for the aforementioned legal reasons, then there is lots more work that can be done on improving Wine configuration and so on if you're interested in that. Theming and the test suite are also areas which could do with work though, and you may be able to make a more substantial project out of those areas. Cheers, -- Owen Rudge http://www.owenrudge.net/

March 28, 2009

GSoC 2009

by Tim Felgentreff

Hi, I'm currently an IT student in Germany in my 2nd year. I'd like to help out with wine during the summer of code. I have never done any dll development apart from a little messing with the windows research kernel, so I'd rather work on something else. I would love to work on control panel applets or the wine config tool as in the project ideas, however, theming and the test suite would be two other things I'd be interested in. It would be great if you could give me some pointers as to where my help would be appreciated most so I dig a little deeper into that for a couple of days before I write my proposal. Regards, Tim

March 28, 2009