February 2012 - Wine-Devel - list.winehq.org

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers

by Stefan Dösinger

Am Dienstag, 28. Februar 2012, 14:50:28 schrieb Henri Verbeet: > Ok, but we could just be more clever about doing uploads and only > upload what's actually referenced by draws. We already have most of > the code for tracking uploaded ranges. Similarly, are we really sure > that maintaining a sysmem copy of the entire buffer is really better > than mapping the VBO for drawStridedSlow() in the first place? At some > point the data needs to be sent to the GPU, and I think we're in a > better position to decide what to upload and when than the driver. Indexed draws will be tricky, it depends on how decent the app-provided index ranges are. It also means we'd have to track which parts of the VB are uploaded and which aren't. Mapping the VBO in drawStridedSlow might be an option, although I guess that would force the driver to wait until previous draws are done. All those options are out of reach for Wine 1.4, and beyond Wine 1.4 I'd prefer to fix the problems that force us into drawStridedSlow by implementing a vertex pipeline and proper instancing.

Feb. 28, 2012

Re: Major mmdevapi and winmm audio bugs

by Andrew Eikum

On Mon, Feb 27, 2012 at 11:41:56PM +0100, Maarten Lankhorst wrote: > > W.r.t. to 1.4.0, I believe the following path should be taken: > > - Write CreateTimerQueue tests to verify whether native behaves like: > > a) sleep(Xms) /* what Wine does now */ or > > b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */ > > - If b), fix CreateTimerQueue. > > - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi > > and something else must be sought... > Even if so, it is unneeded for the pulse driver, I'm using the auto timing > update feature and the callback for when rendering is not running. > When the buffer is not underflowed, I'm using the write callback to > signal more data is available. > > Timerqueue would be a lie, the driver should schedule when data can > actually be written and not based purely on ticks. Pulseaudio allows > this and I'm using this feature in my driver. It passes all the render > tests now except the volume related ones (they're a reminder, > and a nop on other drivers anyhow), and I'm working to complete > capture in a similar fashion as well. > > I believe the event should be triggered when there is actual data > available, at least that's how I understood the event is supposed > to work. Doing it based on a timer that isn't tied to the state in > any way feels wrong. Having 2 threads for pulse feels wrong too, > especially since it can be done with just using the one pulse > provides, because you can set callbacks for when more data > can be read or written. > Unfortunately, the only backend that actually produces that kind of information is Pulse. So we need a solution for the other drivers anyway. At that point, we'll have to decide whether we want to use the same mechanism for Pulse, or rely on the callbacks. There's an argument for having each driver behave as similar as possible, even if it's arguably less "correct." I've also been burned enough times by relying on the audio backend to work correctly that I hesitate to give the backends more responsibility than absolutely necessary. I'm investigating native TimerQueue's operation now. If it turns out that TimerQueue isn't sufficient, we'll probably just switch over to using poll() like winmm's timer stuff does. Andrew

Feb. 28, 2012

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic

by Henri Verbeet

On 28 February 2012 14:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Dienstag, 28. Februar 2012, 13:05:16 schrieb Henri Verbeet: >> I don't see why WRITEONLY should imply DYNAMIC. > For one, the documents from nvidia tell you to set D3DVBCAPS_WRITEONLY when > you want to stream data[1]. Microsoft doesn't really document how dynamic > buffers work in d3d7. > > The other consideration is that DYNAMIC buffers that are not WRITEONLY are a > bad idea in d3d8/9. Yes, we don't handle WINED3DUSAGE_WRITEONLY at the moment, > but the consideration makes sense for d3d7 too. > Yes, but that's the other way around. If anything, that pdf suggests that buffers are dynamic by default in ddraw.

Feb. 28, 2012

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers

by Henri Verbeet

On 28 February 2012 13:46, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > buffer_direct_upload is working correctly and the gl buffer is mapped with > GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT, depending on the > lock flags the buffer used. The performance hit comes from the memcpy, not the > buffer map. This is particularly bad in 30019 because d3d7 forces us to memcpy > the entire buffer. I added some dummy writes to the start and the end of the > buffer instead of the memcpy to make sure the driver is forced to upload data. > Ok, but we could just be more clever about doing uploads and only upload what's actually referenced by draws. We already have most of the code for tracking uploaded ranges. Similarly, are we really sure that maintaining a sysmem copy of the entire buffer is really better than mapping the VBO for drawStridedSlow() in the first place? At some point the data needs to be sent to the GPU, and I think we're in a better position to decide what to upload and when than the driver.

Feb. 28, 2012

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic

by Stefan Dösinger

Am Dienstag, 28. Februar 2012, 13:05:16 schrieb Henri Verbeet: > I don't see why WRITEONLY should imply DYNAMIC. For one, the documents from nvidia tell you to set D3DVBCAPS_WRITEONLY when you want to stream data[1]. Microsoft doesn't really document how dynamic buffers work in d3d7. The other consideration is that DYNAMIC buffers that are not WRITEONLY are a bad idea in d3d8/9. Yes, we don't handle WINED3DUSAGE_WRITEONLY at the moment, but the consideration makes sense for d3d7 too. > Setting it for all > ddraw buffers may make sense, but even then I'd like to hear a > somewhat more convincing argument that now is the right time to change > this. To fix bug 30019. That's the one argument I have. I'm happy to defer this change until after Wine 1.4. It's fairly obvious that we have to set DYNAMIC somewhere if we want DDLOCK_DISCARDCONTENTS and DDLOCK_NOOVERWRITE to work, but I think that's not your point of concern. 1: http://developer.download.nvidia.com/assets/gamedev/docs/top5perfkill.pdf

Feb. 28, 2012

Re: Web based translation tool

by Aric Stewart

Hi, I have had quite a long discussion with the TranslateWiki people. They are great and while what we need would require a bit of PHP development they expressed that they would be happy to do the work. The main sticking block is that our requirement for Real Names and e-mail for all contributors runs contrary to their privacy policy. So we would not be able to get that information in our patches. They are currently exploring that idea and we are in continued discussion about this. If we can get around that road block then they may be our best option. Transifex's Dimitris Glezos has also been very communicative with me, and very helpful, however Transifex does not actually do PO management converting the POs into their own database format and requiring developers to have a client tool to be able to get and push the translations. That could be done by a translation manager who would then generate all the patches and mail them with the proper credit. However he still has not answered my basic question of if we would be able to get that information. So I am still actively following up on these leads and hopefully something will work out. -aric On 2/28/12 1:42 AM, Yaron Shahrabani wrote: > Hi guys! > > If I understand correctly the wanted solution is the translation > attribution will be per string basis meaning that we can attribute a > certain author to a string. > > The only system I'm aware of that is capable of such thing is > TranslateWiki, which is a little overkill because we will have to use a > full wiki system in order to implement gettext (which can be done using > a much less sophisticated system). > > Since the Wine project already has a Wiki, maybe we can utilize this > wiki in order to install TranslateWiki. > > There are several advantages: > 1. The strings are saved just like wiki pages meaning that there's a > full history and diff of all strings including dates and authors. > 2. The statistics are great (The current statistics is nice as well but > contains less info). > 3. It's a full wiki system (Both advantage and disadvantage). > > None of the other systems can attribute a certain translation to a > certain author AFAICT. > > Kind regards, > YaronShahrabani > > <Hebrew translator> > > > > > 2012/2/27 Miroslav Suchý <msuchy(a)redhat.com <mailto:msuchy(a)redhat.com>> > > Hi, > I just read: > http://www.winehq.org/news/__2012022001 > <http://www.winehq.org/news/2012022001> > and then > http://wiki.winehq.org/__Translating > <http://wiki.winehq.org/Translating> > especially: > > The Wine project would be very interested in making its PO files > available on web-based community translations systems such as > Pootle or Launchpad. Our hope is that this would make > translating Wine even easier and engage new translators. > > The reason why it has not happened yet is that all Wine > contributions, including for translations, must be attributable > to a specific author and that these tools don't make that > possible yet. For more details see the wine-devel discussion > here and here. Any contributions that would solve this issue > would be very welcome. > > > which refer: > http://www.winehq.org/__pipermail/wine-devel/2012-__January/093908.html > <http://www.winehq.org/pipermail/wine-devel/2012-January/093908.html> > > I would like to point you to: > https://www.transifex.net/ > which can do the tracking. > > Latest version is probably not what you want, because it just add at > the top of the file: > # Translators: > # Martin Minar <skulliq(a)gmail.com <mailto:skulliq(a)gmail.com>>, 2011 > <tel:2011>. > # Milan Kerslager <kerslage(a)linux.cz <mailto:kerslage(a)linux.cz>>, > 2002 <tel:2002>, 2007 <tel:2007>. > # Miloslav Trmac <mitr(a)volny.cz <mailto:mitr(a)volny.cz>>, 2002 > <tel:2002>. > # Miroslav Suchý <msuchy(a)redhat.com <mailto:msuchy(a)redhat.com>>, > 2011 <tel:2011>. > msgid "" > msgstr "" > "Project-Id-Version: Spacewalk\n" > "Report-Msgid-Bugs-To: \n" > "POT-Creation-Date: 2011-12-21 13:07+0100\n" > "PO-Revision-Date: 2011-12-14 09:21+0000\n" > "Last-Translator: Miroslav Suchý <msuchy(a)redhat.com > <mailto:msuchy(a)redhat.com>>\n" > "Language-Team: Czech > (http://www.transifex.net/__projects/p/fedora/team/cs/ > <http://www.transifex.net/projects/p/fedora/team/cs/>)\n > > So you had overview of contributors, but you could not tell which > one contributor done which string. > > But version 0.7 (IIRC) sent each contribution immediately to git. > Under login (and email) of that contributor. That contributor was > "Author" and commiter was some transifex user. So this way you allow > git commit access to those contributors directly to git, but since > it goes via that web interface, they could commit only to /po/ > directory and even only to language, for which they had been granted. > > You can download it here: > http://trac.transifex.org/__files/ <http://trac.transifex.org/files/> > and setup your own instance. > > If is sufficient for you only tracking name of contributors, you can > use that hosted solution at: https://www.transifex.net/ > > > -- > Miroslav Suchy > Red Hat Satellite Engineering > > > > > >

Feb. 28, 2012

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers

by Stefan Dösinger

Am Dienstag, 28. Februar 2012, 13:05:36 schrieb Henri Verbeet: > I don't find this all that convincing either. My impression is that > the reason we have these kinds of problems is mostly that the buffer > conversion code is broken. I don't think there are legitimate cases > where not creating a VBO should improve performance. There's no conversion involved. 30019 uses double-buffered buffers because it falls back to drawStridedSlow for material source tracking. 29897 and 29079 also have double-buffered buffers without conversion too, I assume because of instanced draws. buffer_direct_upload is working correctly and the gl buffer is mapped with GL_MAP_UNSYNCHRONIZED_BIT or GL_MAP_INVALIDATE_BUFFER_BIT, depending on the lock flags the buffer used. The performance hit comes from the memcpy, not the buffer map. This is particularly bad in 30019 because d3d7 forces us to memcpy the entire buffer. I added some dummy writes to the start and the end of the buffer instead of the memcpy to make sure the driver is forced to upload data. It's not a minor performance difference. In 30019 it's 65 fps vs 0.67 fps. The d3d9 bugs are less severe, but in Serious Sam HD the framerate is still cut in half.

Feb. 28, 2012

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers

by Henri Verbeet

On 28 February 2012 12:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is for bug 30019. > > They are a lot slower than using no VBO at all in at least some, if not all > games. The reason for the slowdown is the memcpy call, not the buffer > map. I don't find this all that convincing either. My impression is that the reason we have these kinds of problems is mostly that the buffer conversion code is broken. I don't think there are legitimate cases where not creating a VBO should improve performance.

Feb. 28, 2012

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic

by Henri Verbeet

On 28 February 2012 12:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is for bug 30019. > > Out ddraw.dll forwards DDLOCK_DISCARDCONTENTS and DDLOCK_NOOVERWRITE to > wined3d, but wined3d ignores those flags because we never set > WINED3DUSAGE_DYNAMIC. D3d7 docs refer to D3DVBCAPS_WRITEONLY as the flag > to set when creating a buffer, so translate it to DYNAMIC | WRITEONLY. > > An argument could be made that we should set the DYNAMIC flag on all > d3d7 buffers, but until I see a game that needs it I prefer to keep > non-D3DVBCAPS_WRITEONLY buffers regular buffers. I don't see why WRITEONLY should imply DYNAMIC. Setting it for all ddraw buffers may make sense, but even then I'd like to hear a somewhat more convincing argument that now is the right time to change this.

Feb. 28, 2012

Re: A small cs.po file update

by Francois Gouget

On Mon, 27 Feb 2012, David wrote: > Hello. > > There is attached a small cs.po update. Gzipped. Generated using > winepo. More is coming. I am planning to update it all. Last will be > translation of certificates/encryption strings. Thanks for the translation update. Unfortunately the tool you used to edit the PO file converted all the line ends from LF to CR+LF. The resulting diff was not so small as it contained the whole file twice. I have cleaned it up and rediffed it for this time (and I'll try to modify winepo to detect this). Some notes about the patch: -#, fuzzy msgid "&Modify..." msgstr "Z&měnit" msgid "&Install" -msgstr "&Instalovat" +msgstr "Na&instalovat..." The ellipses don't match here. Ellipses are very important because, for instance, they make all the difference between a 'Print' button that will send the page to the default printer right away, and a 'Print...' button that will first display a dialog that will let you choose the destination printer or cancel before anything happens. These look like th eonly two issues so things are looking pretty good. msgid "" "Is '%1' a filename or directory\n" "on the target?\n" "(F - File, D - Directory)\n" msgstr "" "Je '%1' název souboru nebo adresáře\n" "v cíli?\n" "(F - Soubor, D - Adresář)\n" It would probably be more intuitive for users if you change the 'shortcut keys': "(S - Soubor, A - Adresář)\n" And then modify the two other corresponding translations: msgctxt "File key" msgid "F" msgstr "S" msgctxt "Directory key" msgid "D" msgstr "A" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A black hole is just God dividing by zero.

Feb. 28, 2012