Hi Derek,
Am 31.10.24 um 11:05 schrieb Derek Lesho:
Hi Christian,
Thanks for exploring this option, it's great to have a better
understanding of the capabilities/limits of mremap.
First, a few practical questions:
- How would Wine detect the updated mremap, I suppose we would want to
creat
Hi Christian,
Thanks for exploring this option, it's great to have a better
understanding of the capabilities/limits of mremap.
First, a few practical questions:
- How would Wine detect the updated mremap, I suppose we would want to
create a test persistent mapping on init and see if mremap
Hi guys,
so I looked a bit deeper into the problem of duplicating graphics driver
mappings with mremap().
This use case of duplicating a mapping into a fixed address is already
supported quite well using mremap(). This is used by a couple of
different emulators to re-create the address space
> On Oct 24, 2024, at 1:04 AM, Derek Lesho wrote:
>
> In my last mail I responded to this approach all the way at the bottom, so
> it probably got lost: mremap on Linux as it exists now won't work as it only
> supports private anonymous mappings (in conjunction with MREMAP_DONTUNMAP),
> which
Wait, apparently this was fully merged in kernel 5.13? The man page is simply
out of date.
https://github.com/torvalds/linux/commit/a4609387859f0281951f5e476d9f76d7fb9ab321
~Theodore
> On Oct 24, 2024, at 9:37 AM, tbl...@icloud.com wrote:
>
>
>>> On Oct 24, 2024, at 1:04 AM, Derek Lesho wro
Darek we are unfortunately both partially right.
Linux supports cloning VMAs using mremap() from userspace by using a
zero old size, but unfortunately only for SHM areas.
See the code in mm/mremap.c:
/*
* We allow a zero old-len as a special case
* for DOS-emu "duplic
Oh interesting, thanks for looking into this guys. As far as I
understand it though, this is still not duplicating the mapping, but
setting up a fault handler at the original address to manage access. I
don't think we'd want this since when wine remaps the page/s hosting a
given buffer it also
I haven't tested it but as far as I know that isn't correct.
As far as I know you can map the same VMA at a different location even
without MREMAP_DONTUNMAP. And yes MREMAP_DONTUNMAP only work with
private mappings, but that isn't needed here.
Give me a moment to test this.
Regards,
Christia
Is there a way for drivers to change the semantics of memory mappings to
make mremap work?
Marek
On Thu, Oct 24, 2024, 07:08 Derek Lesho wrote:
> In my last mail I responded to this approach all the way at the bottom,
> so it probably got lost: mremap on Linux as it exists now won't work as
> i
In my last mail I responded to this approach all the way at the bottom,
so it probably got lost: mremap on Linux as it exists now won't work as
it only supports private anonymous mappings (in conjunction with
MREMAP_DONTUNMAP), which GPU mappings are not.
Am 10/24/24 um 01:06 schrieb James Jon
That makes sense. Reading the man page myself, it does seem like:
-If the drivers can guarantee they set MAP_SHARED when creating their
initial mapping.
-If WINE is fine rounding down to page boundaries to deal with mappings
of suballocations and either using some lookup structure to avoid
d
I haven't read through the whole mail thread, but if you manage the
address space using mmap() then you always run into this issue.
If you manage the whole 4GiB address space by Wine then you never run
into this issue. You would just allocate some address range internally
and mremap() into tha
On 10/22/24 18:03, Derek Lesho wrote:
Am 10/21/24 um 11:35 schrieb Michel Dänzer:
And Wine's solution for this can't be implemented in Mesa?
I think this might actually be possible: In order to accomplish this
Wine essentially keeps calling mmaps with addresses in its range until
it finds
Am 10/21/24 um 11:35 schrieb Michel Dänzer:
And Wine's solution for this can't be implemented in Mesa?
I think this might actually be possible: In order to accomplish this
Wine essentially keeps calling mmaps with addresses in its range until
it finds a free spot. It of course is able to alr
This sounds interesting, but does it come with the same "Only gets 2GB
VA" downside Derek pointed out in the thread fork where he was
responding to Michel?
Thanks,
-James
On 10/22/24 07:14, Christian König wrote:
Hi guys,
one theoretical alternative not mentioned in this thread is the use of
Hi guys,
one theoretical alternative not mentioned in this thread is the use of
mremap().
In other words you reserve some address space below 2G by using
mmap(NULL, length, PROT_NONE, MAP_32BIT | MAP_ANONYMOUS, 0, 0) and then
use mremap(addr64bit, 0, length, MREMAP_FIXED, reserved_addr).
I
So, it sounds like something like an OpenGL equivalent of
VK_EXT_map_memory_placed would be more palatable?
While we're at it, something like VK_EXT_map_memory_placed that also allows
to place the GPU resource handles (not host VAs) could be used by
https://github.com/apitrace/apitrace to try repl
On 10/21/24 07:33, Jose Fonseca wrote:
I see a few downsides with the proposed callback:
- feels like a solution too tailored for WINE
- there's a layering violation: the application suddenly takes the
driving seat for a thing deep down in the GL driver
so I fear Mesa community might regret it d
I see a few downsides with the proposed callback:
- feels like a solution too tailored for WINE
- there's a layering violation: the application suddenly takes the driving
seat for a thing deep down in the GL driver
so I fear Mesa community might regret it doing, and once WINE supports
there would b
On 2024-10-21 11:20, Derek Lesho wrote:
> On 10/21/24 11:08, Michel Dänzer wrote:
>
>> On 2024-10-18 23:55, Derek Lesho wrote:
>>> Hey everyone 👋,
>>>
>>> I'm Derek from the Wine project, and wanted to start a discussion with
>>> y'all about potentially extending the Mesa OGL drivers to help us w
On 10/21/24 11:08, Michel Dänzer wrote:
On 2024-10-18 23:55, Derek Lesho wrote:
Hey everyone 👋,
I'm Derek from the Wine project, and wanted to start a discussion with y'all
about potentially extending the Mesa OGL drivers to help us with a
functionality gap we're facing.
Problem Space:
In
On 2024-10-18 23:55, Derek Lesho wrote:
> Hey everyone 👋,
>
> I'm Derek from the Wine project, and wanted to start a discussion with y'all
> about potentially extending the Mesa OGL drivers to help us with a
> functionality gap we're facing.
>
> Problem Space:
>
> In the last few years Wine's
Hey Timur,
This is actually what Wine has traditionally done, the problem is that
we are moving forward to a new implementation for running 32-bit Windows
apps, where all of Wine's ELF code is 64-bit, and interacts with the
host as a normal 64-bit app. In order to use a 32-bit driver in this
Hello Derek,
As I am not working on GL, I don't have anything to contribute to the
discussion, but I just have a question out of curiosity: what's wrong
with simply using a driver that is compiled for 32-bit?
Best regards,
Timur
On Fri, 2024-10-18 at 23:55 +0200, Derek Lesho wrote:
> Hey everyon
On 10/19/24 00:47, Faith Ekstrand wrote:
The timing here isn't great, unfortunately. I'd love to contribute
more to the discussion but I'm going on leave starting next week until
mid-Febuary so I won't be able to participate much until then. I'll
try to leave a few thoughts, though.
Thanks for
The timing here isn't great, unfortunately. I'd love to contribute more to
the discussion but I'm going on leave starting next week until mid-Febuary
so I won't be able to participate much until then. I'll try to leave a few
thoughts, though.
On Fri, Oct 18, 2024 at 5:10 PM Derek Lesho wrote:
>
Hey everyone 👋,
I'm Derek from the Wine project, and wanted to start a discussion with
y'all about potentially extending the Mesa OGL drivers to help us with a
functionality gap we're facing.
Problem Space:
In the last few years Wine's support for running 32-bit windows apps in
a 64-bit hos
27 matches
Mail list logo
