Re: HLSL Compiler and d3dcompiler_xx.dll
On Apr 14, 2010, at 1:48 PM, Matijn Woudt wrote: >> I think you want to test if the compiled shader works instead of the >> exact bytecode. Generating the same bytecode is probably way too hard, >> fragile to test, and most likely not worth the effort. > > I think I should go for exact bytecode as long as it is possible, it's > the only way we can be sure the implementation is 100% right for each > test case. FYI, we encountered a game a while back which used a few shaders that depended on being compiled with a particular version for d3dx9_##.dll. There was a compiler bug which the game engine knew about and accounted for. If you tried to use the compiled shader from a newer d3dx9_##.dll, then the rendering wouldn't look quite right on certain objects. So, there's one argument for identical bytecode compatibility, but it's likely that very few apps will exhibit behavior like this.
Re: dbghelp: Make sure the ClientPointers flag is set correctly
On Dec 29, 2009, at 2:37 PM, Henri Verbeet wrote: > 2009/12/29 Jason Green : >> commit 317da09400946ca9f97361a47a227595c5bedfe3 >> Author: Eric van Beurden >> Date: Tue Dec 29 12:35:03 2009 -0500 >> >>Make sure the ClientPointers flag isn't set incorrectly > > Mostly out of curiosity, how did you generate this patch? That looks > like the kind of output git log gives, not git format-patch. Using "stg show" from stgit 0.14.2. Looks like that function is mostly just a passthrough to "git show". git-format-patch seems nicer since it gives the number of line items changed, etc., although there's probably an option in "git show" somewhere that will do that as well...?
Re: [usp10 1/6] Fix an uninitialized static variable.
We both work for TransGaming, and these patches are officially from the company. On Dec 17, 2009, at 4:22 PM, James Hawkins wrote: > On Thu, Dec 17, 2009 at 1:19 PM, Jason Green wrote: >> Sorry, should have copied Eric van Beurden on this earlier. His name & >> email are in the patch on the From: line. >> > > To clarify my question, are you guys working at a company that is > contributing to Wine, or are you contributing for fun, etc? > > James
Re: [usp10 1/6] Fix an uninitialized static variable.
Sorry, should have copied Eric van Beurden on this earlier. His name & email are in the patch on the From: line. On Dec 17, 2009, at 4:07 PM, James Hawkins wrote: > On Thu, Dec 17, 2009 at 12:56 PM, Jason Green wrote: >> Yeah, I was just forwarding this from one of our other internal developers. >> I just went back and noticed that he had a note here which said, "This patch >> isn't really necessary, and could be left off the submission to WineHQ." >> > > I'm just curious. Who is we? > > Thanks, > James Hawkins
Re: [usp10 1/6] Fix an uninitialized static variable.
Yeah, I was just forwarding this from one of our other internal developers. I
just went back and noticed that he had a note here which said, "This patch
isn't really necessary, and could be left off the submission to WineHQ."
:-)
On Dec 17, 2009, at 3:46 PM, Juan Lang wrote:
> Hi Jason,
>
> -static const ABC nil;
> +static const ABC nil = {0};
>
> This has no effect, as static variables are implicitly initialized to
> 0 anyway. It might be a little less surprising this way..
> --Juan
Re: [3/3] wininet: Add missing empty line to end of headers list
On Fri, Jun 5, 2009 at 6:21 AM, Alexandre Julliard wrote:
> Jason Green writes:
>
>> @@ -4265,6 +4265,24 @@ static INT HTTP_GetResponseHeaders(LPWININETHTTPREQW
>> lpwhr, BOOL clear)
>> }
>> }while(1);
>>
>> + /* make sure the response header is terminated with an empty line.
>> Some apps really
>> + truly care about that empty line being there for some reason. If
>> it's not present,
>> + just add it to the header. */
>> + if (cchRawHeaders >= 4 &&
>> + (strcmpW(&lpszRawHeaders[cchRawHeaders - 4], szCrLf) ||
>> + strcmpW(&lpszRawHeaders[cchRawHeaders - 2], szCrLf)))
>> + {
>
> This check doesn't seem necessary, I don't see how you could already
> have an empty line in the buffer since we only store valid headers.
Hi Alexandre,
Here's the response from the patch author, Eric van Beurden:
This check was added because the login server for one of our games was
sending a final line that either contained only whitespace or was received
as an empty string and that was being discarded. This left the headers list
without a terminating empty line (ie: ending in "\r\n\r\n"). The game then
went to retrieve and examine the CRLF raw headers and would just spin
endlessly because the terminating empty line was not present. Adding this
check allowed the game to succeed on the login immediately.
Admittedly, this is more an issue with improper information being sent back
from the server, but it would be better to ensure the terminating empty line
is present in all cases instead of storing potentially invalid headers.
Perhaps a more detailed comment in there would help?
Re: d3d9: Add some visual tests for Direct3DDevice9_StretchRect()
On Tue, Apr 1, 2008 at 5:45 AM, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Am Dienstag, 1. April 2008 07:20:44 schrieb Jason Green: > Did you take a look at the various capability flags? I think the test as you > submitted it is correct for dx9 level cards and drivers, but there are a few > capability flags like D3DDEVCAPS2_CANSTRETCHRECTFROMTEXTURE or similar. Also > some drivers seem to refuse StretchRecting between offscreenplain surfaces, > even if no stretching is used. Yeah, I meant to make a comment about that as a TODO, but I didn't have any cards lying around that didn't advertise that cap. If anyone does, it'd be interesting to see how Windows handles some of those cases. I'd guess it would be just like MSDN claims, but you never know until you actually test it. > Do you have any ideas what the scheme behind the allowed/forbidden blits is? > So far I can see this: > > -> Blitting to a rendertarget surface/texture is always OK > -> blitting between offscreen surfaces is ok as long as no stretching occurs > -> blitting to non-RT surfaces/textures faily, except the above > Yeah - turns out that MSDN was correct on this scheme: http://msdn2.microsoft.com/en-us/library/bb174471(VS.85).aspx These tests show that the results of the dx9 drivers are valid according to that page. > Did you test blitting from/to sysmem surfaces? The msdn says both must be > D3DPOOL_DEFAULT as far as I remember Yep - I probably should have left a few tests in there for that, but the only surfaces that are valid to call StretchRect on must be in D3DPOOL_DEFAULT (both source and destination). Everything else fails.
Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
On Jan 23, 2008 3:38 PM, Eric Pouech <[EMAIL PROTECTED]> wrote:
> Jason Green a écrit :
> thanks for the sample files
> how does this patch solve the issue ?
> A+
>
> diff --git a/include/wine/mscvpdb.h b/include/wine/mscvpdb.h
> index 58627c0..8a22dfd 100644
> --- a/include/wine/mscvpdb.h
> +++ b/include/wine/mscvpdb.h
> @@ -343,9 +343,9 @@ union codeview_type
> {
> unsigned short int len;
> short int id;
> -unsignedthis_type;
> -unsigned intclass_type;
> unsigned intrvtype;
> +unsigned intclass_type;
> +unsignedthis_type;
> unsigned char call;
> unsigned char reserved;
> unsigned short params;
Hey, Eric - I actually don't see that part of a patch anywhere in what
I submitted... Are you sure this was what you meant to paste?
Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
See the first paragraph: :) Re-re-responses from Eric van Beurden. I'll send the sample app to you off-list (and anyone else who wants a copy, just email me directly).: I'll send it to you off-list, too, John. On Jan 23, 2008 10:31 AM, John Klehm <[EMAIL PROTECTED]> wrote: > On Jan 23, 2008 8:14 AM, Jason Green <[EMAIL PROTECTED]> wrote: > > > > The attached archive contains 4 files: > > - 'emptyTest.exe': the optimized release build executable linked to > > 'emptyTest.pdb'. This should crash. > > - 'emptyTest.pdb': the PDB file > > - 'main.cpp': the source file for the test app. Some of the code is > > unused as the app has morphed over time. > > - 'emptyTest.vcproj': the VC++7.1 project file for the test app > > > > Missing the attachment? > > --John >
Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
On Jan 22, 2008 4:00 PM, Eric Pouech <[EMAIL PROTECTED]> wrote: > Jason Green a écrit : > > Re-responses from Eric van Beurden: > > > > > >> hmm I still don't get how, in a generic way symbols could overlap > >> the only think I could come up with if when static functions get > >> automatically inlined by the compiler, but that's rather a different > >> story (as I'd suspect the inlined function to be a single memory range > >> within a container => and in that case returning the shortest matching > >> symbol should be fine is there an existing exe/pdb file available for > >> further testings > >> > > > > > > in testing with one of our projects, i was seeing symbols lookups fail > > 85-90% of the time with the initial versions of dbghelp. The PDB > > files that were being used were generated along with the release build > > of the project (it was a C++ project as well). On further > > investigation i found that the lookups were failing because many > > symbol addresses and ranges were overlapping. This seemed to occur on > > even unrelated objects and symbols. I would suspect it was the result > > of the optimizations the compiler performed. > > > > I was able to generate PDBs that exhibited this behaviour with every > > test app i built under Visual Studio (v7.1 and 8.0Express); even apps > > that were only 25 lines long. Since it was very repeatable and the > > project in question would always be using PDBs generated from > > optimized release builds i decided to change the symbol lookup method > > to take the range into account and to be able to store a sublist of > > all symbols whose addresses fall into the same range (15-25% of the > > lookups still failed with just the range addition). > > > I'm still not convinced that the fix proposed is the correct one. Do you > have one of those examples handy so that I can have a look on it (src > file + .exe + .pdb) ? that would be great > TIA Re-re-responses from Eric van Beurden. I'll send the sample app to you off-list (and anyone else who wants a copy, just email me directly).: I tracked down one of my sample apps that showed the overlapping symbols issue in its PDB file. Many of the symbols in it are either coincident or overlapping. In some cases the overlap occurs between a C++ decorated name and its undecorated counterpart, but in several cases the overlapping symbols are unrelated. For some symbols it could be possible that their sizes are being read incorrectly from the PDB. The original symbol lookup method used a binary search on a symbol list that was sorted by starting address. The issue was that during the search it was skipping over the correct symbol because its starting address was the same as a previous symbol's address. This sent the search in the wrong direction after that and the lookup would fail. There was no fallback for handling the case of the symbol being coincident with another or the symbol being within the address space of another symbol. The attached archive contains 4 files: - 'emptyTest.exe': the optimized release build executable linked to 'emptyTest.pdb'. This should crash. - 'emptyTest.pdb': the PDB file - 'main.cpp': the source file for the test app. Some of the code is unused as the app has morphed over time. - 'emptyTest.vcproj': the VC++7.1 project file for the test app
Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
Re-responses from Eric van Beurden: > hmm I still don't get how, in a generic way symbols could overlap > the only think I could come up with if when static functions get > automatically inlined by the compiler, but that's rather a different > story (as I'd suspect the inlined function to be a single memory range > within a container => and in that case returning the shortest matching > symbol should be fine is there an existing exe/pdb file available for > further testings in testing with one of our projects, i was seeing symbols lookups fail 85-90% of the time with the initial versions of dbghelp. The PDB files that were being used were generated along with the release build of the project (it was a C++ project as well). On further investigation i found that the lookups were failing because many symbol addresses and ranges were overlapping. This seemed to occur on even unrelated objects and symbols. I would suspect it was the result of the optimizations the compiler performed. I was able to generate PDBs that exhibited this behaviour with every test app i built under Visual Studio (v7.1 and 8.0Express); even apps that were only 25 lines long. Since it was very repeatable and the project in question would always be using PDBs generated from optimized release builds i decided to change the symbol lookup method to take the range into account and to be able to store a sublist of all symbols whose addresses fall into the same range (15-25% of the lookups still failed with just the range addition). > hmm still not sure it's the correct explanation... the 928k value is not > that clear (and doesn't explain the impact of the order) > I'd rather fear something like windbg mmaps the first meg of minidump > upfront, and expects to get most the relevant information (the 5 listed > streams, potentially header and data, in that mapping)... memory is > likely to be used differently by another memory mapping, hence getting > around the 1meg barrier (that's still needs to be further tested anyway) Sorry, i don't think i explained it properly last time. The 928kb stream limiting change was incorrect and should be ignored now. It very well could be that windbg only mmaps the first 1MB of the file in an effort to find the SystemInfoStream information (and some others). The issue arose when we were performing a minidump that included a thread with an invalid ESP and EBP value in its Context struct. This resulted in us dumping the whole stack buffer (~1.14MB) for that thread instead of just the used area. Windbg refused to open the minidump after that. It complained that the SystemInfoStream could not be found (as it came after the MemoryListStream data in the file). The stream reordering was done for a couple of reasons: - to put the smaller, fixed size, standard streams first in the file where windbg seemed to want them - to better match the stream ordering that native dbghelp wrote its minidump files in. The stream ordering still isn't identical because native does things such as coalesce all strings into the same area of the minidump file (instead of putting each string immediately after the stream they belong to), and group stream data and non-stream data together.
Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
Eric, below are the responses from Eric van Beurden, who wrote the patch. I merely split it up and removed a bunch of traces for submission to WineHQ. The problem is that all of our changes were done initially in just a couple of huge commits during the initial import of dbghelp instead of nice, incremental changes. I split things up based mostly on a file by file basis, but I can further split this one as well On Jan 18, 2008 3:14 PM, Eric Pouech <[EMAIL PROTECTED]> wrote: > what's the rationale of optimized pdb ? An optimized PDB file is generated with an optimized build of an app. Symbol addresses and ranges can overlap in these files. The existing implementation neither takes that into account when sorting the list nor when looking up symbols. This results in symbol lookups failing ~85-90% of the time. > the patch is already big enough not to mix code evolution with stuffing > new trace:s all over the place Understood. Re: 7/10 - Fix file searching to search only listed directories instead of the whole HD: > you failed to set DebugFilePath to the desired value > again the rest of the patch has nothing to do with the first part of the > patch Previously, the FindDebugInfoFile() function was using the function's return value string as the me of the first file to open. This was an error since there is no requirement that this string be initialized to anything. However, you are correct in pointing out that the variable did not get set in the event that the first attempt at finding the file succeeded. This fix will be submitted. Re: 10/10 - Clamp minidump memory blocks to 928KB: > if that's really the case (and I'm even not sure we want to support this > backward compatibility), a good fix would be to add several streams each > up to 928k instead of clamping After much more research and testing this turned out to be in error. The issue was not actually the size of the single stream, it was the ordering of the streams that windbg did not like. Windbg expects the six standard streams in the following order or else it will have trouble opening some minidumps: SystemInfoStream MiscInfoStream ExceptionStream ThreadListStream ModuleListStream MemoryListStream The stream table at the start of the file is sorted in numerical order by stream ID (as the current implementation has), but the actual stream data must appear in the above order after the file header. Our current fix for this is rather hacky and needs to be fixed properly and cleaned up before resubmitting. The proper fix would be to change the order that each stream is created, then to sort the stream table by stream ID before writing it to file.
Re: Hmm. Cider and the LGPL
> Hi Jason, > on the off chance the rest of Transgaming hasn't already > seen those two pages, please circulate the links. > One of the problems is that [to my knowledge,] we don't have any fluent German speakers in the company, so we wouldn't even know *how* to respond to those articles. :) > it'd be nice to have responses to questions like > "The LGPL seems to give users the right to remove > the LGPL'd portions of Cider from game A and use it > with other apps. The gamers who are currently doing this > are also copying proprietary parts of Cider, which isn't allowed. > How will Transgaming prevent the copying of the proprietary > parts of Cider without preventing the copying or modification > of the LGPL portions?". > The EULA included in all games which are shipped using Cider technology spells out how each of the pieces of the Cider framework are licensed. It includes the folders which have LGPL'd WineHQ code and lists all of the various MIT/BSD-style licenses for other components. Any components which require source re-distribution (such as those licensed under the LGPL) are available on the public CVS site. All of the license details can also be found on the public CVS site. We know that some people are creating their own "home-brew" Cider packages for other games, but they obviously cannot distribute these packages legally (in most countries, at least). It does take a fair bit of work to put together a custom package that actually works, and many of these apparently require hacked EXEs to get around other games' copy protection techniques. We do make customizations to the Cider engine and optimizations for each game that we port, so these "home-brew" games will never be as high quality as they could be. At the moment, there isn't much of a real issue to be worried about. People have pirated software on every platform that's ever been made, so I don't see why Macs would be any different. Not that we condone software piracy (ahem, *copyright violations*, that is) by any means, but in this case, it's mostly a non-issue. I'm not sure if that answers your question or not, but hopefully it clears it up a little bit. If a user wants to use only the LGPL parts of Cider, they will need to extract just those folders and leave the rest of the code alone. However, they'd probably have a hard time running a DirectX-based game without any of the D3D* libraries or many of the other non-LGPL pieces. > And maybe even get the answer back to the authors of those pages. > Anyone who speaks German is invited to respond to these types of articles and point them to our website and PR department. To my knowledge, I don't believe that these authors attempted to contact us prior to writing their articles. > That ought to calm the waters. > Nah, this is the Internet... there's always a storm brewing somewhere. ;-) Jason Green Developer, TransGaming, Inc.
Re: Hmm. Cider and the LGPL
On 8/30/07, Dan Kegel <[EMAIL PROTECTED]> wrote: > http://www.linux-community.de/story?storyid=23294 and > http://www.macnews.de/news/102145.html mention > that some users are using Cider from one game > to run a second game on the Mac. The game vendors > are upset, and are saying they'll do something to make > that harder. There is some question about whether Cider > includes LGPL components of Wine, and whether there > are any violations lurking there. > I imagine our friends at Cedega would > instinctively avoid such infringement, but accidents might > happen. It'll be interesting to see if anybody finds a real problem. All of the LGPL Cedega/Cider source code is available on TransGaming's public CVS server at http://www.cedega.com/cvs/. Any substantial patches to LGPL'd components are typically submitted back to WineHQ. There haven't been many recently since most of those components aren't heavily used by games. One of my roles at TransGaming is to make sure that patches to our LGPL'd folders make their way back here. Jason Green Developer, TransGaming, Inc.
Re: debugging help
On 6/18/07, Damjan Jovanovic <[EMAIL PROTECTED]> wrote: only appear in +snoop, not in +relay. And is there a way for a builtin DLL to LoadLibrary() the native DLL of the same name and call functions in it? It would be very useful in narrowing down the bug. You can definitely use LoadLibrary() / GetProcAddress() inside of a builtin DLL manually to compare results against the native function. You'll have to change the name of the native DLL to avoid loading the builtin one by accident. Of course, none of that type of debugging code should be in the main git tree. Take a look at the tests/ folders for good examples of how to dynamically load the DLLs and functions.
Re: iphlpapi: Only call res_init() once per process
On 4/18/07, H. Verbeet <[EMAIL PROTECTED]> wrote: On 18/04/07, Jason Green <[EMAIL PROTECTED]> wrote: > Original author: Mark Adams, TransGaming Technologies. > Why are you the one submitting this then, using a private mail address? (Are you even allowed to, for that matter?) Because my @transgaming.com account isn't subscribed to wine-patches, and this method was easier. Mark asked me to submit the patch, since our iphlpapi is the same as the WineHQ LGPL dll, and he's busy with meetings and other things today. I'm fully allowed to collaborate with WineHQ on any projects that don't involve the closed-source aspects of Cedega (basically, DirectX and copy protection). The vast majority of Cedega is available on our public CVS at transgaming.org. Feel free to email my work account (jason at transgaming dot com) or Mark Adams (mark at transgaming dot com) if you need further validation. Gavriel State submitted iphlpapi patches a few months ago that were written by Mark as well, so this isn't anything new (although he probably used his TG email account).
Re: Benchmarking Wine
On 8/2/06, H. Verbeet <[EMAIL PROTECTED]> wrote: On 02/08/06, Tom Wickline <[EMAIL PROTECTED]> wrote: > > As for 3DMark 05 and 06, they don't seem to think we support Pixel Shader 2.0, > > even when using GLSL, so I'm not sure how valuable those would be to > > benchmark in that state. I've come accross some sample programs that seem to use a reference device to check what shader versions we support. I don't know if 3DMark05/06 do that as well, but it might be something to look for. +d3d_caps should be enough to tell. There's also a chance that some programs check the VS20CAPS or PS20CAPS structures which we currently don't fill at all, and report 0's. These should be fairly easy to fill as they don't look that complicated from MSDN.
Found a sample with source code of the broken character models/misplaced vertices
The SkinnedMesh sample from the dx8.1 sdk is broken in shader mode, but you have to change the caps to get anything to show up. In directx.c, I set MaxVertexBlendMatrices to 4 and MaxVertexBlendMatrixIndex to 0 (to match to caps of my machine in Windows), then launched the sample and switched to Software mode, then Shader mode. (if you go straight to shader mode, it crashes - yet another bug. ;-) It results in a broken animation and misplaced vertices like many games have been experiencing: http://www.cmhousing.net/wine/skinnedmesh_broke.png We finally have a simple sample to experiment with which, when fixed, should fix the broken models in most newer games [hopefully].
Re: wined3d: More shader fixes / new instructions
Makes sense. Please use this patch instead. Everything is the same:
- Replace gl_FragColor with gl_FragData[0] for GLSL pixel shader output.
- Subtract 1 more constant from total GLSL allowed float constants to
accommodate the PROJECTION matrix row that we reference. Some of the
shaders in the Settlers 2 demo were failing due to accessing too many
constants.
(Settlers 2 still doesn't render correctly due to not supporting
multiple render targets, but that should be the last major roadblock
for it)
On 7/28/06, H. Verbeet <[EMAIL PROTECTED]> wrote:
On 28/07/06, Jason Green <[EMAIL PROTECTED]> wrote:
> - GLSL: Translate oC0-oC3 output registers (multiple render targets)
> to gl_FragData[] register. We don't support draw buffers yet, but
> this allows shader programs that use those registers to compile (such
> as Settlers 2)
If you do that, you should use gl_FragData[] for *all* render targets,
including the first one. gl_FragColor will write to all render
targets.
diff --git a/dlls/wined3d/arb_program_shader.c
b/dlls/wined3d/arb_program_shader.c
index a2b07db..6700de3 100644
--- a/dlls/wined3d/arb_program_shader.c
+++ b/dlls/wined3d/arb_program_shader.c
@@ -171,7 +171,6 @@ void shader_generate_arb_declarations(
/* Need to PARAM the environment parameters (constants) so we can use
relative addressing */
shader_addline(buffer, "PARAM C[%d] = { program.env[0..%d] };\n",
max_constantsF, max_constantsF - 1);
-shader_addline(buffer, "PARAM PROJECTION =
state.matrix.projection.row[1];\n");
}
static const char* shift_tab[] = {
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 5b35494..4454d98 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -243,8 +243,8 @@ void select_shader_max_constants(WineD3D
switch (wined3d_settings.vs_selected_mode) {
case SHADER_GLSL:
-/* Subtract the other potential uniforms from the max available
(bools & ints) */
-gl_info->max_vshader_constantsF = gl_info->vs_glsl_constantsF -
MAX_CONST_B - MAX_CONST_I;
+/* Subtract the other potential uniforms from the max available
(bools, ints, and 1 row of projection matrix) */
+gl_info->max_vshader_constantsF = gl_info->vs_glsl_constantsF -
MAX_CONST_B - MAX_CONST_I - 1;
break;
case SHADER_ARB:
/* We have to subtract any other PARAMs that we might use in our
shader programs.
diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c
index b3ae5cb..63af4f7 100644
--- a/dlls/wined3d/glsl_shader.c
+++ b/dlls/wined3d/glsl_shader.c
@@ -638,12 +638,10 @@ static void shader_glsl_get_register_nam
sprintf(tmpStr, "Vsampler%lu", reg);
break;
case D3DSPR_COLOROUT:
-if (reg == 0)
-sprintf(tmpStr, "gl_FragColor");
-else {
+sprintf(tmpStr, "gl_FragData[%lu]", reg);
+if (reg > 0) {
/* TODO: See GL_ARB_draw_buffers */
FIXME("Unsupported write to render target %lu\n", reg);
-sprintf(tmpStr, "unsupported_register");
}
break;
case D3DSPR_RASTOUT:
@@ -914,7 +912,6 @@ void shader_glsl_map2gl(SHADER_OPCODE_AR
case D3DSIO_NRM:strcat(tmpLine, "normalize"); break;
case D3DSIO_LOGP:
case D3DSIO_LOG:strcat(tmpLine, "log2"); break;
-case D3DSIO_EXPP:
case D3DSIO_EXP:strcat(tmpLine, "exp2"); break;
case D3DSIO_SGE:strcat(tmpLine, "greaterThanEqual"); break;
case D3DSIO_SLT:strcat(tmpLine, "lessThan"); break;
@@ -942,6 +939,39 @@ void shader_glsl_map2gl(SHADER_OPCODE_AR
}
+/** Process the D3DSIO_EXPP instruction in GLSL:
+ * For shader model 1.x, do the following (and honor the writemask, so use a
temporary variable):
+ * dst.x = 2^(floor(src))
+ * dst.y = src - floor(src)
+ * dst.z = 2^src (partial precision is allowed, but optional)
+ * dst.w = 1.0;
+ * For 2.0 shaders, just do this (honoring writemask and swizzle):
+ * dst = 2^src;(partial precision is allowed, but optional)
+ */
+void shader_glsl_expp(SHADER_OPCODE_ARG* arg) {
+
+char tmpLine[256];
+char dst_str[100], src_str[100];
+char dst_reg[50], src_reg[50];
+char dst_mask[6], src_mask[6];
+IWineD3DPixelShaderImpl* This = (IWineD3DPixelShaderImpl*) arg->shader;
+DWORD hex_version = This->baseShader.hex_version;
+
+shader_glsl_add_param(arg, arg->dst, 0, FALSE, dst_reg, dst_mask, dst_str);
+shader_glsl_add_param(arg, arg->src[0], arg->src_addr[0], TRUE, src_reg,
src_mask, src_str);
+shader_glsl_add_dst(arg->dst, dst_reg, dst_mask, tmpLine);
+
+if (hex_version < D3DPS_VERSION(2,0)) {
+shader_addline(arg->buffer, "tmp0.x =
Re: Broken character models in dx8/9 games in wined3d
On 7/26/06, Frank Richter <[EMAIL PROTECTED]> wrote: I thought more along the lines of "flip result.position.y", not changing the MVP matrix. I just sent a patch to wine-patches do just that. I thought that the broken character models would have been a related issue, but that is apparently not the case. Neither of the previous two hacks (which completely flipped the textures at the cost of decreased framerate) had any effect on the character models. My initial hack was on the right track, but it didn't mask the output for y, so it was having issues with other objects that used shaders. So, now it's on to figuring out why the models are disjointed (like this: http://www.cmhousing.net/wine/civ4_brokenmodels.png and this: http://www.cmhousing.net/wine/hl2_models2.png). :-) There are still a few places where I don't think we use shaders that look like they may be rendering upside down, or at least are offset improperly. I'll keep digging into those, too. Thanks, guys!
Re: Broken character models in dx8/9 games in wined3d
Well, we discussed a few different ways of handling this, and here are
the results:
1) We can flip the texture we get from the framebuffer in
Device_LoadTexture. Getting images from the back framebuffer always
are upside down, so we'll need to manually flip it before setting it
as the next render target.
a) Use glCopyTexSubImage2D() to swap each row
b) Use glReadPixels() to copy to a buffer, flip the image, then use
glTexImage2D() to write it back.
Both of these methods fixed the upside down rendering, but the issue
of the disconnected/broken models is still there, although less
prevalent now that things look more normal to begin with. I've
attached both patches. However, performance takes a pretty serious
hit:
Max Payne 2 with pixel shaders enabled in High detail mode (there are
still some lighting bugs, though):
Current git (upside-down): ~65 fps
1a: ~35 fps
1b: ~15 fps
Civ4 with pixel shaders enabled
Current git (some upside-down stuff and very broken models): 30-50 fps
1a (still some broken models): ~35 fps
1b (still some broken modles): 25-35 fps
2) Try to do some kind of fixup in the shader itself. I'm not
entirely sure how to do this other than being creative with the small
hack I posted originally. There are no noticable performance losses,
but visually, some things are broken (the sky in Tomb Raider Legends
as well as Half Life 2 are completely wrong, but Max Payne is about
99% right).
Any other suggestions? Also, the models are still broke, so that may
be a separate topic and not related like I thought it was.
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 323a2f5..f0fe2ec 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -3463,25 +3463,15 @@ static HRESULT WINAPI IWineD3DDeviceImpl
case D3DCULL_CW:
glEnable(GL_CULL_FACE);
checkGLcall("glEnable GL_CULL_FACE");
-if (This->renderUpsideDown) {
-glFrontFace(GL_CW);
-checkGLcall("glFrontFace GL_CW");
-} else {
-glFrontFace(GL_CCW);
-checkGLcall("glFrontFace GL_CCW");
-}
+glFrontFace(GL_CCW);
+checkGLcall("glFrontFace GL_CCW");
glCullFace(GL_BACK);
break;
case D3DCULL_CCW:
glEnable(GL_CULL_FACE);
checkGLcall("glEnable GL_CULL_FACE");
-if (This->renderUpsideDown) {
-glFrontFace(GL_CCW);
-checkGLcall("glFrontFace GL_CCW");
-} else {
-glFrontFace(GL_CW);
-checkGLcall("glFrontFace GL_CW");
-}
+glFrontFace(GL_CW);
+checkGLcall("glFrontFace GL_CW");
glCullFace(GL_BACK);
break;
default:
@@ -7385,28 +7375,9 @@ #endif
IWineD3DSurface_AddRef(This->renderTarget);
IWineD3DSurface_Release(tmp);
-{
-DWORD value;
-
-/* The surface must be rendered upside down to cancel the flip produce
by glCopyTexImage */
-/* Check that the container is not a swapchain member */
-
-IWineD3DSwapChain *tmpSwapChain;
-if (WINED3D_OK != IWineD3DSurface_GetContainer(This->renderTarget,
&IID_IWineD3DSwapChain, (void **)&tmpSwapChain)) {
-This->renderUpsideDown = TRUE;
-}else{
-This->renderUpsideDown = FALSE;
-IWineD3DSwapChain_Release(tmpSwapChain);
-}
-/* Force updating the cull mode */
-TRACE("setting render state\n");
-IWineD3DDevice_GetRenderState(iface, WINED3DRS_CULLMODE, &value);
-IWineD3DDevice_SetRenderState(iface, WINED3DRS_CULLMODE, value);
-
-/* Force updating projection matrix */
-This->last_was_rhw = FALSE;
-This->proj_valid = FALSE;
-}
+/* Force updating projection matrix */
+This->last_was_rhw = FALSE;
+This->proj_valid = FALSE;
/* Restore recording state */
This->isRecordingState = oldRecording;
diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c
index bb48982..485e0fe 100644
--- a/dlls/wined3d/drawprim.c
+++ b/dlls/wined3d/drawprim.c
@@ -148,12 +148,6 @@ static void init_materials(IWineD3DDevic
}
-static GLfloat invymat[16] = {
- 1.0f, 0.0f, 0.0f, 0.0f,
- 0.0f, -1.0f, 0.0f, 0.0f,
- 0.0f, 0.0f, 1.0f, 0.0f,
- 0.0f, 0.0f, 0.0f, 1.0f};
-
void d3ddevice_set_ortho(IWineD3DDeviceImpl *This) {
/* If the last draw was transformed as well, no need to reapply all the
matrixes */
if ( (!This->last_was_rhw) || (This->viewport_changed) ) {
@@ -190,10 +184,6 @@ void d3ddevice_set_ortho(IWineD3DDeviceI
a pixel (See comment above glTranslate below)
*/
glTranslatef(0.375, 0.375, 0);
checkGLcall("glTranslatef(0.375, 0.375, 0)");
-if (This->renderUpsideDown) {
-glMultMatrixf(invymat);
-checkGLcall("glMultMatrixf(invymat)");
-}
Re: Broken character models in dx8/9 games in wined3d
On 7/25/06, H. Verbeet <[EMAIL PROTECTED]> wrote: Can't we just correct the texture coordinates / start writing the surface contents at the bottom? Also, if we use EXT_framebuffer_object instead, we probably won't have to use glCopyTexImage in the first place. No idea, but that's the type of answer I was looking for. :-) http://www.winehq.com/hypermail/wine-patches/2004/04/0433.html is the patch which first started this whole concept of flipping to begin with, if that helps.
Re: Broken character models in dx8/9 games in wined3d
On 7/25/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Can we flip around the y axis in the shader? It's not quite so easy. At the moment in the case w/o shaders, we multiply the WORLDVIEW and/or PROJECTION matrices by a matrix that flips the y axis on the whole matrix, like so: 1 1 1 1 1 0 0 0 2 2 2 2 0 -1 0 0 3 3 3 3 * 0 0 1 0 4 4 4 4 0 0 0 1 = 1 -1 1 1 2 -2 2 2 3 -3 3 3 4 -4 4 4 However, when you use a shader, you don't use those matrices at all, you pass your own vec4 (4 component float vector) constants into the shader program, and you don't just have 4 of them to use as a matrix, you have as many as the hardware allows (typically 96 or 256 with current hardware). So, we don't know which ones the shader will use as it's MV/P matrix, so we can't perform any type of y-flip at that spot because we might mess up the other constants that the shader needs to perform its calculations. Plus, the same shader can be used for multiple render targets - some upside-down and some not. Flipping the y position in the shader based on the current MVP matrix fixes the issue in some cases, but only when the shader's "effective MVP matrix" is the identity matrix. If the constants that the app passes to the shader differ from the identity matrix, then our y-flip isn't taking any of the other rows y-flip into account, so the calculations are wrong and hence the models are broken.
Broken character models in dx8/9 games in wined3d
I've spent a couple of days researching the issue of
broken/upside-down character/object models in Wine in almost all newer
games when you have vertex shaders enabled (Civ4, Half Life 2,
Oblivion, Max Payne 2, etc.). I think I've boiled it down to a single
case: When "device->renderUpsideDown" is set in the case where vertex
shaders are enabled. That flag gets set in device.c:7395 when the
current renderTarget is not on the current swapchain. The comments in
the source say that the upside-downedness is produced by
glCopyTexImage, so it sets a flag to flip everything over.
In the case w/o shaders, there is code in drawprim.c which loads the
WORLDVIEW and PROJECTION matrices and then multiplies those matrices
by one which inverts the y coordinates when that flag is set. That
seems to work in the case without vertex shaders, but when shaders are
enabled, they bypass the WORLD, VIEW, and PROJECTION matrices
entirely. The shader case was written when only software shaders
worked, but that is no longer true. It loads identity matrices and
performs the y flip, but that code is entirely irrelevant since the
vertex shader doesn't reference those matrices; it only uses constants
that are passed by the app, which we can't perform any type of fixup
on since we don't know which constants will be used for which
calculation.
So, I think what we need to do is prevent ourselves from having to do
any flipping whatsoever. That's the part that I'm not sure how to do
and is the reason for this email. Can we load the textures in system
memory first, perform a software reversing process, then load that up
with glCopyTexImage instead? Will we need to do that type of fixup
every time the app locks/unlocks/changes part of the texture? Or, is
there a better way?
I think I've figured out the problem, it's just the next step of
fixing it that I'm unsure of. :-)
From a few hackish tests, I've been able to fix some of the issues
where the only thing wrong was that the images were upside-down with
this hack (for GLSL shader mode only):
diff --git a/dlls/wined3d/vertexshader.c b/dlls/wined3d/vertexshader.c
index 84f90f5..d0325d9 100644
--- a/dlls/wined3d/vertexshader.c
+++ b/dlls/wined3d/vertexshader.c
@@ -719,6 +719,7 @@ #endif
shader_addline(&buffer, "gl_FogFragCoord =
clamp(gl_FogFragCoord, 0.0, 1.0);\n");
}
+shader_addline(&buffer, "gl_Position = gl_Position *
gl_ModelViewProjectionMatrix;\n");
shader_addline(&buffer, "}\n\0");
TRACE("Compiling shader object %u\n", shader_obj);
This works because the gl_ModelViewProjectionMatrix is just a matrix
which reverses the y position when This->renderUpsideDown == TRUE,
otherwise it's the identity matrix. Here are a few comparison
screenshots:
Oblvion:
-
Before: http://www.cmhousing.net/wine/oblivion2.png
After: http://www.cmhousing.net/wine/oblivion_sortacorrect3.png
Civ4:
-
Before: http://www.cmhousing.net/wine/civ4_before.png
After: http://www.cmhousing.net/wine/civ4_leaderhead.png
Half Life 2:
-
After: http://www.cmhousing.net/wine/hl2_rightsideup.png (the bottom
got screwed up, but normally the guy on the picture is upside-down)
Many of the character models and other objects are still broken even
with that hack, but that's because we should be flipping more than
just the final position - we should be flipping a whole row of
constants that the app is using before it starts its calculations.
Instead of trying to do that, we should fix the root of the problem
IMHO.
Anyway, any ideas are welcome. :-)
Jason
Re: wined3d: Fix regression from dynamic constants patch
I was getting ready to argue with you this point, but you made a comment on IRC that changed my mind: "I thought the idea was to support the full range of the hardware". And, you're right. :-) So, please ignore this patch for now - I'll re-work it over the weekend and resubmit. On 7/21/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote: > > There were plenty of ways to fix this. One would have been to unroll > all of the memset/memcpy calls into functions that explicitly set > every value on the stateblock. While this might have been more > "correct", it would be harder to maintain. I argue that an explicit initializer is always better than an implicit one. An implicit initializer is basically programmer laziness imho (I consider myself very lazy :) When you add a new feature, you should check its initialization one way or the other - can't rely on calloc assumptions, the code has to be verified. So, while you're doing that, it's easy to add an initializer. > Plus, we might lose some performance from numerous sets vs. > a single memset routine. Code correctness, clarity and reliability is much more important than any performance considerations imho. Saving 1 cpu cycle here or there does not matter in the long run. > So, I chose to make the number of constants more fixed again (less > dynamic). The number of available constants is now capped at 256, > which is the minimum required number for shader model 3.0. Software shaders require 8192 constants. They're not supported right now, but that gives you an idea of how many we need to support. Anyway, I'm not sure which way is better - maybe you're right that making things dynamic is not worth the trouble. However, I think that shows lack of flexibility in the stateblock, and if we ever need to make other things dynamic in the future we might run into the same issue. > The app > will use the min() of 256 and the number reported by the card So it uses the lower value? How come?
Re: wined3d: Implement more GLSL instructions
On 7/21/06, Chris <[EMAIL PROTECTED]> wrote: On Friday 21 July 2006 11:19, Jason Green wrote: > + /* Calculate reflection vector (Assume normal is normalized): RF = 2*(N.E)*N -E */ > + shader_addline(buffer, "tmp0.w = dot(vec3(tmp0), %s);\n", src1_str); > + shader_addline(buffer, "tmp0 = tmp0.w * tmp0;\n"); > + shader_addline(buffer, "tmp0 = (2.0 * tmp0) - %s;\n", src1_str); I'm hardly an expert, but couldn't this be simplified to: shader_addline(buffer, "tmp0 = reflect(-%s, vec3(tmp0));\n", src1_str); Yeah, looks correct from the GLSL spec. I basically just copied the formula from the arb_shader routine and it seemed to display everything the same in both modes. It's probably worth simplifying, though. Either way should work.
Re: Winlib - Active Scripting
On 7/19/06, Dan Kegel <[EMAIL PROTECTED]> wrote: Hi Luc, I know of no issues (other than that this would restrict you to running on x86, but perhaps that's not an issue for you). I don't think anyone's done it before, but I could be wrong. On 7/19/06, Luc-Eric Rousseau <[EMAIL PROTECTED]> wrote: > thanks. > Are there any known issue with the native microsoft WSH (Windows > Scripting Host)DLL under wine? Has this this been done with a WineLib > app in the past? If you're planning on distributing this app to customers, there may be legal licensing issues involved with using those libraries. IANAL, but just thought I'd give a heads up. Jason
Re: another wined3d compile fail
On 7/19/06, James Hawkins <[EMAIL PROTECTED]> wrote: make[2]: Entering directory `/home/jhawkins/wine/dlls/wined3d' ... gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o directx.o directx.c directx.c: In function `IWineD3DImpl_FillGLCaps': directx.c:553: `GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB' undeclared (first use in this function) directx.c:553: (Each undeclared identifier is reported only once directx.c:553: for each function it appears in.) make[2]: *** [directx.o] Error 1 make[2]: Leaving directory `/home/jhawkins/wine/dlls/wined3d' That was my fault - I'm away from my Linux box at the moment, but Henri Verbeet offered to send in a patch for it (Thanks!). I wrongly assumed the define was already present in our includes. Jason
Re: Testing help needed: Pixel format whitelisting
On 7/7/06, Jason Green <[EMAIL PROTECTED]> wrote: On 7/1/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Half Life 2, on the other hand, won't launch the level after the patch (at least with pixel shaders enabled). I've attached the d3d_caps logs grepped for "CheckDeviceFormat" from before and after for comparison. The game launches, but it gets about half-way through the status bar loading the first level (Point Insertion), and then crashes. Reporting that we support V8U8 and V16U16 (like the old code did) fixes Half Life 2. Apparently it needs to have at least one bump mapping format available.
Re: Battlefront blending problem is fixed.
On 6/28/06, Jesse Allen <[EMAIL PROTECTED]> wrote: Hi Henri, You latest round of wined3d patches fixed the blending problem in SW Battlefront including blocky text. Now I can properly aim at targets. :) Yes, Henri, thanks again for this patchset. A *lot* more works now because of it. :-) Good work!
Re: Opengl states in wined3d
On 6/25/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: The way opengl states are managed in wined3d at the moment is a bit messy and inefficient. Agreed. :-) * Brute force applying opengl states is likely to re-set the old state unnecessarily. Opengl does not assure that redundant calls are cheap. * if an application sets and resets a state for some reason between 2 drawprim calls that involves 2 not really necessary opengl state switches I have this problem with Fog settings in the case of shaders. If I set & restore the fog states on each drawPrimitive, it will drop the fps from 1250 to about 1000 in the Dolphin demo compared to just setting it once and leaving it. I've been holding off on a patch (pretty much taken from Roderick Colenbrander) for this reason. At the moment in current git, fog is broken when used with shaders (Dolphin demo and Tomb Raider Legend are affected). I can think of a few ways to solve this: * Do not do any opengl changes in SetRenderState, and apply all states in drawprim. This way UnlockRect and Blt don't have to care for resetting the things they changed and redundant changes can be catched nicely This style is probably the best, since we (hopefully) don't have to change much between drawPrim calls. Just have a function which compares the current GL state to the desired (cached) state, and change only what's necessary. However, some things (as you mentioned) can be changed safely during SetRenderState, and that's outside of the drawPrim loop, so hopefully it's just once per scene. Though, every game acts a bit differently, so it's tough to say how one method will work over another. But the caching method seems the cleanest to me. To avoid re-setting an old setting again the current opengl state could be stored in the d3ddevice. I think this should be done in any case, and depending on the nature of some parameters the opengl state or the d3d state should be kept in there(or both). Agreed. I also think we should try to get rid of as much things as possible in drawprim. I do not mean entirely removing it, but having a simple flag which tells if a bigger number of states needs attention, like last_was_rhw does. I think about adding a last_was_blit flag which is set in BltOverride and UnlockRect. Yep. So, let's get a final game plan together and I can start the process with the fog patch, then we can start cleaning up everything else (which will be a fairly large undertaking but can be done in small chunks). Jason
wined3d: Regression in DX8 SDK samples with VBO patch
http://source.winehq.org/git/?p=wine.git;a=commit;h=2122026713baa318093181607db79d7577f728e9 This patch breaks most of the DirectX 8 SDK Direct3D samples (Billboard, ClipMirror, Cull, etc.). It seems like most of the samples that use Shaders work fine, but those that don't are broken (misplaced vertices, etc.).
Re: wined3d: declaration/FVF conversion test
On 6/19/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote: Does the windows box support shader model 3.0 ? The reason I keep asking about this is that MSDN talks about a ' pre-3.0' driver and a 3.0 driver, and I wanted to see if behavior was different. Just tested on my primary machine which has an NVidia 6600GT (Shader Model 3.0) in Windows XP, and got this: vertexdeclaration: 441 tests executed, 0 marked as todo, 0 failures. So, looks like we are good to go.
Re: wined3d: declaration/FVF conversion test
On 6/15/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote: Hi, I'm attaching test, which demonstrates incorrect behavior of SetFVF and SetVertexDeclaration. Windows converts one to the other and backwards (at least partially), and we do not such thing - this breaks at least 2 demos (dx9_hlsl_*) I'm posting it here, because: - I don't have Windows, and I need someone to try it on machine with pixel shader support (preferably 3.0, will need to enable pshaders and GLSL registry key). The whole first part of the test checks decl to fvf conversions, and they're almost all set to 0 in order to pass on H. Verbeet and V. Margolen's setups [ which have no pshaders ]. MSDN has a whole page on how to convert to an fvf, and the values there are definitely *not* 0, so that's why I'm suspicious. I just tested this on a Windows box that supports Shader model 2.0, and all tests came back positive without failures. So, now we need to clean up the test so it doesn't report twice the number of errors and get it applied. Then, we fix Wine. ;-) Jason
Re: wined3d: GLSL Patch feedback requested
On 6/13/06, H. Verbeet <[EMAIL PROTECTED]> wrote: On 13/06/06, Raphael <[EMAIL PROTECTED]> wrote: > I only have one question: > i see you have a cache to reuse prgid in set_glsl_shader_program but what > happens if user/app change the shaders content (for example using > SetFunction) ? your pre-compiled program will be correct ? > (because i don't see any list cleanup in shaders function reset) Good point :-) I wonder if respecifying the source and recompiling the program is worth it, or if we should just create a new shader object. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/IDirect3DPixelShader9.asp From what I can tell (for DX9 at least), the app shouldn't be able to use SetFunction(). I thought it was an internal wined3d function. Unless it's a DX8 call that I'm unaware of. I haven't seen any apps try to do that yet, but maybe I'm just not looking closely enough. :-) The apps tend to CreatePixelShader(), then later [often during the render loop], they SetPixelShader(). I haven't seen any that modify an existing shader yet.
Re: [WINED3D 2/9] Add the bulk of the GLSL string generation functions
On 6/9/06, H. Verbeet <[EMAIL PROTECTED]> wrote: Is making the distinction between rgba and xyzw really needed? xyzw / rgba / stpq should be equivalent and the distinction is mostly for readability if you know the variable type. However, since you can't decided that purely based on whether something is a vertex shader or a pixel shader, the way it's currently done might be misleading in some cases. That makes sense (and so does your comment about patch #9). Instead of rebuilding the patchset, though, I'll submit a small cleanup patch today as #10/9, as these patches aren't technically wrong. There's always a better way. ;-)
Re: wined3d: GLSL Patch feedback requested
By the way, here's a comparison screenshot of Civ4 from before my hard drive failed, and this is without having texturing on pixel shaders entirely working. Using GLSL (working completely for vertex shaders 2.0, at least the instructions that Civilization 4 used): http://cmhousing.net/wine/civ4_glsl.png compared to: http://cmhousing.net/wine/civ4_ingame2.png and http://cmhousing.net/wine/civ4_3.png with current git and using regular ARB shaders. So, we at least know that this is going to help. :-) On 6/8/06, Jason Green <[EMAIL PROTECTED]> wrote: The current cumulative patch is located here: http://cmhousing.net/wine/glsl_cumul.diff (This includes the recently submitted "Split constant loading out of drawPrim()" patch, which hasn't been applied to git yet) Before submitting, I plan to fix the following things: - Fix relative addressing (it was working correctly, then I lost some stuff when my hard drive got corrupted, and now it's using R0 instead of A0 as the address register for some reason) - Switch the shader_reg_maps.constantsF[] to a CHAR array instead of a BOOL array (maybe even a bitmap(?)) This whole patchset should be a no-op for normal users, unless they have the UseGLSL registry key enabled. Here's a list of the changelogs that this cumulative patch entails, somewhat in the order that I'll be sending them: [already sent] Move constant loading out of DrawPrimDrawStrided() - DrawPrim is just too big of a function. This separates the passing of constants to the shader into new functions. - Fixes an off-by-one error when loading vertex declaration constants (should be <, not <=) - Adds a function for GLSL loading of constants (aka Uniforms) - Adds a GLSL program variable to the stateblock and sets it to 0 (a future patch will actually create this program) Add GLSL helper functions to device.c - Adds functions to attach & detach shader objects, create and delete programs, and maintain the list of programs. - Adds a list of GLSL shader programs to the device which is initialized on Init3D(), and deleted on Release() Add the bulk of the GLSL string generation functions - Add a new file glsl_shader.c which contains almost every GLSL specific function we'll need - Move print_glsl_info() into glsl_shader.c - Move the shader_reg_maps struct info into the private header, and make it part of SHADER_OPCODE_ARG. - Create a new shared ps/vs register map for float constants (future patch will make ARB programs use this, too) - This is a big patch, but none of the new functions in glsl_shader.c are being called yet. This just sets them up. Unified float constant register mapping between ARB pixel and vertex shaders. - Got rid of the separate constant maps. - Side effect of this is that the map is a bit larger for pixel shaders than it needs to be. - Will make this dynamic in a future patch. Added more declarations to GLSL in generate_glsl_declarations() - Declare more variable names for GLSL programs. - Correct output name for pixel shaders (gl_FragColor instead of glFragColor) Map pixel shader instructions to GLSL generating functions. - Also, delete the GLSL program when the refcount hits 0 Map vertex shader instructions to GLSL generating functions. - Also, delete the GLSL program when the refcount hits 0 Allow drawPrim to create and use the GLSL program - Now that we can fully create a GLSL program, this patch lets us actually use it. I would have submitted these all separate for review, but I have some janitorial git cleanup to do first to get all of this in the right order.
wined3d: GLSL Patch feedback requested
The current cumulative patch is located here: http://cmhousing.net/wine/glsl_cumul.diff (This includes the recently submitted "Split constant loading out of drawPrim()" patch, which hasn't been applied to git yet) Before submitting, I plan to fix the following things: - Fix relative addressing (it was working correctly, then I lost some stuff when my hard drive got corrupted, and now it's using R0 instead of A0 as the address register for some reason) - Switch the shader_reg_maps.constantsF[] to a CHAR array instead of a BOOL array (maybe even a bitmap(?)) This whole patchset should be a no-op for normal users, unless they have the UseGLSL registry key enabled. Here's a list of the changelogs that this cumulative patch entails, somewhat in the order that I'll be sending them: [already sent] Move constant loading out of DrawPrimDrawStrided() - DrawPrim is just too big of a function. This separates the passing of constants to the shader into new functions. - Fixes an off-by-one error when loading vertex declaration constants (should be <, not <=) - Adds a function for GLSL loading of constants (aka Uniforms) - Adds a GLSL program variable to the stateblock and sets it to 0 (a future patch will actually create this program) Add GLSL helper functions to device.c - Adds functions to attach & detach shader objects, create and delete programs, and maintain the list of programs. - Adds a list of GLSL shader programs to the device which is initialized on Init3D(), and deleted on Release() Add the bulk of the GLSL string generation functions - Add a new file glsl_shader.c which contains almost every GLSL specific function we'll need - Move print_glsl_info() into glsl_shader.c - Move the shader_reg_maps struct info into the private header, and make it part of SHADER_OPCODE_ARG. - Create a new shared ps/vs register map for float constants (future patch will make ARB programs use this, too) - This is a big patch, but none of the new functions in glsl_shader.c are being called yet. This just sets them up. Unified float constant register mapping between ARB pixel and vertex shaders. - Got rid of the separate constant maps. - Side effect of this is that the map is a bit larger for pixel shaders than it needs to be. - Will make this dynamic in a future patch. Added more declarations to GLSL in generate_glsl_declarations() - Declare more variable names for GLSL programs. - Correct output name for pixel shaders (gl_FragColor instead of glFragColor) Map pixel shader instructions to GLSL generating functions. - Also, delete the GLSL program when the refcount hits 0 Map vertex shader instructions to GLSL generating functions. - Also, delete the GLSL program when the refcount hits 0 Allow drawPrim to create and use the GLSL program - Now that we can fully create a GLSL program, this patch lets us actually use it. I would have submitted these all separate for review, but I have some janitorial git cleanup to do first to get all of this in the right order.
Re: wined3d: Another GLSL shader status update
On 6/6/06, Jason Green <[EMAIL PROTECTED]> wrote: I'll add a section to the DirectX-Shaders wiki page with an explanation soon, as well as make the comments in the source code more verbose (and/or link to the wiki where applicable). FYI - I just added a bunch to this page to get us started: http://wiki.winehq.org/DirectX-Shaders
Re: wined3d: Another GLSL shader status update
On 6/6/06, Mike Hearn <[EMAIL PROTECTED]> wrote: On Sun, 04 Jun 2006 12:04:21 -0400, Jason Green wrote: Re: the recent discussion on code commenting and documentation, it'd be nice if the patch explained this somewhere. It'd be even nicer still if at some point one of you guys could take a break from the codeface and write a chapter for the Wine Developer Guide on shaders and how all this works Yep, that is all planned before I submit any of the new real work to wine-patches. I'm still trying to figure out exactly where some of this stuff needs to go and what pitfalls we'll be up against. Should make it easier for Alexandre so he doesn't have to apply 800 patches / month of us moving stuff around after the fact. :-) I'll add a section to the DirectX-Shaders wiki page with an explanation soon, as well as make the comments in the source code more verbose (and/or link to the wiki where applicable).
Re: wined3d: Another GLSL shader status update
On 6/4/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
+/* Declare textures samplers */
+for(i = 0; i < /*This->baseShader.limits.texture */ 4; i++) {
+//if (reg_maps->texcoord & (1 << i))
+shader_addline(buffer,"uniform sampler2D mytex%lu;\n", i);
+}
What's the problem here?
A lot of this is just from debugging. The code is still in the proof
of concept phase.
+if (wined3d_settings.shader_mode == SHADER_GLSL)
+shader_glsl_add_instruction_modifiers(&hw_arg);
If you choose to pull modifier handling out of the per-opcode function,
this should be done for SHADER_ARB as well, imho.
All of the ARB modifiers are run prior to the command. Whereas, (at
least so far), the GLSL instruction modifiers are necessary to run
after the command.
+for (i=0; i
Possibly introducing - nice catch.
+loadConstants(iface, GL_VERTEX_PROGRAM_ARB, constants,
NULL,
+
vshader->baseShader.limits.constant_float, programId, TRUE);
What's the purpose of the "skip_type_check" parameter - TRUE here.
Doesn't the current code only work for float constants anyway?
It's passing NULL as the type array (because VertexDeclaration
constants are always floats and they don't have one).
+/* Update the constants */
+loadConstants(iface, GL_FRAGMENT_PROGRAM_ARB,
This->stateBlock->pixelShaderConstantF,
+ This->stateBlock->pixelShaderConstantT,
pshader->baseShader.limits.constant_float,
+ programId, FALSE);
Those limits aren't checked against GL capabilities yet.
The current 3.0 limit is 224 float constants - does this work properly?
The limits should be checked against the caps in the functions that
set all of the limits based on the shader version. We should probably
do something like set all of the limits as they "should" be, then do a
min() against the GL caps.
+void shader_glsl_add_instruction_modifiers(SHADER_OPCODE_ARG* arg
Doesn't seem to handle multiple modifiers - I think I changed this
elsewhere recently.
Possibly not. I just haven't hit (or noticed) that test case yet.
+SHADER_PARAM_FCT_T param_fct;
Please don't add any more fields that do not need to persist into base
shader. Why are two different param functions needed?
This method avoids the base class having to know about its subclasses.
I'm sure there's a better way to do it, still, though.
+/* Set constants for the temporary argument */
I'm not sure I like how the mnxn functions use a temporary argument
structure and re-invoke the gen. functions. Do they initialize every
field necessary in the arg? I might have added new fields and missed the
initialization part in there - maybe this arg should be 0-ed first with
memcpy.
Agreed.
+GLhandleARB objList[4]; /* There should never be more than 2
objects attached
+ (one pixel shader and one vertex
shader), but we'll be safe */
This doesn't make sense to me - either you know that there are 2 objects
attached exactly, or you don't. In either case, it's wrong to cover up a
potential bug with a 4-element array.
Yeah, I must have been tired. :-)
+ * Note: The downside to this method is that we may end up compiling
and linking
+ * programs that will not be used. Linking is expensive, but it's
typically better to
+ * create more programs than necessary and just bind them when needed
than it is
+ * to create a new program every time you set the shaders
+ */
This is an elaborate scheme with linked lists in each shader - is that
really necessary?
I'm very confused after reading the code (but maybe that's just me :)
If we link the programs together every time the Set__Shader() is
called, it brings performance to a halt (that what my glsl_hack4.diff
did). Everything was roughly 100 times slower that way. So, this
method stores the program for every combination which is used in the
app. That way, when the shaders are set, we already have a linked
program to use. Linking is a very expensive operation. Keeping a
list of them seems like the best method that we could come up with.
If I call:
X = CreatePixelShader(dev);
Y = CreateVertexShader(dev);
Z = CreateVertexShader(dev);
SetPixelShader(dev, X);
SetVertexShader(dev, Y);
SetVertexShader(dev, Z);
How many programs are being created?
3
What objects are attached to each?
Program:Pixel Shader:Vertex Shader:
1 X NULL
2 X Y
3 X Z
Which linked lists does each program go into, and
What's the sequence of things being attached/detached, programs
created/destroyed?
If you run the WINEDEBUG=+d3d_shader trace, you'll get detailed
information about all of the steps involed. Currently, the only time
that the list doesn't get de-allocated is when the app doesn't
properly clean up after it
Re: wined3d: Another GLSL shader status update
On 6/3/06, Phil Costin <[EMAIL PROTECTED]> wrote: Hi Jason, Can you just clarify for my why you are changing the D3DVS_VERSION() and D3DPS_VERSION() to 3.0 for SHADER_ARB in the caps section of directx.c? Sorry, that snuck in. There are some 2.0 shaders that can be handled by ARB already, so I was just telling the app that it supported them as a test. That part shouldn't have been there. :-)
wined3d: Another GLSL shader status update
Well, I've fixed the speed issues with using GLSL (it's now just as fast as ARB shaders for the ones that actually work correctly) and gotten a few other things to work correctly. However, I'm still having issues with certain pixel/vertex shader combinations. Ohsix caught on that it may have to do with sampler limits on graphics cards and how sampling/textures are handled different in GLSL that with ARB. I'm not sure at the moment and could use some help. http://cmhousing.net/wine/glsl_hack6.diff is the diff against the most recent git tree. There are still some ugly hacks lying around in there. Note that I've separated out most of the GLSL functions into a new file "glsl_shader.c". Once again, to use GLSL instead of ARB shaders, you'll have to apply this patch, have a graphics card that's capable of GLSL, and add the following case senstive registry key: HKCU\Software\Wine\Direct3D\UseGLSL = "enabled" (String value)
Re: FW: RE: My 1.0 wish list
On 6/3/06, EA Durbin <[EMAIL PROTECTED]> wrote: This problem in MSI spans a multitude of bugs. ATI demo(Rendering With Natural Light ) - bug # 4712? I noticed yesterday that just about every ATI Demo had similar installer problems. Just try a few from here if you need some quick test cases: http://www.ati.com/developer/demos.html Thanks, and good luck!
wined3d: GLSL shader status
I'm working on the conversion from DirectX pixel and vertex shaders to GLSL function and have made a good bit of progress this weekend. At the moment, I'm able to run just about every simple vertex shader (version <= 1.4, and a few 2.0's) that I can find which already works on ARB_vertex_program (the current way that Wine handles this). I'm having a bit more trouble with pixel shaders, but I haven't really dug into it yet. Some of the really simple ones work, but I believe I'm missing a step in the texture binding code somewhere. I've posted a patch to enable this shader generation here: http://cmhousing.net/wine/glsl_hack4.diff If you want to try this and help debug things, you'll have to apply the patch (it's against the current git tree as of 2:00 AM EST, May 30th). Plus, you'll need a video card and driver capable of using GLSL (type 'glxinfo' and look for "GL_ARB_shading_language_100") . You'll also have to set a new registry key in your Wine installation (it is case sensitve): HKEY_CURRENT_USER\Software\Wine\Direct3D\UseGLSL = "enabled" Here are a few comparison screenshots (note, yes, they should be identical ;-): http://www.cmhousing.net/wine/aniso_arb.png (vanilla wine, or with UseGLSL != "enabled") http://www.cmhousing.net/wine/aniso_glsl.png (using GLSL) http://www.cmhousing.net/wine/grass_arb.png http://www.cmhousing.net/wine/grass_glsl.png http://www.cmhousing.net/wine/dolphin2_glsl.png (DX8 SDK dolphin sample) http://www.cmhousing.net/wine/civ4_glsl.png (not *quite* there yet ;-) In theory, once this all works, we'll be able to support shader model 2.0+, which a lot of newer games either require or strongly suggest (aka prettier graphics). Now, there are plenty of other bugs to be worked out in wined3d, so this isn't the holy grail of patches or anything, but it will take us that much closer to supporting new games. Please lend a hand if you're able to. Thanks! (by the way, many thanks to the entire #winehackers crew for all the help along the way so far, it's been fun)
Re: WineD3D: dynamicly load GL_ARB_multitexture functions
On 5/25/06, Roderick Colenbrander <[EMAIL PROTECTED]> wrote: This patch will dynamicly load the needed GL_ARB_multitexture functions, adds the needed function prototypes and defines to wined3d_gl.h and gets rid of a GL_VERSION compile check. The patch also removes a few lines of code in drawprim.c. The piece of code checked for the presence of GL_ARB_multitexture and if it wasn't supported it called GLMULTITEXCOORD4F (which is only available if GL_ARB_multitexture is available) and then continued. Further in that function GLCLIENTACTIVETEXTURE (which is part of the extension too) before we checked if the extension was available. This patch causes a pretty major regression in quite a few apps. Civilization 4 just flashes a lot and loses most of what few textures that did work previously. ;-) Program #16 here: http://www.zanir.szm.sk/dx10-19.html - It didn't work fully correct before, but it's worse now. All of the text is gone. Possibly more, time for bed, though. Jason
WineD3D patches for review and discussion - not to be applied as-is.
All of these apply to the latest Git tree, and should come after my
last patch submission to wine-patches, but it shouldn't matter. I'm
just looking for a little more feedback on these before I submit.
This should lay the groundwork to begin implementing GLSL opcode
generation. I've hacked around with some of them, and this will
succesfully generate a GLSL shader program if the opcodes are
implemented properly.
Please let me know if any of my ideas here are fundamentally flawed.
We've worked a bunch of it out on IRC, but this should be a nicer
version to look at than my stuff at pastebin. :-)
None of this code changes anything for the end-result
ARB_vertex/fragment_program. It only generates GLSL if you have this
regkey:
HKLU\Software\Wine\Direct3D\UseGLSL = "enabled"
>From nobody Mon Sep 17 00:00:00 2001
From: Jason Green <[EMAIL PROTECTED]>
Date: Fri, 26 May 2006 01:04:37 -0400
To: wine-patches <[EMAIL PROTECTED]>
Subject: [PATCH 1/5] Add ability to generate GLSL shader objects for vertex and
pixel shaders.
- Also modifies the baseshader declarations, and a few minor trace/formatting
cleanups.
---
dlls/wined3d/baseshader.c | 26 ++
dlls/wined3d/pixelshader.c | 25 +++--
dlls/wined3d/vertexshader.c | 31 +--
3 files changed, 74 insertions(+), 8 deletions(-)
77c5f0e5fc62b66943b762730d927ee2553ef842
diff --git a/dlls/wined3d/baseshader.c b/dlls/wined3d/baseshader.c
index 4e30421..cba12f5 100644
--- a/dlls/wined3d/baseshader.c
+++ b/dlls/wined3d/baseshader.c
@@ -549,8 +549,28 @@ void generate_glsl_declarations(
shader_reg_maps* reg_maps,
SHADER_BUFFER* buffer) {
+IWineD3DBaseShaderImpl* This = (IWineD3DBaseShaderImpl*) iface;
+int i;
+
FIXME("GLSL not fully implemented yet.\n");
+/* Declare the constants (aka uniforms) */
+shader_addline(buffer, "uniform vec4 C[%u];\n",
This->baseShader.limits.constant_float);
+
+/* Declare address variables */
+for (i = 0; i < This->baseShader.limits.address; i++) {
+if (reg_maps->address & (1 << i))
+shader_addline(buffer, "ivec4 A%ld;\n", i);
+}
+
+/* Declare temporary variables */
+for(i = 0; i < This->baseShader.limits.temporary; i++) {
+if (reg_maps->temporary & (1 << i))
+shader_addline(buffer, "vec4 R%lu;\n", i);
+}
+
+/* Start the main program */
+shader_addline(buffer, "void main() {\n");
}
/** Shared code in order to generate the bulk of the shader string.
@@ -585,7 +605,6 @@ void generate_base_shader(
/* Pre-declare registers */
if (wined3d_settings.shader_mode == SHADER_GLSL) {
generate_glsl_declarations(iface, ®_maps, buffer);
-shader_addline(buffer, "void main() {\n");
} else {
generate_arb_declarations(iface, ®_maps, buffer);
}
@@ -680,8 +699,7 @@ void generate_base_shader(
/** Prints the GLSL info log which will contain error messages if they exist */
void print_glsl_info_log(
WineD3D_GL_Info *gl_info,
-GLhandleARB obj)
-{
+GLhandleARB obj) {
int infologLength = 0;
char *infoLog;
@@ -693,7 +711,7 @@ void print_glsl_info_log(
{
infoLog = (char *)HeapAlloc(GetProcessHeap(), 0, infologLength);
GL_EXTCALL(glGetInfoLogARB(obj, infologLength, NULL, infoLog));
-FIXME("Error received from GLSL shader #%u: %s", obj,
debugstr_a(infoLog));
+FIXME("Error received from GLSL shader #%u: %s\n", obj,
debugstr_a(infoLog));
HeapFree(GetProcessHeap(), 0, infoLog);
}
}
diff --git a/dlls/wined3d/pixelshader.c b/dlls/wined3d/pixelshader.c
index be4fbb8..5720ea0 100644
--- a/dlls/wined3d/pixelshader.c
+++ b/dlls/wined3d/pixelshader.c
@@ -1298,8 +1298,29 @@ #endif
buffer.bsize = 0;
buffer.lineNo = 0;
-/* TODO: Optionally, generate the GLSL shader instead */
-if (GL_SUPPORT(ARB_VERTEX_PROGRAM)) {
+if (wined3d_settings.shader_mode == SHADER_GLSL) {
+
+/* Create the hw GLSL shader object and assign it as the
baseShader.prgId */
+GLhandleARB shader_obj =
GL_EXTCALL(glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB));
+int success_flag = 0;
+
+/* Generate the bulk of the shader code */
+generate_base_shader( (IWineD3DBaseShader*) This, &buffer, pFunction);
+
+shader_addline(&buffer, "}\n\0");
+
+TRACE("Compiling shader object %u\n", shader_obj);
+GL_EXTCALL(glShaderSourceARB(shader_obj, 1, (const
char**)&buffer.buffer, NULL));
+GL_EXTCALL(glCompileShaderARB(shader_obj));
+GL_EXTCALL(glGetObjectParameterivARB(shader_obj,
+ GL_OBJECT_COMPILE_STATUS_ARB, &success_flag));
+if (success_flag == FALSE) /* Print a
Re: wined3d: Allow vertex shaders to generate GLSL shaders [Take Two]
On 5/18/06, H. Verbeet <[EMAIL PROTECTED]> wrote: On 18/05/06, Jason Green <[EMAIL PROTECTED]> wrote: +/* We will check for errors later when we try to use the program */ Lets not do that. Assuming you're talking about inside drawPrimitiveDrawStrided, that's going to kill performance. What is the problem with checking for errors right after compilation? The error wasn't being generated from GL using checkGLcall() until I called glUseProgramObjectARB() (equivalent to glBindProgramARB()). If there is an error, we need to use glGetInfoLogARB() to get the detailed error message. Up until that point, none of the other functions (Source, Compile, Attach, Link) return any type of error from checkGLcall(). But, I've got glGetObjectParameterivARB() working now to return the error code before glUseProgramObjectARB(), so I will resubmit the whole patchset soon with the changes. Thanks.
Re: wined3d: Allow vertex shaders to generate GLSL shaders
On 5/18/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote: > +/* Create the uniforms (aka constants) */ > +shader_addline(&buffer, "uniform vec4 C[%u];\n", This->baseShader.limits.constant_float); > +/* TODO - Add varyings, attributes, etc. */ > + Shouldn't this go into the "generate_glsl_declarations" thing into baseshader? Things previously merged into baseshader should stay that way, imho... Yep, per our IRC conversation, please disregard this patch for now. One more merge is needed in baseshader.c instead. I'll submit that shortly, then modify this patch.
Re: [WINED3D 13/13] Further split GLSL & ARB_v/f_program generation and allow GLSL functions to be called.
On 5/10/06, H. Verbeet <[EMAIL PROTECTED]> wrote: I think it would be best not to have USING_GLSL checks at several different places in the code. The function signatures are the same, so it wouldn't be that hard to just pass a pointer to the correct function. True, it could be combined better in that function. I'll be on vacation for about a week, but I'll further clean that up when I get back. FYI - I placed the USING_GLSL define in wined3d_private.h because it will also be needed in other placed in wined3d as well. At a minimum, we will also need it in drawprim.c - drawPrimitiveDrawStrided() where it sets the constants. I have a patch that does that currently, but it's too ugly to submit yet.
Re: Wine installation on Ubuntu Dapper
On 5/9/06, Marco Eminente <[EMAIL PROTECTED]> wrote: Thanks to suggestions from Vitaliy Margolen, Neil Skrypuch and Scott Ritchie I downloaded and manually installed 32 bit libraries I've found that the only truly clean way to build Wine in Ubuntu AMD64 is to use a chroot environment. Google on ubuntuforms.org for details on how to set that up. The biggest benefit of that method (besides the fact that it "just works" [eventually]) is that you can keep up to date with security updates for your 32-bit packages. The way you're doing it manually, you are now responsible for updating your 32-bit libs each time there is a security update. Whereas, with a chroot, you can just run "sudo apt-get update && sudo apt-get upgrade". It would be really nice if Ubuntu had a pre-packaged Wine[-dev] environment for 64-bit systems (which would include all of the necessary 32-bit libs placed in the correct locations), but no one has taken the effort yet AFAIK. When I was trying to compile the manual way like you are, I had some issues with Wine's configure script pointing to the wrong libraries in a few places. It was looking in /usr/lib by default, when it needed to look in /usr/lib32 in order to actually work. At that time, however, I didn't know enough about Wine to do much about it besides manually editing my Makefiles each time I ran ./configure. Good luck, though, and if you get it all down, please post a HOWTO on the Wine wiki. Thanks!
Re: D3D Pixel/Vertex shader discussion (for shader model 2.0+)
On 5/8/06, Aric Cyr <[EMAIL PROTECTED]> wrote: Out of curiosity, is anyone working on a HLSL->GLSL compiler? This seems like a large, non-trivial part of shader model 3 that would be required for Wine to properly implement HLSL. At the moment, the d3d9x_##.dll files are shipped with games and those dlls convert the HLSL shaders to bytecode which we use for parsing (I think - I might be wrong about where exactly the bytecode comes from, but that's what we are using at the moment to generate shaders). Ideally, we could write our own d3d9x_## dlls to intercept the HLSL before it becomes bytecode and then perform some conversion to GLSL, but at the moment it's not needed. AFAIK, no one has done any more than talk about this type of project so far. Current status on the implementing GLSL from the bytecode: - I have some very hacked-up code working which has successfully run a 2-line DX shader using GLSL (no, I won't submit anything yet - it's that embarrasingly bad ;-) At least I now know that it'll work. - Once all of the patches that were submitted during Alexandre's vacation make it into the master git repo, I'll get the framework submitted for implementing each DX shader opcode in GLSL. There were a couple of patches sent that were rejected, and most of the patches afterwards depended on those, so nothing is applying cleanly. That part should be resolved in the next few days [hopefully]. Jason
Re: [WINED3D 8/8] Add TRACE output of full shader strings for both pixel and vertex shaders
On 5/5/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote: I think we should do the opposite, and get rid of the one that's already there. The shader output is already produced once by the addline traces, and they're better because (1) they have proper trace prefix, and (2) they show you the line number and byte offset. You can use sed and grep to get only those lines, or better, remove any useless tracing such as printing out individual tokens as they're parsed [ then the shader_addlines would come nicely in a sequence ]. After discussion, I agree. Please discard this patch.
Re: [WINED3D 1/8] Place number of textures/addresses and temps used inside the baseShader struct to prepare for merging of GenerateShader routine.
On 5/5/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote: Merging things between pixel and vertex shaders is the right idea, but we need to think about supporting multiple output targets as well - arbfp/arbvp vs glsl. Any shader_addline() being called is output target specific. Yes, you are correct, and I'm already working on a patch to address this. However, I think this patch should still be applied as-is, since it doesn't break anything currently and is organized so as to make this separation easy in the [very near] future.
Re: D3D Pixel/Vertex shader discussion (for shader model 2.0+)
On 5/4/06, Raphael <[EMAIL PROTECTED]> wrote: Only one "technical thing", how you expect to determin if you need GLSL or if ARB_vertex/ARG_fragment is suffcient ? 1 - always use GLSL when available, else try ARB compat code ? 2 - try to use ARB when possible, else switch to GLSL ? 3 - choose the more performant (heuristic depency of opcodes performances) ? In general, any shader version 2.0 or higher will require GLSL. There are exceptions, but that's the general rule of thumb. So, unless the performance is seriously impacted, we should use GLSL if possible. Also, I'm not sure of the ramifications of using both GLSL shaders and ARB_vertex_program shaders at the same time... Haven't got that far yet, but it's a good question to look into. Phil Costin has already submitted a patch which is in Mike's tree which checks for the existence of the ARB_shader_100 extension (whatever it's called) which allows us to use GLSL shaders. And why about specifics NV/ATI extensions for shaders ? Hopefully we won't need them for shaders as there is already an ARB_ extension that should be usable by both vendors. But, if it turns out that we do need one or the other, then it will have to be an if () else type of scenario.
D3D Pixel/Vertex shader discussion (for shader model 2.0+)
Quite a few of us in #winehackers have been discussing and working on pixel and vertex shaders for the last month or so. However, due to time zone differences, we don't always get to participate in the discussions, so it's tough to keep track of who's doing what and what the real game plan is. So, I've started a rough draft of our roadmap for GLSL implementation here: http://wiki.winehq.org/DirectX-Shaders If you've been part of these shader discussions recently or even have at least a vague understanding of how this stuff works in wined3d, please take a look at that page and make any modifications as you see fit. I plan on working on (and hopefully finishing) the GenerateShader() merge mentioned on that page tonight or tomorrow. With luck, we can begin implementing GLSL very soon and supporting the shaders correctly on newer DirectX games.
Re: wined3d: move traces into D3DFmtMakeGlCfg and fix FIXME for depth/stencil buffer "not found"
On 4/13/06, Christoph Frick <[EMAIL PROTECTED]> wrote: > License: LGPL > ChangeLog: > 2006-04-12 Christoph Frick <[EMAIL PROTECTED]> >* dlls/wined3d/device.c >move traces into D3DFmtMakeGlCfg and fix FIXME for depth/stencil >buffer "not found" Part of this is already in my patch from yesterday that has been applied to the latest git/cvs (the FIXME update). But, the TRACE's could still be useful.
Re: [WINED3D] Map D3DFMT_L16, D3DFMT_A16B16G16R16 to OpenGL formats
On 4/10/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote: > Map: > > D3DFMT_L16 -> GL_LUMINANCE16_EXT > D3DFMT_A16B16G16R16 -> GL_RGBA16_EXT > as Raphael suggested. Assuming this mapping is correct, you should also add these formats here: http://source.winehq.org/git/?p=wine.git;a=blob;h=056c6fb76dd770c03655b7973f86113eb4284ffd;hb=eb834b39fa3c24b1531ca1f53a666040f3769009;f=dlls/wined3d/directx.c#l1122 (though, that whole part of the file could use some work) And, possibly here: http://source.winehq.org/git/?p=wine.git;a=blob;h=f1868cdb3de16e9bb49f11706192648637b06bcd;hb=eb834b39fa3c24b1531ca1f53a666040f3769009;f=dlls/wined3d/surface.c#l787
Re: d3d: unhandled texture formats
On 4/4/06, Raphael <[EMAIL PROTECTED]> wrote: > On Tuesday 04 April 2006 12:48, Ivan Gyurdiev wrote: > > The F.E.A.R and BF2 demos crash immediately after complaining about: > > fixme:d3d:D3DFmtGetBpp Unhandled fmt(36,WINED3DFMT_A16B16G16R16) > > fixme:d3d:debug_d3dformat Unrecognized 81 D3DFORMAT! > > Just fix it :) > > > I have some native dlls installed, d3dx9_*.dll, mscoree.dll... that have > > no wine implementation. > > yes, no problem. > > > According to msdn: > > D3DFMT_A16B16G16R16 36 64-bit pixel format using 16 bits for each > > component. > use GL_RGBA16_EXT for that (GL format is GL_RGBA,GL_UNSIGNED_SHORT) > > D3DFMT_L16 81 16-bit luminance only. > use GL_LUMINANCE16_EXT for that (GL format is GL_LUMINANCE,GL_UNSIGNED_BYTE) On this topic, how about floating point formats such as D3DFMT_A16B16G16R16F? I have an app that checks for a lot of missing float formats. It keeps running even though that function returns false, but there are tons of graphical bugs. There's a comment in the code about having to do some card-specific stuff to support this in OpenGL (NV vs. ATI extensions). I tried adding those formats in, but just mapping the individual float colors over to one of the unsigned int formats (thinking that even if the colors are wrong, they should still show up as *something* instead of black). However, I didn't notice any difference in the output. Eventually wine should support these formats obviously, but is there a simpler test app out there that could display surfaces/textures/whatever in each color format and see which ones work or fail? Civ4 takes a minute just to load, and another 30 seconds to get into the game portion that fails, so it's not the ideal test app. :)
Re: Wined3d/OpenGL question
On 4/4/06, H. Verbeet <[EMAIL PROTECTED]> wrote:
> I think the first thing you should do, is to verify that it's the call
> to glDrawElements() that's generating the errors. glGetError just
> check if an error flag is set, but if an error flag is set it doesn't
> neccesarily mean the call right before glGetError generated that
> error. The easiest way to do this would probably be to call glGetError
> *before* the call to glDrawElements and verify that it return 0 /
> GL_NO_ERROR.
>
Well, added that call just before the glDrawElements() call, and it
returns "call ok". So, I tried Jame's suggestion that it was stuck
inside of a glBegin()/glEnd() call... It didn't look like it in the
source, but to be sure, I put an extra glEnd() in the code under
certain circumstances [cleaned up and stripped of #ifdefs]:
checkGLcall("before glDrawElements");
/* This particular # of vertices w/ GL_TRIANGLES is on that is
failing, so check for it */
if (glPrimitiveType == 4 && numberOfVertices == 6144)
{
glEnd();
checkGLcall("glEnd()");
}
if (idxData != NULL /* This crashes sometimes!*/) {
TRACE("(%p) : glElements(%x, %d, %ld, ...)\n", This,
glPrimitiveType, numberOfVertices, minIndex);
idxData = idxData == (void *)-1 ? NULL : idxData;
...
glDrawElements(glPrimitiveType, numberOfVertices, idxSize == 2
? GL_UNSIGNED_SHORT : GL_UNSIGNED_INT,
(const char *)idxData+(idxSize * startIdx));
checkGLcall("glDrawRangeElements");
}
Here's the output:
trace:d3d_draw:drawStridedFast before glDrawElements call ok drawprim.c / 1226
fixme:d3d_draw:drawStridedFast > 502 from glEnd() @
drawprim.c / 1230
trace:d3d_draw:drawStridedFast (0x7fd8d1e8) : glElements(4, 6144, 0, ...)
fixme:d3d_draw:drawStridedFast > 502 from
glDrawRangeElements @ drawprim.c / 1248
I also did another check later to verify that idxData != NULL. All I
can figure is that the data in idxData is somehow not matching up with
the data that OpenGL is looking for... or the calculated # of
vertices or indices is somehow wrong? I really don't know past this
point, but am willing to keep plugging away. Any further ideas are
welcome.
Thanks
Wined3d/OpenGL question
I may be barking up the wrong tree here, but I'm trying to debug the cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in drawprim.c (line 1251). This is for Civilization 4 using both hardware vertex & pixel shaders. I've only noticed this error when it is passed GL_TRIANGLES with a large number of vertices. Here's a sample output with a little extra debugging info, and cleaned up a little: trace:d3d_draw:primitiveToGl TRIANGLES trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144, number of vertices1156 trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144, number of vertices1156 ... trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader trace:d3d_draw:drawPrimitiveDrawStrided glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok drawprim.c / 1846 trace:d3d_draw:drawPrimitiveDrawStrided glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850 trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...) fixme:d3d_draw:drawStridedFast > 502 from glDrawRangeElements @ drawprim.c / 1251 Often, a series of these errors will result in an unhandled exception in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1 kernel). I read up on the glDrawElements() function and it refered to the GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES. When I call that function, it returns 4096, and the number of vertices that it's trying to pass is larger than that. I've tried doing a min() of the max and the actual # of vertices, but the results are the same. So, the question is: Could this be one of the causes of the graphical glitches I'm seeing? I can toy around with these functions all day, but I don't really understand them all that well. Does that routine need to be reworked to split up a D3DPT_TRIANGLELIST into multiple calls if the calculated number of vertices/indices is too high for the user's graphics card? Or, am I way off base thinking this has any bearing on my real issues? Thanks, Jason
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
On 3/29/06, Dr J A Gow <[EMAIL PROTECTED]> wrote: > I was interested to read several comments on this list in respect of such > comments as 'IQ of zero'. Such comments were the final straw in leading me to > take this action. Thank you. It sometimes takes a thick skin to ignore the petty and childish rants that are prevalent online. Anonymity (or pseudo-anonymity in this case) often leads to childishness, and has done so since the beginnings of the Net. It gives the impression to potential new users and developers that the "community" is hostile and unwelcoming. I experienced a little bit of myself when asking my first couple of [naive] questions in IRC at #winehq. While it's completely understandable that people will get tired of seeing the same questions posted over and over again, there's no need to get hostile about it unless the user asking the questions gets hostile or demanding themselves (and even then, restraint or kick/ban would be preferable). If someone asks a "stupid question" (entirely subjective, remember), just ignore it or point to a place where they can learn the answer themselves. Please don't be a jerk. Thanks.
Re: I have a complaint about the website
On 3/27/06, Segin <[EMAIL PROTECTED]> wrote: > Due to the current state of Wine, plus it's archjitechure, Even if a > virus was found, it is much easier to remove. > > If the virus is a memory-resident kind, you can do pkill -9 wine as root > or your user and shut down ile essentially killing said virus. > > A lot of viruses, in order to keep small, attempt to make fnction calls > based on a DLL function absolute address. This has a 1 in 256 million > cnahce in working, because each time you recodmile wine, the function > entry points change. all that aill result in is a segmentation fault. I agree that running viruses are much more difficult in Wine than in Windows, however, by default, Wine maps Z:\ to your entire Linux tree. If the user running Wine has write-access to any other folders in the Linux system tree and runs a virus which randomly deletes or modifies files on any accessible drive letter, that is still a problem. Plus, some users don't use "rm -rf .wine/" on a daily basis like most devs do, and they may actually store useful things under their .wine/ folder. In the (albeit, unlikely) event of "succesfully" running a Windows virus, those files are at risk. There are plenty of distros that install some version of Wine by default and automatically associate .exe's and the like with Wine, so users that aren't careful are still at risk. Granted, that risk is minimized by not being fully compatible with everything Windows does [yet], but it's still a risk.
Re: May be a bad idea to have Winetools in the next SUSE release
On 3/11/06, Tony Lambregts <[EMAIL PROTECTED]> wrote: > In simple terms we get WineTools to query the AppDB with an application name > (ie > somename.exe) and we return a list of applications for the user to choose from > and the after the user selects the program WineTools gets the appropriate > overrides from the AppDB and sets them for the user. > > I think that that this is do-able if we work together. First, great idea. Second, here's a [very incomplete] list of what would need to be done to pull this off: - AppDB would have to be extended to be able to get and report this data, and it would make sense for each App's maintainer to be able to manage that information. - Biggest issue here is that this information could have a tendency to change very rapidly, so it might overload the app maintainers if they had to track this for each version of wine. What I think would make sense is to have regular snapshots (every 3 months?) and release a new version of "Winetools Plus" or whatever you want to call this thing a month later to give the maintainers time to update each of their apps based on the frozen version. - Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL Overrides, Window settings (fullscreen/windowed - sometimes and issue), Sound options, Video acceleration required, General notes or HOWTO's, etc. You would need separate overrides/settings for Installing vs. Running the app. - AppDB could dump this information to an xml format which "Winetools Plus" could be distributed with. Maybe have an option to download the latest xml file directly from winehq.org. - The 'Winetools Plus' front-end would just be a menu which would query all of the apps in the xml dump. The user picks they app they want to install, and it reads the necessary information, verifies the source installation media, and goes at it. - Applying patches to apps might get tricky (e.g., where wine only successfully runs version 1.5 of the app, but 1.0 is on the CD), but I'm sure it could be worked out. Anyway, there's a start. That would encourage users to get involved in the AppDB reporting process as well as better organize how to just "get things done" using wine. My 2 cents. Jason
Re: AlphaImageLoader - tranparent pngs 4 IE
On 3/8/06, Axel Huizinga <[EMAIL PROTECTED]> wrote: > Did anybody get DXImageTransform.AlphaImageLoader working > to render transparent png in IE on wine? If I recall correctly, transparent .PNG's don't even work in IE on Windows (at least until the upcoming IE7.0).
Fwd: Can't run DirectX games on x86_64 biarch Linux
On 3/8/06, Willie Sippel <[EMAIL PROTECTED]> wrote: > [...] > I also build Wine on an amd64 system (running gentoo/ amd64), no problems. But > there's one thing I noticed a while ago: Wine continues to compile and > install even if some of the DLLs won't compile. I had this a few times in the > past, and ended up with a basically working Wine install that missed a few > DLLs, mostly OpenGL-related stuff. Maybe something like that happens to you? > Just check that all DLLs are built and in place, and make sure there were no > errors during compile (like I said, with some DLLs, Wine just continues to > build even though errors appear)... Correct, wine will compile and run without a lot of features and never warn you that they don't exist. See this wiki page for an example of what your include/config.h file should probably look like: http://wiki.winehq.org/Recommended_Packages I just added the Fedora Core 5 and Ubuntu Dapper sections yesterday, and I believe that they are at least 95% accurate, although I might have missed one somewhere. If someone can add the package names required for a gentoo build (or possibly create and maintain wine-cvs packages with all of the necessary deps???), it would probably help out many users trying to compile from source.
x11drv: [PATCH] for X_SetClipRectangles clipping crash
While running Quickbooks Pro 99, WINE would crash every time I changed an existing transaction and clicked "Next" or "Prev", then answered Yes to save changes. It gave the following error: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 59 (X_SetClipRectangles) Serial number of failed request: 83724 [<--- that number changed every time] Current serial number in output stream: 87435 [<--- that number changed every time, too] (it also still gives quite a few of these errors elsewhere in the app, but I don't know if it's related): err:x11drv:X11DRV_CreateWindow invalid window height -2 The line it was crashing on was in x11drv/clipping.c: XSetClipRectangles( gdi_display, physDev->gc, physDev->org.x, physDev->org.y, (XRectangle *)data->Buffer, data->rdh.nCount, YXBanded ); After digging around a little, I found this Xlib programming manual entry: http://tronche.com/gui/x/xlib/GC/convenience-functions/XSetClipRectangles.html Here's what it has to say on the last argument about clipping rectangle sorting: "If known by the client, ordering relations on the rectangles can be specified with the ordering argument. This may provide faster operation by the server. If an incorrect ordering is specified, the X server may generate a BadMatch error, but it is not required to do so. If no error is generated, the graphics results are undefined. Unsorted means the rectangles are in arbitrary order. YSorted means that the rectangles are nondecreasing in their Y origin. YXSorted additionally constrains YSorted order in that all rectangles with an equal Y origin are nondecreasing in their X origin. YXBanded additionally constrains YXSorted by requiring that, for every possible Y scanline, all rectangles that include that scanline have an identical Y origins and Y extents." Changing that last parameter from YXBanded to Unsorted has completely resolved my problem, and it doesn't seem to have broken anything else that I've noticed (Firefox, Mozilla-suite, winefile all seem to run just as well as before). However, I'm sure you all know more than I do about how that particular function works. The code for that function hasn't changed at least since the 20031212 CVS. Either way, I'm submitting a small one-line patch. Please let me know if you think this will cause issues elsewhere. Thanks! Index: dlls/x11drv/clipping.c === RCS file: /home/wine/wine/dlls/x11drv/clipping.c,v retrieving revision 1.6 diff -u -r1.6 clipping.c --- dlls/x11drv/clipping.c 22 Dec 2004 17:16:03 - 1.6 +++ dlls/x11drv/clipping.c 17 Feb 2006 03:02:56 - @@ -119,7 +119,7 @@ wine_tsx11_lock(); XSetClipRectangles( gdi_display, physDev->gc, physDev->org.x, physDev->org.y, -(XRectangle *)data->Buffer, data->rdh.nCount, YXBanded ); +(XRectangle *)data->Buffer, data->rdh.nCount, Unsorted ); wine_tsx11_unlock(); HeapFree( GetProcessHeap(), 0, data ); }
