November 2006 - Wine-devel - list.winehq.org

Re: [Module] winex11.drv A new function.
by Dmitry Timoshkov 27 Nov '06

27 Nov '06

"Anatoly" <vostok(a)etersoft.ru> wrote: > +static struct codepair { > +unsigned short keysym; > + unsigned short ucs; > +} keysymtab[] = { Nothing prevents to make the keysymtab[] a const data. -- Dmitry.

1 0

Re: [winex11.drv/keyboard.c] Fix
by Dmitry Timoshkov 27 Nov '06

27 Nov '06

"Anatoly" <vostok(a)etersoft.ru> wrote: > --- x11drv.h 8 Nov 2006 20:14:19 -0000 1.10 > +++ x11drv.h 24 Nov 2006 09:38:39 -0000 > @@ -19,6 +19,8 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > > +#include <config.h> You can't do that, a comment 2 lines further in that file explains what you need to do instead. -- Dmitry.

1 0

Re: mscoree [1/2]: Add missing stubs to the spec file
by Paul Chitescu 27 Nov '06

27 Nov '06

On Wed, 11 Oct 2006, James Hawkins wrote: > Hi, > > Changelog: > * Add missing stubs to the spec file. > > dlls/mscoree/mscoree.spec | 125 +++++++++++++++++++++++++++++++++++++++++++-- > 1 files changed, 120 insertions(+), 5 deletions(-) Interesting - what mscoree version are those ordinals from? I got mines from XP Home SP2. Paul Chitescu

3 8

Re: msxml3: Implement createProcessingInstruction with a stub PI object.
by Lei Zhang 27 Nov '06

27 Nov '06

domdoc.c:domdoc_createProcessingInstruction() uses xmlNewDocPI() from libxml2. This feature was added in libxml2 version 2.6.15. (released about 2 years ago) Anyone using an older distro with an outdated libxml2 (e.x. RHEL 3) will not be able to compile this code. On 11/16/06, Huw Davies <huw(a)codeweavers.com> wrote: > --- > dlls/msxml3/Makefile.in | 1 > dlls/msxml3/domdoc.c | 19 +- > dlls/msxml3/msxml_private.h | 1 > dlls/msxml3/pi.c | 544 +++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 563 insertions(+), 2 deletions(-) > > > > > >

1 1

Re: [3/8] wined3d: Create a separate function for sampling a texture
by Ivan Gyurdiev 27 Nov '06

27 Nov '06

H. Verbeet wrote: > There are a couple of instructions that have to sample from a texture, > right now most of them duplicate that code, and hardcode the texture > type. > > Changelog: > - Create a separate function for sampling a texture You should continue to use "add_param" or "get_register_name". There should be a single point in the code where register names are constructed, adding another one is a bad idea. This function is specifically tasked with naming registers, and taking into account things like relative addressing, so that when samplers support relative addressing in the future, changing the naming scheme would be trivial.

2 3

Re: [4/8] wined3d: Fix the texm3x3tex instruction to sample properly
by Mirek 27 Nov '06

27 Nov '06

Wow, I am impressed those patches fixed almost all tests in 3DMark 2003, test4 (mother nature), vertex shader and Ragtroll without any regression in other apps. Perfect work! Mirek H. Verbeet napsal(a): > The current code for texm3x3tex doesn't handle projected textures, and > actually uses the wrong argument to determine the sampler type. This > patch fixes the turtle in the 4th game test in 3DMark03. > > Changelog: > - Fix the texm3x3tex instruction to sample properly > > > ------------------------------------------------------------------------ > > --- > > dlls/wined3d/arb_program_shader.c | 6 ++++-- > dlls/wined3d/glsl_shader.c | 23 ++++++----------------- > 2 files changed, 10 insertions(+), 19 deletions(-) > > diff --git a/dlls/wined3d/arb_program_shader.c b/dlls/wined3d/arb_program_shader.c > index 9f2be9b..7c73fd4 100644 > --- a/dlls/wined3d/arb_program_shader.c > +++ b/dlls/wined3d/arb_program_shader.c > @@ -781,13 +781,15 @@ void pshader_hw_texm3x3tex(SHADER_OPCODE > DWORD reg = arg->dst & WINED3DSP_REGNUM_MASK; > SHADER_BUFFER* buffer = arg->buffer; > SHADER_PARSE_STATE* current_state = &This->baseShader.parse_state; > + char dst_str[8]; > char src0_name[50]; > > pshader_gen_input_modifier_line(buffer, arg->src[0], 0, src0_name); > shader_addline(buffer, "DP3 TMP.z, T%u, %s;\n", reg, src0_name); > > - /* Cubemap textures will be more used than 3D ones. */ > - shader_addline(buffer, "TEX T%u, TMP, texture[%u], CUBE;\n", reg, reg); > + /* Sample the texture using the calculated coordinates */ > + sprintf(dst_str, "T%u", reg); > + shader_hw_sample(arg, reg, dst_str, "TMP"); > current_state->current_row = 0; > } > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 6be71bb..39ad693 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -1560,33 +1560,22 @@ void pshader_glsl_texm3x2tex(SHADER_OPCO > } > > /** Process the WINED3DSIO_TEXM3X3TEX instruction in GLSL > - * Perform the 3rd row of a 3x3 matrix multiply, then sample the texture using the calculate coordinates */ > + * Perform the 3rd row of a 3x3 matrix multiply, then sample the texture using the calculated coordinates */ > void pshader_glsl_texm3x3tex(SHADER_OPCODE_ARG* arg) { > - > + char dst_str[8]; > char src0_str[100]; > char src0_name[50]; > char src0_mask[6]; > - char dimensions[5]; > DWORD reg = arg->dst & WINED3DSP_REGNUM_MASK; > - DWORD src0_regnum = arg->src[0] & WINED3DSP_REGNUM_MASK; > - DWORD stype = arg->reg_maps->samplers[src0_regnum] & WINED3DSP_TEXTURETYPE_MASK; > IWineD3DPixelShaderImpl* This = (IWineD3DPixelShaderImpl*) arg->shader; > SHADER_PARSE_STATE* current_state = &This->baseShader.parse_state; > - > - switch (stype) { > - case WINED3DSTT_2D: strcpy(dimensions, "2D"); break; > - case WINED3DSTT_CUBE: strcpy(dimensions, "Cube"); break; > - case WINED3DSTT_VOLUME: strcpy(dimensions, "3D"); break; > - default: > - strcpy(dimensions, ""); > - FIXME("Unrecognized sampler type: %#x\n", stype); > - break; > - } > > shader_glsl_add_param(arg, arg->src[0], arg->src_addr[0], TRUE, src0_name, src0_mask, src0_str); > shader_addline(arg->buffer, "tmp0.z = dot(vec3(T%u), vec3(%s));\n", reg, src0_str); > - shader_addline(arg->buffer, "T%u = texture%s(Psampler%u, tmp0.%s);\n", > - reg, dimensions, reg, (stype == WINED3DSTT_2D) ? "xy" : "xyz"); > + > + /* Sample the texture using the calculated coordinates */ > + sprintf(dst_str, "T%u", reg); > + shader_glsl_sample(arg, reg, dst_str, "tmp0"); > current_state->current_row = 0; > } > > > > ------------------------------------------------------------------------ > >

1 0

WineD3D state management
by Stefan Dösinger 27 Nov '06

27 Nov '06

Hi, In the past days I've been hacking on implementing my state management ideas, and I think I've come to a state where I don't have to be completely ashamed of my patches :-) First, what the code does NOT do yet: * Pixel Shaders, GLSL shaders: I only had my notebook with the M9 available, so I had no chance to implement them. Expect anything from broken graphics to the sudden release of Duke Nukem Forever if you try to use them. * Stateblocks * Register combiners: Disabled right now * Offscreen rendering: Causes random rendering garbage * 2D Blits: Commented out I have described the basic ideas in earlier mails(http://www.winehq.org/pipermail/wine-devel/2006-October/051868.html), so I don't describe them here again. I pretty much followed the original plan. Performance: One of the aims was to get better performance, since we apparently lost performance due to exessive state changes which eat CPU time and may require CPU-GPU syncs. My patches improve performance, but not as much as I originally hoped. I mainly have performance figures on the M9, and some basic testing on a gf7600. * Billboard dx8 sdk demo: got from 56fps to 107 fps :-) * Half-Life 1: Quite an improvement here too. 110->150 fps in one of my timedemos. The d3d renderer now outperforms the opengl renderer(140 fps). Both the billboard demo and hl1 hit a special rendering case(no stream source or fvf changes), this is nicely optimized by my changes. The gl renderer in hl1 uses immediate mode drawing while wined3d can use VBOs and array drawing, thus beeing faster on today's cards. * Battlefield 1942: Slight improvement too, 32->37 fps on my testing scene(spawn point on a u.s. carrier(a)full graphics). BF1942 exceeded the usual linux/windows driver performance ratio already before, so I assume I'm pretty much at the limit of my M9 here. * 3DMark2000: Unfortunately my driver crashes it before showing the scores, so I can only watch the in-test counter. Seems to get +5 to +10 fps in the low detail helicopter test(resolution independent). Native msvcrt.dll gets another +5 fps. I did only a short testing on my geforce7600: * 3dmark2000: gets 11500 3dmarks, with forcing drawStridedFast 14500. This is I believe the windows performance. However, the benchmark is too old to be meaningful. Before my state patches drawStridedFast scroe was around 13500 if I remember correctly, have to retest. * 3dmark2001: Low detail tests run at 150-300 fps, too fast for a meaningful result. high detail tests are slow and partially broken due to offscreen rendering. * Battlefield 1942: Runs at steady 100fps, but it did that already before So it seems that the state patches improve one bottleneck, but we have still many others(offscreen rendering, drawStridedSlow) left. The nvidia profiling driver may help here. Where to go from here: The state management was also planned to make implementing other features easier: * Multithreading: Make the dirty states list per context, and the helpers stored in the device too. Before applying the states activate the correct ctx for the thread. * Stateblocks: Basic idea is to record a display list and call it: glNewList(stateblock->listname, GL_COMPILE); for(i = 1; i <= STATE_HIGHEST; i++) { States[i].func(i, stateblock); } glEndList(); To apply the stateblock: glCallList(stateblock->listname); Ok, we need to split the list to apply only partial states, and the for loop can be improved to create a more efficient list. When the stateblock is altered we have to recreate the list. Thats the basic idea... * Offscreen rendering: Depends on wether we need seperate contexts for pbuffers. If yes, include it with the multithreading ctx finding, then apply the states, otherwise I think we can make selecting the pbuffer/fbo a state like all others. Has interactions with the viewport(I think) and the projection matrix(render_offscreen for upside down rendering) * sRGB textures: Dirtifies the sampler. All textures have now information about how many samplers they are bound to, and the number of one of the samplers. Phil? * Vertex samplers: Ivan said he'd need the state management for them. My idea is to build a d3d sampler - gl sampler mapping in SetTexture, which will be needed for register combiners too. Based on that we can bind vtf samplers in gl. I have no clean patches right now(45 chaotic patches), so I decided to share my wined3d directory. However, this is even compressed a bit big for a mailing list, so I uploaded it to http://stud4.tuwien.ac.at/~e0526822/wined3d-statemgmt.tar.bz2 Stefan

4 9

[wiki] multi language FrontPage
by Karsten Elfenbein 27 Nov '06

27 Nov '06

Hi, could a wiki admin please delete StartSeite on the wiki. According to http://wiki.winehq.org/HelpOnLanguages the wiki would use the english FrontPage if StartSeite doesn't exist. The german FrontPage isn't needed as the users don't get any information about wine there. Karsten

1 0

re: wineshelllink: Use FreeDesktop standard to create Wine menu structure.
by Dan Kegel 27 Nov '06

27 Nov '06

Vitaly wrote: > [xdg-utils] can not handle files with spaces in them. If that's true, it's a bug, and should be fixed. > Also they don't allow installing icons without specifying size. ? http://portland.freedesktop.org/xdg-utils-1.0/xdg-desktop-icon.html doesn't seem to talk about sizes at all. > [We can't just check the scripts into the wine source tree > and require their installation.] Why not? If they save effort and work well, let's do it. - Dan

7 6

Re: WineD3D state management
by Stefan Dösinger 27 Nov '06

27 Nov '06

Am Montag 27 November 2006 13:36 schrieben Sie: > Here is log from 3DMark 2005, some new games are not working with those > patches, 3DMark 2001 works but very bad in high details tests. 05 fails because of pixel shaders / glsl, and I know that 2001 is broken because my patch doesn't care for offscreen rendering yet. The mail was mainly to show what the code looks like, rather than doing extensive testing. Its time for testing once pshaders, glsl and offscreen rendering are in. Sorry - Should have mentioned that in my original mail

3 4