Old 11-16-2019, 05:27 PM   #41
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 5,524
Default

I believe devs recently changed the entire graphics engine of the arrange, to make it also compatible with the new OSX system (which I believe it is hardware accelerated?) and it is much faster with many hundreds of tracks than before. Justin said it would probably break many things, but that didn't stop him to do it.

I really wouldn't complain if we could have GPU accelerated graphics on scripts. Some scripts can become heavy on graphics. And when I scroll the arrange for example, they can stop to be refreshed creating some problems as I described here: https://forum.cockos.com/showthread.php?t=163905
heda is offline   Reply With Quote
Old 11-16-2019, 06:47 PM   #42
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 764
Default

It is not hardware accelerated. Go check in your system settings. Only certain plugins, like fabfilter use hardware acceleration when used inside reaper. That´s it.
__________________
Intel core i7 6700K - socket 1151 LGA - Chipset z170 - 16G DDR4 - Nvidia GTX 1060
pepe44 is online now   Reply With Quote
Old 11-16-2019, 11:32 PM   #43
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,140
Default

Quote:
Originally Posted by Klangfarben View Post
assigning a dedicated core or cores to the GUI...
I don't suppose this will help in a "CPU busy" situation, as you describe. In a DAW by default CPU threads assigned to audio are higher priority, meaning that the GUI will lag, if all CPU power is needed for audio, but the GUI will automatically get the remaining CPU cycles as soon as it's possible to calculate the audio without dropouts. Audio only is allowed to wait for as long as the buffer setting says. This is not an amount of time the smoothness of the GUI will noticeably benefit from.

Hence in such a "busy" situation, dedicating a core to the GUI will result in degrading audio. This might be what you want in certain situations, but it's bad as a default behavior.

In a "non busy" (audio not demanding or stopped) in fact only one core will do GIU work. Here in fact using multiple cores (i.e. OS threads) might help. But doing so is a lot of work, as communicating with the widget set tools of the OS with multiple threads is non-standard and rather complicated and error-prone. (I in fact did such stuff some years ago.).

Offloading some visual work to the GPU (handling the GUI like a game programmer would, e.g by using a framework like OpenGL) might speed up the GUI without hampering audio. But that needs a complete overhaul of a program initially done by a different GUI tool set (widgets). I in fact once helped doing this for a computer graphics program .

-Michael

Last edited by mschnell; 11-16-2019 at 11:45 PM.
mschnell is offline   Reply With Quote
Old 11-16-2019, 11:40 PM   #44
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,140
Default

Quote:
Originally Posted by heda View Post
(which I believe it is hardware accelerated?)
Any Widget Set of any modern OS is hardware accelerated by using the GPU, and there is close to no hardware that does not feature a GPU. Otherwise rendering just the standard widgets to the screen would be awfully slow. In Linux you can select a Framebuffer driver that does the rendering completely by the CPU. Of course nobody does this any more .
Hence what is discussed here is a kind of "advanced" / manual hardware acceleration of the GUI using the GPU.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 05:30 AM   #45
BirdBird
Human being with feelings
 
BirdBird's Avatar
 
Join Date: Mar 2019
Posts: 60
Default

Quote:
Originally Posted by mschnell View Post
I don't suppose this will help in a "CPU busy" situation, as you describe. In a DAW by default CPU threads assigned to audio are higher priority, meaning that the GUI will lag, if all CPU power is needed for audio, but the GUI will automatically get the remaining CPU cycles as soon as it's possible to calculate the audio without dropouts. Audio only is allowed to wait for as long as the buffer setting says. This is not an amount of time the smoothness of the GUI will noticeably benefit from.

Hence in such a "busy" situation, dedicating a core to the GUI will result in degrading audio. This might be what you want in certain situations, but it's bad as a default behavior.

In a "non busy" (audio not demanding or stopped) in fact only one core will do GIU work. Here in fact using multiple cores (i.e. OS threads) might help. But doing so is a lot of work, as communicating with the widget set tools of the OS with multiple threads is non-standard and rather complicated and error-prone. (I in fact did such stuff some years ago.).


-Michael
Thanks for the explanation I am still trying to wrap my head around it.
So in a situation like this:

Core 1: Audio ---------- Core 2: Audio ---------- Core 3: Audio ---------- Core 4: GUI

Would the GUI thread here still starve if there is heavy audio workload? I was under the assumption that since different cores do their operations in parallel the workload on the other 3 cores would not affect the performance on the 4th core.
BirdBird is offline   Reply With Quote
Old 11-17-2019, 08:25 AM   #46
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,140
Default

As all cores can run at the same time and Reaper sets the audio threads to highest priority, and Reaper requests an OS thread for each track, and the OS assigns cores to OS threads according th the priority, all available cores are assigned to audio as long as there are more tracks with work to do. only then a core will be assigned to the GUI thread.
Hence yer: it would sometimes (unnecessarily) starve audio, if the behavior would be changed.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 09:01 AM   #47
BirdBird
Human being with feelings
 
BirdBird's Avatar
 
Join Date: Mar 2019
Posts: 60
Default

Quote:
Originally Posted by mschnell View Post
As all cores can run at the same time and Reaper sets the audio threads to highest priority, and Reaper requests an OS thread for each track, and the OS assigns cores to OS threads according th the priority, all available cores are assigned to audio as long as there are more tracks with work to do. only then a core will be assigned to the GUI thread.
Hence yer: it would sometimes (unnecessarily) starve audio, if the behavior would be changed.

-Michael
So you just described how it currently works, is that correct? What i am trying to understand is, if the behaviour was changed and we could assign a dedicated core that does GUI only, would that mean that the GUI thread could do its work without getting interrupted by audio?

The other end of it is that i wouldn't really mind losing some processing power for FX processing if it means i get a stable GUI out of it, the tweak suggested is less about audio performance and more about user experience, superb audio performance doesn't matter much if i can't do anything during playback
BirdBird is offline   Reply With Quote
Old 11-17-2019, 09:06 AM   #48
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,990
Default

Quote:
Originally Posted by mschnell View Post
Any Widget Set of any modern OS is hardware accelerated by using the GPU
Are you sure that is the case for example with the Windows win32 common controls? (Which is what Reaper uses for some parts of its GUI.) But even if that was so, most of the screen estate in Reaper has custom graphics that are currently rendered on the CPU. (Level meters, audio waveforms, the MIDI editor...) I literally see 0% GPU use in Windows with Reaper when not using any 3rd party plugins that use the GPU for their graphics. Maybe parts of the Reaper GUI are rendered on the GPU by the OS, but it uses so few GPU cycles it doesn't even register in Process Explorer's GPU usage graph.
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/
Xenakios is online now   Reply With Quote
Old 11-17-2019, 09:12 AM   #49
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 785
Default

Quote:
Originally Posted by mschnell View Post
Hence in such a "busy" situation, dedicating a core to the GUI will result in degrading audio. This might be what you want in certain situations, but it's bad as a default behavior.
It could only negatively affect the audio if the CPU usage exceeded the number of remaining (non-dedicated) cores/threads. So, in the case of having enough available cores/threads, the audio would not be affected in any way. I agree, this should not be default behavior, but if the user has enough cores, there is nothing negative about doing this. Other DAWS have reserved cores for certain functions without degrading audio. There is no reason to think Reaper would be different in this regard.

Also, keep in mind the high CPU usage of GUI-related functions can and will degrade the audio. Yes, audio threads are always processed with highest priority, but if the CPU spikes or the GUI-related function is eating up too much of the available CPU/threads, the audio most certainly is negatively affected. Reaper is pretty good about this, but when the CPU is maxed/strained, you still get clicks and pops and other degradation.

So, what we are talking about here is that currently, because of non-optimized or hardware-accelerated GUI, we are getting laggy behavior that destroys workflow. Slow or non-existent redraw, no video playback, etc, etc. Also, because GUI is only using CPU rather than GPU/hardware acceleration, it can also negatively affect audio playback, even when audio has the highest priority. Now, the second issue can only be solved by offloading to the GPU or optimizing the GUI usage. But the first could be solved with a dedicated core as long as CPU usage didn't exceed what is available on the remaining cores. I think it should be an option.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 09:28 AM   #50
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,990
Default

I think an extension plugin could be made to test the "assign a dedicated CPU core for the GUI thread" thing. (On Windows, enumerate through the Reaper process threads and use SetThreadAffinityMask and SetThreadPriority as appropriate for them.) I don't have any heavy real life projects to test the behavior with, though, I could only do synthetic tests. My expectation is that it wouldn't really help anything, even if there were CPU cores/time to spare. Some of the GUI operations in Reaper just are inherently slow and assigning more CPU priority or even a dedicated core to them isn't likely to help that much. It would still be interesting to test, I guess.
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/

Last edited by Xenakios; 11-17-2019 at 09:36 AM.
Xenakios is online now   Reply With Quote
Old 11-17-2019, 09:30 AM   #51
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 764
Default

sure klang, and has i said, cockos has different priorities for now.
Rebuilding a full GUI engine is not one of them.
__________________
Intel core i7 6700K - socket 1151 LGA - Chipset z170 - 16G DDR4 - Nvidia GTX 1060
pepe44 is online now   Reply With Quote
Old 11-17-2019, 09:34 AM   #52
BirdBird
Human being with feelings
 
BirdBird's Avatar
 
Join Date: Mar 2019
Posts: 60
Default

Quote:
Originally Posted by pepe44 View Post
sure klang, and has i said, cockos has different priorities for now.
Rebuilding a full GUI engine is not one of them.
Do you work at Cockos? Are you one of the developers? Why are you talking on their behalf?
BirdBird is offline   Reply With Quote
Old 11-17-2019, 09:36 AM   #53
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 785
Default

Quote:
Originally Posted by Xenakios View Post
I think an extension plugin could be made to test the "assign a dedicated CPU core for the GUI thread" thing. (Enumerate through the Reaper process threads and use SetThreadAffinityMask and SetThreadPriority as appropriate for them.) I don't have any heavy real life projects to test the behavior with, though, I could only do synthetic tests. My expectation is that it wouldn't really help anything, even if there were CPU cores/time to spare. Some of the GUI operations in Reaper just are inherently slow and assigning more CPU priority or even a dedicated core to them isn't likely to help that much. It would still be interesting to test, I guess.
Wow, that's actually a really clever idea. You might be right though, in which case a dedicated core wouldn't be much good.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 09:39 AM   #54
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 785
Default

Quote:
Originally Posted by pepe44 View Post
sure klang, and has i said, cockos has different priorities for now.
Rebuilding a full GUI engine is not one of them.
Well I can't say what their priorities are obviously. But it is a workflow killer so I think the OPs request is pretty valid and will make the argument and let the chips fall where they may.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 09:43 AM   #55
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 764
Default

Quote:
Originally Posted by BirdBird View Post
Do you work at Cockos? Are you one of the developers? Why are you talking on their behalf?
Hi BirdBird, no i´m not a developer. But there are at least 10 forum posts about this subject, just look at the dates and see for how long this has been asked.

Did you even listen to the latest Justin talk on Dawbench podcast? Maybe its a good start to get in into the real deal of Cockos and reaper.
__________________
Intel core i7 6700K - socket 1151 LGA - Chipset z170 - 16G DDR4 - Nvidia GTX 1060
pepe44 is online now   Reply With Quote
Old 11-17-2019, 09:45 AM   #56
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 764
Default

Quote:
Originally Posted by Klangfarben View Post
Well I can't say what their priorities are obviously. But it is a workflow killer so I think the OPs request is pretty valid and will make the argument and let the chips fall where they may.
Sure it is, im not against the OP request! we all would benefit from that.
But do you understand that is not on the Top priorities ? and why they are not ?
__________________
Intel core i7 6700K - socket 1151 LGA - Chipset z170 - 16G DDR4 - Nvidia GTX 1060
pepe44 is online now   Reply With Quote
Old 11-17-2019, 09:54 AM   #57
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Posts: 3,020
Default

I wouldn’t be too sure about this. No one really expected the devs to make Reaper work smoother with a huge track count, Then, from one day to another, we had this feature showing up in a pre. Expect the unexpected.
__________________
My Reascripts forum thread | My Reascripts on GitHub | Stephan Römer - film composer
If you wish to donate for my scripts: please consider an organization like: animal shelter, doctors without borders, UNICEF, etc...
_Stevie_ is offline   Reply With Quote
Old 11-17-2019, 09:55 AM   #58
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 785
Default

Quote:
Originally Posted by pepe44 View Post
But do you understand that is not on the Top priorities ? and why they are not ?
I don't actually. I can't speak for the developers nor what their road map/priority list might be. They've certainly introduced new features out of the blue I never expected or thought I would ever see (like re-writing CC with interpolation) so this wouldn't be any different. I think discussing the developers mindset and what they may or may not do is pretty moot. As users all we can do is make the argument and show the need. Anything else is outside our purview.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 10:00 AM   #59
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 764
Default

http://dawbench.libsyn.com/episode-0...present-future
__________________
Intel core i7 6700K - socket 1151 LGA - Chipset z170 - 16G DDR4 - Nvidia GTX 1060
pepe44 is online now   Reply With Quote
Old 11-17-2019, 10:04 AM   #60
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Posts: 3,020
Default

Quote:
Originally Posted by Klangfarben View Post
As users all we can do is make the argument and show the need. Anything else is outside our purview.
That’s exactly right. There’s no room for speculations.
__________________
My Reascripts forum thread | My Reascripts on GitHub | Stephan Römer - film composer
If you wish to donate for my scripts: please consider an organization like: animal shelter, doctors without borders, UNICEF, etc...
_Stevie_ is offline   Reply With Quote
Old 11-17-2019, 10:09 AM   #61
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 785
Default

Quote:
Originally Posted by pepe44 View Post
I listened to that as well. And apparently we should all be concerned because we are all going to have to switch to Linux.

Come on man. Stop convoluting the thread with speculation. If you support the feature then chime in with a plus 1. If you don't, then make the argument against. Btw, saying the developers don't have time for it isn't an argument against. Unless you had coffee with Justin this morning there's a pretty fair chance you don't know what's coming in the next pre.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 10:12 AM   #62
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Posts: 3,020
Default

Well, +1
__________________
My Reascripts forum thread | My Reascripts on GitHub | Stephan Römer - film composer
If you wish to donate for my scripts: please consider an organization like: animal shelter, doctors without borders, UNICEF, etc...
_Stevie_ is offline   Reply With Quote
Old 11-17-2019, 10:16 AM   #63
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 764
Default

Quote:
Originally Posted by Klangfarben View Post
I listened to that as well. And apparently we should all be concerned because we are all going to have to switch to Linux.

Come on man. Stop convoluting the thread with speculation. If you support the feature then chime in with a plus 1. If you don't, then make the argument against. Btw, saying the developers don't have time for it isn't an argument against. Unless you had coffee with Justin this morning there's a pretty fair chance you don't know what's coming in the next pre.
+1 , peace.
Not here to talk on developers behalf or make wrong suppositions.

Regarding the Linux, maybe its the future anyway..since 1980...
__________________
Intel core i7 6700K - socket 1151 LGA - Chipset z170 - 16G DDR4 - Nvidia GTX 1060
pepe44 is online now   Reply With Quote
Old 11-17-2019, 10:19 AM   #64
White Tie
Pixel Pusher
 
White Tie's Avatar
 
Join Date: Mar 2007
Location: Blighty
Posts: 2,703
Default

Quote:
Originally Posted by Klangfarben View Post
Why does everyone always make the argument that x feature request will completely break the Reaper code? Justin and Schwa aren't idiots.
Its not a matter of being idiots. Its a matter of replacing something known, tested and trusted with something untested and uncertain. The bigger the change, the bigger the degree of uncertainty and the greater the risk.

Its also not an absolute thing. Justin or Schwa might make a change seemingly flawlessly, and the hard-working folks in the pre forum might test it hard, and then months later something odd might happen for 3 users who like to run 48 instances of a bolivian noseflute plugin from 1992, and there would be no indication that it stems back to that change that was made. The potential time spent chasing that bugger down needs to be factored into the time the change would make.

Source : I have been responsible for causing this sort of thing!

GPU acceleration is only going to become more important, as future computers' screen resolutions rise and their CPU power is throttled to save power and thermals. This is the way things are going. This will need to be addressed. But the driving motivation will, I expect, come from users reporting poor performance, to which GPU utilization might be the cure, than from requests for GPU acceleration for its own sake.
__________________
The House of White Tie
White Tie is offline   Reply With Quote
Old 11-17-2019, 10:27 AM   #65
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 785
Default

Thanks White Tie. All good points.

I do want to point out that it is in fact the poor performance that is driving the feature request, not just for its own sake. For those of us running large screens or multiple screens or with large templates, it's a big problem.

Also, I'd like to point out that I'm very partial to nose flute. And Linux
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 01:19 PM   #66
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 764
Default

I have a Dual monitor setup and regularly i mix medium/large sessions (40 to 100 tracks). Some medium / heavy CPU load with routing, FX and outboard. I do "spread" outboard in a few submixes to offload the high PDC on one only Submix track. Do you guys do that ? If not maybe worth a test.
This new windows update 1909 made some things a bit smoother regarding the GUI spikes
I normally print tracks too.
__________________
Intel core i7 6700K - socket 1151 LGA - Chipset z170 - 16G DDR4 - Nvidia GTX 1060
pepe44 is online now   Reply With Quote
Old 11-17-2019, 04:17 PM   #67
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,140
Default

Quote:
Originally Posted by BirdBird View Post
i wouldn't really mind losing some processing power for FX processing
If CPU power is available without producing dropouts and cracks, it's given to the GUI thread, anyway.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 04:19 PM   #68
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,140
Default

Quote:
Originally Posted by Xenakios View Post
Are you sure that is the case for example with the Windows win32 common controls.
Any text rendering is done by the GPU. anything else would result in a horrible performance.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 04:22 PM   #69
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,140
Default

Quote:
Originally Posted by Klangfarben View Post
It could only negatively affect the audio if the CPU usage exceeded the number of remaining (non-dedicated) cores/threads. .
The count of tracks (plus master track) very often will be greater than the number of cores.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 06:25 PM   #70
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,990
Default

Quote:
Originally Posted by mschnell View Post
Any text rendering is done by the GPU. anything else would result in a horrible performance.
Nah, I don't think so. Doing text rendering fully on the GPU is extremely complicated, doing it on the CPU would probably make much more sense, especially considering situations when the text needs to be incorporated with other graphics. (At least Cockos's Lice and Juce do it on the CPU. The Qt framework also used to. And I bet win32 common controls also do it on the CPU.)
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/
Xenakios is online now   Reply With Quote
Old 11-17-2019, 06:31 PM   #71
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,990
Default

Quote:
Originally Posted by heda View Post
I really wouldn't complain if we could have GPU accelerated graphics on scripts.
It wouldn't make any sense to implement it only for scripts, the needed effort would be pretty much the same as implementing it for Reaper's other graphics.
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/
Xenakios is online now   Reply With Quote
Old 11-18-2019, 12:21 AM   #72
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 8,140
Default

Quote:
Originally Posted by Xenakios View Post
Nah, I don't think so.
So I am in error here with m guessing ? I in fact did not do a research on that, as it seemed perfectly obvious to me: offloading True Type character rendering as the most computational intensive standard task from the CPU.

At my work, we once used a flash player embedded in the GUI of a program to avoid the need for handling such stuff in our own software, which was not intended to use the GPU.

-Michael

Last edited by mschnell; 11-18-2019 at 12:29 AM.
mschnell is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 08:28 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.