On Sat, Jul 26, 2008 at 5:34 PM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/26 Allan Tong <[EMAIL PROTECTED]>:
>> You could try the attached hack patch to see if it fixes the problem
>> you're seeing. It completely ignores FBO cleanup, but it should avoid
>> the driver bug.
>>
> It's not *that
2008/7/26 Allan Tong <[EMAIL PROTECTED]>:
> You could try the attached hack patch to see if it fixes the problem
> you're seeing. It completely ignores FBO cleanup, but it should avoid
> the driver bug.
>
It's not *that* easy. You'll need to adjust the code in
apply_fbo_state() as well. fbo_color_
On Sat, Jul 26, 2008 at 3:39 PM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/26 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> So if we need to create an fbo for each thread, does that mean that
>> everything needs to be rebound to it on the context switch?
>>
> It would mostly mean that apply_fbo_sta
2008/7/26 Vitaliy Margolen <[EMAIL PROTECTED]>:
> So if we need to create an fbo for each thread, does that mean that
> everything needs to be rebound to it on the context switch?
>
It would mostly mean that apply_fbo_state() would need to track things
per-context rather than per-device. I guess th
Allan Tong wrote:
> On Sat, Jul 26, 2008 at 1:48 AM, H. Verbeet <[EMAIL PROTECTED]> wrote:
>> 2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
>>> So it seems the FBOs are created in one thread used there, then
>>> rebounding in the new thread leads to the crash.
>>>
>>> Any ideas how to fix this? O
On Sat, Jul 26, 2008 at 1:48 AM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> So it seems the FBOs are created in one thread used there, then
>> rebounding in the new thread leads to the crash.
>>
>> Any ideas how to fix this? Or what to try?
>>
> AFAIK
2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
> Ok I think I see the problem:
> 0045:trace:d3d_surface:surface_load_ds_location before bind_fbo
> 0045:trace:d3d:bind_fbo 0x14f474 -> 0
> 0045:trace:d3d:bind_fbo glGenFramebuffersEXT() -> 2 @
> ../../../wine.git/dlls/wined3d/device.c:6084 call ok
>
H. Verbeet wrote:
> 2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> BTW this is a driver crash in libglcore.so with what appears to be a
>> null-pointer dereference. I'm trying to play with your code to see how to
>> "fix" it.
>>
> Thanks.
Ok I think I see the problem:
0045:trace:d3d_surface:su
2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
> BTW this is a driver crash in libglcore.so with what appears to be a
> null-pointer dereference. I'm trying to play with your code to see how to
> "fix" it.
>
Thanks.
Vitaliy Margolen wrote:
> H. Verbeet wrote:
>> 2008/7/24 Vitaliy Margolen <[EMAIL PROTECTED]>:
> side affects. But the full version of Psychonauts crashes after initial
> videos. Same as it did when we had problems with multi-threaded games.
>
Is that a regression introduced by the
H. Verbeet wrote:
> 2008/7/24 Vitaliy Margolen <[EMAIL PROTECTED]>:
side affects. But the full version of Psychonauts crashes after initial
videos. Same as it did when we had problems with multi-threaded games.
>>> Is that a regression introduced by the patch?
>> Yes. Without the pat
H. Verbeet wrote:
> 2008/7/24 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> side affects. But the full version of Psychonauts crashes after initial
>> videos. Same as it did when we had problems with multi-threaded games.
>>
> Is that a regression introduced by the patch?
Yes. Without the patch everyth
2008/7/24 Vitaliy Margolen <[EMAIL PROTECTED]>:
> side affects. But the full version of Psychonauts crashes after initial
> videos. Same as it did when we had problems with multi-threaded games.
>
Is that a regression introduced by the patch?
H. Verbeet wrote:
> 2008/7/24 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> I've been trying to track some of the errors that I get with different
>> games. To do that I've added some extra traces and this is what I see:
>>
>> fixme:d3d_surface:read_from_framebuffer_texture glReadBuffer(0x405) was
>> 0x
On Wednesday 23 July 2008 03:56:14 pm Vitaliy Margolen wrote:
> +#define checkGLcall(A...) \
AFAIK, this valid C. It's a GNU extension. This:
#define checkGLcall(...)
TRACE(__VA_ARGS__);
is valid C, but requires C99.
> + TRACE(A);
2008/7/24 Vitaliy Margolen <[EMAIL PROTECTED]>:
> I've been trying to track some of the errors that I get with different
> games. To do that I've added some extra traces and this is what I see:
>
> fixme:d3d_surface:read_from_framebuffer_texture glReadBuffer(0x405) was
> 0x8ce0 > GL
I've been trying to track some of the errors that I get with different
games. To do that I've added some extra traces and this is what I see:
fixme:d3d_surface:read_from_framebuffer_texture glReadBuffer(0x405) was
0x8ce0 > GL_INVALID_ENUM (0x500) @
../../../wine.git/dlls/wined3
17 matches
Mail list logo
