Re: wined3d: Fix trace output of emulated_textureram.

[Henri Verbeet]

On 31 August 2014 21:40, Johannes Brandstätter  wrote:
>              wined3d_settings.emulated_textureram =
>
> TmpVideoMemorySize *1024*1024;

It looks like your MUA wrapped the patch, I'd recommend using git
send-email for sending patches.
> -
>            TRACE("Use %iMB = %d byte for emulated_textureram\n",
> -
>            TRACE("Use %iMB = %u byte for emulated_textureram\n",
>                    TmpVideoMemorySize,
>                    wined3d_settings.emulated_textureram);

This change is ok, but note that for large values you'd want
"emulated_textureram" to be a UINT64. Currently it's going to wrap to
0 at 4 GiB.

wined3d: Fix trace output of emulated_textureram.

[Johannes Brandstätter]

On 01/09/14 12:54, Henri Verbeet wrote:
> On 31 August 2014 21:40, Johannes Brandstätter  wrote:
> >              wined3d_settings.emulated_textureram =
> >
> > TmpVideoMemorySize *1024*1024;
>
> It looks like your MUA wrapped the patch, I'd recommend using git
> send-email for sending patches.

Thanks for pointing that out, I will look into it.
Should I resend the patch afterwards?
> > -
> >            TRACE("Use %iMB = %d byte for emulated_textureram\n",
> > -
> >            TRACE("Use %iMB = %u byte for emulated_textureram\n",
> >                    TmpVideoMemorySize,
> >                    wined3d_settings.emulated_textureram);
>
> This change is ok, but note that for large values you'd want
> "emulated_textureram" to be a UINT64. Currently it's going to wrap to
> 0 at 4 GiB.

I did not know that, was just relying on the existing types. But this
raises the question if we want to change it, as 4GiB hardware is already
here right?

wined3d: Fix trace output of emulated_textureram.

[Henri Verbeet]

On 1 September 2014 13:52, Johannes Brandstätter  wrote:
> Thanks for pointing that out, I will look into it.
> Should I resend the patch afterwards?

Yeah, it won't apply like this.
> I did not know that, was just relying on the existing types. But this
> raises the question if we want to change it, as 4GiB hardware is already
> here right?

Yeah, it is. In principle there isn't much of a reason to set
VideoMemorySize to more than 4095 for 32-bit applications, and ideally
there wouldn't be a reason to set it at all, but we're probably
getting to the point where VideoMemorySize doesn't do what people
expect when they just fill in the amount of memory their hardware has.