If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
Is my Intel graphics driver up to date?
VanguardLH wrote:
Terry Pinnell wrote: Yes, although past tense applies now. The updated driver has unfortunately *not fixed it. For me or another friend on the same forum with an almost identical PC as mine and the same video problem. (With the way our NLE, Magix Movie Edit Pro Premium, handles the HDR effect, if you're curious.) Even though the i5 user does not have the problem. So we're still looking, although I'd have thought the chipset driver low on the list of possible causes? ... Did you read my post yesterday reporting that I had installed the latest driver? Twas in another subthread, missed it, sorry. Although both you and your friend are using Windows 10, are you both using the 64-bit version of Windows 10? Yep. http://www.pcmag.com/article2/0,2817,1777473,00.asp "... a native 64-bit video-editing program" http://www.magix.com/us/movie-edit-pro/premium/ "You require a 64-bit version of one the following operating systems: Windows 10, 8, 7" You'd expect a 64-bit only program's installer to NOT allow its install on a 32-bit version of Windows. As to your original topic, you now probably have the latest available driver. No, it may not be listed by Intel using the same version as for the package of driver files. For example, the video package version shown my AMD Catalyst and Device Manager is 15.20.1062.1004. However, looking at the versions of the actual driver files show varying versions (aka file versions, not package versions) only some of which match on the package version. So it depends on which version you are looking at: the package version (fileset) or the file version(s). https://www.extremetech.com/computin...should-you-buy "The Core i7 features quad-cores with Hyper-Threading enabled and Intel’s HD Graphics 530 solution. The Core i5 family offers quad-cores without Hyper-Threading, and either HD Graphics 530 or 510 GPUs." So the difference is whether or not there is hyperthreading and which video controller is included on the chip. I had assumed you (i7) and your buddy (i5) had the same video driver. Maybe not if he has an i5 with the HD 510 video controller. http://www.pcmag.com/article2/0,2817,2422874,00.asp If hyperthreading is the differentiating factor then maybe you disabling it for your i7 might show if the Magix program then works okay. Maybe Magix doesn't know how to handle virtual cores. Users have complained that enabling hyperthreading results in BSODs or unstable systems (probably due to a defective CPU) or even decreased performance for multi-threaded processes (e.g., [M]SQL) when compared with hyperthreading off. There can be racing problems or deadlocks in code with hyperthreading (not a defect of the processor but in the code, like not handling race conditions between threads). Thread stalling is another problem with hyperthreading. I've seen some forum posts where users complained that Magix did not use all cores in the multi-core processor and also did not use hyperthreading. To me, hyperthreading is like GPU acceleration in web browsers: sometimes helps but if not then disable it. See https://en.wikipedia.org/wiki/Hyper-threading. Some users report that stutter disappears after disabling hyperthreading: https://www.reddit.com/r/fo4/comment...utter_problem/ Maybe disabling the i7's extra features so it has only those in the i5 will get Magix to operate properly. https://software.intel.com/en-us/art...n-application/ "Hyper-Threading Technology cannot have performance expectations equivalent to that of multi-processing where all the processor resources are replicated." So reports from users that performance was worse with hyperthreading enabled is even supported in Intel's description. Simulated hardware isn't as fast as real hardware. If it's a driver issue, you might have to test prior versions of the driver for your CPU (i7) to see if one works. As I mentioned, the latest driver is not necessarily the best one. For some programs (games), I had to find the latest prior driver that still worked with them. The latest video driver wasn't the best one and sometimes the worst one. Just to be sure, are you you (i7) and your friend (i5) using the HD graphics controller within the CPU? Or might your friend have a video card? The embedded Intel video graphics is particularly strong in the graphics arena. Performance of CPU-embedded graphics is very low. http://www.videocardbenchmark.net/gp...u=Intel+HD+530 https://www.futuremark.com/hardware/...ics+530/review For graphics editing, I would think you would want something better than what is essentially a backup GPU: you revert back to it when your video card dies and until you get a replacement. Thanks, appreciate the suggestions. I'll discuss with others in the context of this HDR problem in the MEP forum. Terry, East Grinstead, UK |
Ads |
#17
|
|||
|
|||
Is my Intel graphics driver up to date?
Terry Pinnell wrote:
Thanks, appreciate the suggestions. I'll discuss with others in the context of this HDR problem in the MEP forum. Terry, East Grinstead, UK https://www.magix.info/uk/forum/hdr-...ages--1103421/ That's not the same thing as video game HDR. And your four second delay in the program, isn't likely to be a video driver issue. If the video driver was stalling and doing a VPU recover, you would expect the screen to "twitch" to some extent (loss of sync, screen going black for up to a second, usually the symptoms are significant). While Magix is running, I would use Process Monitor from Sysinternals.com (a Microsoft company), and run a trace while you "exercise" the bug. Then stop the trace and scroll back, and see if you can spot a contributing factor. Process Monitor does not log every possible aspect, but if Magix was consulting the registry for example, you might find your four second stretch of registry accesses logged in there. For some programs, you can see unbelievable things going on. Paul |
#18
|
|||
|
|||
Is my Intel graphics driver up to date?
On 06/03/2017 16:18, Terry Pinnell wrote:
And still unsure why Win 10 said my driver was up to date when in fact it was two versions old? A very small proportion of Windows drivers are ever distributed via Windows Update. Even then it's likely that not ever version will be on Windows Update. Also Microsoft sometimes takes features out before distributing them. IF you like to always have the very latest drivers for all your hardware you'd better get the drivers direct from the hardware manufacturer. Sometime Windows Updates even gets it wrong and offers a driver that isn't suitable and will cause problems. Also sometimes a particular computer made by, say, ABC that includes a part made by, say, XYZ won't work right with drivers obtained directly from XYZ, instead you need a modified driver you can only get from ABC. -- Brian Gregory (in the UK). To email me please remove all the letter vee from my email address. |
#19
|
|||
|
|||
Is my Intel graphics driver up to date?
Wolf K wrote:
Or: There is no such thing as a universal driver, one that will work with any and all hardware+software configurations. Have a good day, GPU driver downloads are seldom for just one GPU. The drivers can be bundled by OS, or by SKU. For example, I found one Intel driver for Skylake and Kaby Lake GPUs, but it didn't have an (apparently) identical GPU that was in a GoldMont processor. While some of the manufacturers have software you can load on the target computer, which figures out what driver to use, such software is usually a mess and is more trouble than it is worth. For example one idiot company uses Java for this. Which means you need the Sun/Oracle JRE Java package, install Java, run the driver finder, get your driver, uninstall the driver finder, uninstall the Java. (As you should not leave Java installed.) Another software wants you to install ..NET 4.5 (which of course you cannot do on WinXP). The concept is "rife with opportunities for the software-clown-car". And this is on platforms, where one PE32 would have done the job *just fine*. Paul |
#20
|
|||
|
|||
Is my Intel graphics driver up to date?
Paul wrote:
Terry Pinnell wrote: Thanks, appreciate the suggestions. I'll discuss with others in the context of this HDR problem in the MEP forum. Terry, East Grinstead, UK https://www.magix.info/uk/forum/hdr-...ages--1103421/ That's not the same thing as video game HDR. And your four second delay in the program, isn't likely to be a video driver issue. If the video driver was stalling and doing a VPU recover, you would expect the screen to "twitch" to some extent (loss of sync, screen going black for up to a second, usually the symptoms are significant). While Magix is running, I would use Process Monitor from Sysinternals.com (a Microsoft company), and run a trace while you "exercise" the bug. Then stop the trace and scroll back, and see if you can spot a contributing factor. Process Monitor does not log every possible aspect, but if Magix was consulting the registry for example, you might find your four second stretch of registry accesses logged in there. For some programs, you can see unbelievable things going on. Paul, I'm guessing that you googled 'HDR magix' or similar and came up with that three-year old thread you've referenced? It has no relevance to the HDR issue that prompted my query here about drivers. That concerns the loss of proper use of MEP's HDR feature for some of us running modern versions with Win 10. And your reference to a "4 s delay" by me in that thread was even less relevant! Easy to do, but you must have missed my opening sentence: "Excuse the digression...". That OT query was about the magix.info web site - nothing to do with HDR, or indeed MEP ;-) But your final suggestion is back on topic. I was considering the same exercise myself but haven't suggested it to my MEP forum friends as frankly I have little optimism based on previous forensic experience. ProcMon's output, even with filtering, always dismays me with its obscurity! I will try it though. -------------------- Here's a note to me yesterday by one of the UK MEP forum technical gurus, the OP of the current thread about the HDR/Win 10 issue, as possible interest for you and Vanguard. "The hyperthreading tip might be worth trying although I am still keeping in mind that [Magix] confirmed a while back when I reported the anomaly that they had reproduced it and that it appeared to occur with "some Intel graphics Hardware" and had been forwarded to the dev's. I have had no response to queries about progress on the issue other than he thought a recent patch to VPX might have fixed it. Unlikely as it occurs on all versions of Magix NLEs that have the HDR function! As far as the German Forum goes it has not been reported there at all as far as I know, hence Support putting it on low priority. Most of the Mods and usual responders tend to have discreet cards in their machines however." Terry, East Grinstead, UK |
#21
|
|||
|
|||
Is my Intel graphics driver up to date?
Paul wrote:
While Magix is running, I would use Process Monitor from Sysinternals.com (a Microsoft company), and run a trace while you "exercise" the bug. Then stop the trace and scroll back, and see if you can spot a contributing factor. Process Monitor does not log every possible aspect, but if Magix was consulting the registry for example, you might find your four second stretch of registry accesses logged in there. For some programs, you can see unbelievable things going on. Following on from my post a few hours ago I've run Procmon and posted the following in the MEP forum: ==================== terrypin wrote on 03/09/2017, 02:43 PM I've used SysInternals Procmon with filters to show two sets of results operating on a single JPG in MEP 2016 Premium under Win 10 Pro. I'm hoping that the experts here will find clues by comparing these. Perhaps a crucial DLL or whatever, present in the NewBlue set that we can isolate. And then add that to affected Win 10 PCs, independent of NewBlue avoiding the jerky preview that's the downside of that work-around. Not optimistic, but worth a shot! Applied HDR only ---------------- Filtered the hundreds of thousands of entries from a few seconds processing to show only those 81 events with Process = Videodeluxe.exe, OR Path contains 'intel', OR Path contains 'hdr'. Full text at https://dl.dropboxusercontent.com/u/...on-HDRonly.txt Mostly in this screenshot: https://dl.dropboxusercontent.com/u/...on-HDRonly.jpg Applied NewBlue effect first, then HDR -------------------------------------- (I used the 'Reset to None' effect.) Filtered to show only those 342 events with Process = Videodeluxe.exe, OR Path contains 'intel', OR Path contains 'hdr'. Full text at https://dl.dropboxusercontent.com/u/...-NBthenHDR.txt The first 70 or so (showing all NewBlue and some HDR) in this screenshot: https://dl.dropboxusercontent.com/u/...-NBthenHDR.jpg ==================== FYI, the 'work-around' I mentioned is to add any effect from the NewBlue plugin built into MEP *before* using the HDR feature. Its negative side-effect is to make playing in the preview very jerky. Hence the continuing effort to find a 'proper' solution. I haven't yet studied the results as I expect more technically competent users than me to do a better job. Probably futile but ... Terry, East Grinstead, UK |
#22
|
|||
|
|||
Is my Intel graphics driver up to date?
Terry Pinnell wrote:
I haven't yet studied the results as I expect more technically competent users than me to do a better job. Probably futile but ... Terry, East Grinstead, UK Any time you use a tool that produces tons of output data, you start with an "operating failure model" and apply human pattern matching skills. What you're looking for is something out of the ordinary (perhaps coming from the system rather than from the application). When you tighten up the filter rules, sometimes that's handy when you've located the actual problem, and you seek to highlight the problem for others. If you prematurely tighten up the filtering, you might "miss something". If there are "interfering" elements, you can exclude them from the output using the filter, to make it easier to spot patterns in the remaining stuff. For example, ProcMon can be adding its own "profiling" entries, and filtering those out would be considered normal. In your first trace, I see Magix looking for D3D10 registry entries. Does that mean it is a D3D10 only product ? Do the special effects or hardware acceleration only work there ? That's the first question that comes to mind. And using ProcMon comes with no guarantees - it's what you use when you don't have source, you don't have a source code/object code debugger, and you're not getting any help from their technical support. It's the "tool of last resort", and generally limited to noting some defect in your system setup, with respect to the program. For example, on some softwares, you can do Properties on the executable, and select "compatibility mode". And emulate some older set of conditions. Conditions which might be more in line with the year 2014 perhaps. Now, my luck with that is pretty poor - for example, I wasn't able to coax a certain version of Audacity to work any better, no matter what OS version I selected in compatibility. Same with Dscaler. Paul |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|