On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson chris.kcat@gmail.comwrote:
On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
I had an interesting thought the other day, and that is to having some built in support for forwarding windows dlls to linux .so's.
IIRC, this kind of thing is generally discouraged, except in cases where needed (eg. opengl32). Part of the problem is internal differences.. for example, what would a Linux .so do if it's given a Win32 filename path? Other problems would be if the Linux equivalent wants a Window for a function argument and the DLL wants an HWND instead, or if the DLL has more/different functions (eg. CUDA on Win32 has functions for dealing with D3D objects; CUDA on Linux doesn't, and it wouldn't be straight forward to even implement them through wined3d).
Something like OpenGL, and even OpenAL to some degree, would directly benefit from having the DLLs forwarded to their host equivalents as it provides better access to the hardware and better integration with the host system. Something like zlib or ogg/vorbis and stuff wouldn't though, since the code should largely be the same, and save for some bugs/inefficiencies in Wine (which should be fixed), would work identically.
Does Wine yet have the capability to interface with HAL for Win32 hardware access similar to NT? It looks like it doesn't from all this talk of forwarding DLLs. What we should do instead of trying to forward DLLs, which is asking for more trouble than its worth, is try to get the NT layer to connect to UNIX HAL so that DLLs can link directly to HAL and operate the hardware.
On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson chris.kcat@gmail.comwrote:
On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
I had an interesting thought the other day, and that is to having some built in support for forwarding windows dlls to linux .so's.
IIRC, this kind of thing is generally discouraged, except in cases where needed (eg. opengl32). Part of the problem is internal differences.. for example, what would a Linux .so do if it's given a Win32 filename path? Other problems would be if the Linux equivalent wants a Window for a function argument and the DLL wants an HWND instead, or if the DLL has more/different functions (eg. CUDA on Win32 has functions for dealing with D3D objects; CUDA on Linux doesn't, and it wouldn't be straight forward to even implement them through wined3d).
Something like OpenGL, and even OpenAL to some degree, would directly benefit from having the DLLs forwarded to their host equivalents as it provides better access to the hardware and better integration with the host system. Something like zlib or ogg/vorbis and stuff wouldn't though, since the code should largely be the same, and save for some bugs/inefficiencies in Wine
(which
should be fixed), would work identically.
Does Wine yet have the capability to interface with HAL for Win32 hardware access similar to NT? It looks like it doesn't from all this talk of forwarding DLLs. What we should do instead of trying to forward DLLs, which is asking for more trouble than its worth, is try to get the NT layer to connect to UNIX HAL so that DLLs can link directly to HAL and operate the hardware.
This can't be done. You would be writing your own operating system and hardware can't be shared. It is not that hard to write wrapper libraries. Second even if libraries look similar between OSes take for instance Cuda it does offer OS-specific functionality like e.g. Direct3D integration.
Roderick
On Wed, Feb 18, 2009 at 2:11 AM, Roderick Colenbrander < thunderbird2k@gmx.net> wrote:
On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson chris.kcat@gmail.comwrote:
On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
I had an interesting thought the other day, and that is to having
some
built in support for forwarding windows dlls to linux .so's.
IIRC, this kind of thing is generally discouraged, except in cases
where
needed (eg. opengl32). Part of the problem is internal differences..
for
example, what would a Linux .so do if it's given a Win32 filename path? Other problems would be if the Linux equivalent wants a Window for a function argument and the DLL wants an HWND instead, or if the DLL has more/different functions (eg. CUDA on Win32 has functions for dealing with D3D
objects;
CUDA on Linux doesn't, and it wouldn't be straight forward to even implement them through wined3d).
Something like OpenGL, and even OpenAL to some degree, would directly benefit from having the DLLs forwarded to their host equivalents as it provides better access to the hardware and better integration with the host system. Something like zlib or ogg/vorbis and stuff wouldn't though, since the code
should
largely be the same, and save for some bugs/inefficiencies in Wine
(which
should be fixed), would work identically.
Does Wine yet have the capability to interface with HAL for Win32
hardware
access similar to NT? It looks like it doesn't from all this talk of forwarding DLLs. What we should do instead of trying to forward DLLs, which is asking for more trouble than its worth, is try to get the NT layer to connect to UNIX HAL so that DLLs can link directly to HAL and operate the hardware.
This can't be done. You would be writing your own operating system and hardware can't be shared. It is not that hard to write wrapper libraries. Second even if libraries look similar between OSes take for instance Cuda it does offer OS-specific functionality like e.g. Direct3D integration.
Roderick
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
So it wouldn't be possible to hook Wine's Direct3D implementation into Gallium3D on Linux and use the hardware directly instead of translating it to OpenGL and then sending it to the hardware?
Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha:
So it wouldn't be possible to hook Wine's Direct3D implementation into Gallium3D on Linux and use the hardware directly instead of translating it to OpenGL and then sending it to the hardware?
Possible yes. I don't know if its gains anything though. We can never use the hardware directly, we always have to bother the Linux/Mac/Whatever driver.
If we go D3D->Gallium3D->Driver->HW or D3D->GL->Driver->HW doesn't make too much difference, and Gallium3D is a driver specific API. It won't work on the proprietary drivers or on MacOS, so I don't think it is worth the effort.
The one big advantage of Gallium3D is that its interface is more flexible, and it is easier to implement certain things that opengl doesn't have yet(e.g. the color selection for flat shading).
The bottom line is that if anybody implements a Gallium3D backend and it is well-written and has a reasonable design it will most likely be accepted. I personally don't have any plans to do that right now though.
Stefan Dösinger a écrit :
Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha:
So it wouldn't be possible to hook Wine's Direct3D implementation into Gallium3D on Linux and use the hardware directly instead of translating it to OpenGL and then sending it to the hardware?
Possible yes. I don't know if its gains anything though. We can never use the hardware directly, we always have to bother the Linux/Mac/Whatever driver.
If we go D3D->Gallium3D->Driver->HW or D3D->GL->Driver->HW doesn't make too much difference, and Gallium3D is a driver specific API. It won't work on the proprietary drivers or on MacOS, so I don't think it is worth the effort.
The one big advantage of Gallium3D is that its interface is more flexible, and it is easier to implement certain things that opengl doesn't have yet(e.g. the color selection for flat shading).
The bottom line is that if anybody implements a Gallium3D backend and it is well-written and has a reasonable design it will most likely be accepted. I personally don't have any plans to do that right now though.
Out of curiosity, would moving to this sort of architecture http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That may give manufacturer the possibility to develop wine-direct3d drivers and support what wine does not support. This would require a major architecture change in the current wine's d3d implementation though.
2009/2/18 Jérôme Gardou jerome.gardou@gmail.com:
Out of curiosity, would moving to this sort of architecture http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That may give manufacturer the possibility to develop wine-direct3d drivers and support what wine does not support. This would require a major architecture change in the current wine's d3d implementation though.
Possible sure, but I don't think it would be worth the effort. IIRC ddraw support might be a problem as well.
Henri Verbeet a écrit :
2009/2/18 Jérôme Gardou jerome.gardou@gmail.com:
Out of curiosity, would moving to this sort of architecture http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That may give manufacturer the possibility to develop wine-direct3d drivers and support what wine does not support. This would require a major architecture change in the current wine's d3d implementation though.
Possible sure, but I don't think it would be worth the effort. IIRC ddraw support might be a problem as well.
Well, the fact is that wined3d is a bit d3d8/9 centric, and integrating DXGI and d3d10/11 might as well be tricky. I've seen that some work had begun, and I'm quite curious on which design decision you will make.
As of ddraw, wouldn't it be possible to write it on top of d3d9, as it is already done with wined3d.
Am Mittwoch, 18. Februar 2009 23:47:47 schrieb Jérôme Gardou:
As of ddraw, wouldn't it be possible to write it on top of d3d9, as it is already done with wined3d.
That will screw non-opengl ddraw rendering, which the VNC/remote X/old card/bad driver users will not really like. WineD3D currently has two surface implementations, one for GL based rendering and one for SW emulation(2D only)
/me remembers the uproar when the ddraw rewrite broke the ability to compile ddraw without GL headers. (gentoo useflags OMG!!!)
Stefan Dösinger a écrit :
Am Mittwoch, 18. Februar 2009 23:47:47 schrieb Jérôme Gardou:
As of ddraw, wouldn't it be possible to write it on top of d3d9, as it is already done with wined3d.
That will screw non-opengl ddraw rendering, which the VNC/remote X/old card/bad driver users will not really like. WineD3D currently has two surface implementations, one for GL based rendering and one for SW emulation(2D only)
/me remembers the uproar when the ddraw rewrite broke the ability to compile ddraw without GL headers. (gentoo useflags OMG!!!)
This might be a silly question, but isn't MESA here just for it : providing openGL functionality to sytems that don't have good hardware? And wasn't it planned somewhere to split together wined3d and winex11 (not related to the question here, but just curious :) )
This might be a silly question, but isn't MESA here just for it : providing openGL functionality to sytems that don't have good hardware? And wasn't it planned somewhere to split together wined3d and winex11 (not related to the question here, but just curious :) )
Gentoo users still have to set the +opengl use flag... That's where most of the complaints came from.
The other aspect is that even software GL isn't available when you're using Xvnc or similar servers.
Gentoo users still have to set the +opengl use flag... That's where most of the complaints came from.
The other aspect is that even software GL isn't available when you're using Xvnc or similar servers.
To be honest, I prefer the second argument over the first one :-)
I still don't see what the harm is in having support for .so's. I mean even if it brings partial compatibility to the dlls vs so's isn't it worth it? That is more than we have right now in Wine. What was the last version to have the built in support? I'd like to see if I can't update it, and port it to the latest GIT of Wine and see how it does. See if it works as well as the CUDA wrapper, or the CAL wrapper. See if there is a benefit or not to having this support.
Thanks,
Seth Shelnutt
-
Henri Verbeet -
Jérôme Gardou -
King InuYasha -
Roderick Colenbrander -
Seth Shelnutt -
Stefan Dösinger