similar to: Project ideas for GSoC/EVoC v2

On 15/10/17 22:13, Karol Herbst wrote: > Hi everybody, > > currently on the Xorg Wiki page [1] there are only three projects > ideas, two being quite similiar: > 1. Instruction scheduling > 2. Maxwell Video Accel Decoding > 3. Kepler Video Accel Encoding > and also the reference to our Trello board. > > Because I don't expect any student interested in a

Hi everybody, currently on the Xorg Wiki page [1] there are only three projects ideas, two being quite similiar: 1. Instruction scheduling 2. Maxwell Video Accel Decoding 3. Kepler Video Accel Encoding and also the reference to our Trello board. Because I don't expect any student interested in a GSoC/EVoC project to read our wiki or trello, I am sure to attract more students, we should give

On 11/06/2014 13:59, Roy Spliet wrote: > Dear Mr. Dew, > > I hereby wish to propose the X.org EVoC project "REclock - > Reverse-engineer and implement NVA3/5/8 Voltage- and Frequency Scaling > in Nouveau" for which I am willing to participate, and apply for the > associated funding. Full details below or on > http://nouveau.spliet.org/evoc.html . For any further

On Fri, May 16, 2014 at 11:54 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 17 May 2014 13:39, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: >> >> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: >> >> >>

On 17 May 2014 13:39, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: > > On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: > >> > >> Adds a NvReclock boolean option to allow the user to enable (or disable) > >> reclocking.

https://bugs.freedesktop.org/show_bug.cgi?id=96957 Bug ID: 96957 Summary: [NVE0] Feature request: Support Vulkan on Kepler cards. Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau

On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: >> >> Adds a NvReclock boolean option to allow the user to enable (or disable) >> reclocking. All chipsets default to off, except NVAA/NVAC, which are >> reportedly complete. > Hey Ilia, > > I

A quick look over the memory reclocking part inside the maxwell mmiotraces kind of reminded me of the kepler memory reclocking, it looks for most parts the same. I didn't do a deep inspection so treat this with great care, but it seems to work at least on those maxwell gpus this was tested on. It depends on the PMU fixes for the fuc5 though, otherwise the PMU might not work as expected and

Hello Everyone, Greetings! I hope you are doing well. I am Ojus, a final-year IT student. Recently, I discovered EVoC as an open-source enthusiast, and I'm deeply interested in participating in this program. However, I am new to this and am looking for a mentor to guide me through EVoC for a project related to nouveau. I would appreciate any ideas or projects for this program, as I am open

On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: > > Adds a NvReclock boolean option to allow the user to enable (or disable) > reclocking. All chipsets default to off, except NVAA/NVAC, which are > reportedly complete. Hey Ilia, I think I've expressed my thoughts on this previously via IRC, but let me stick them here too so there's a record

Hi Andy, Thanks for checking! I do see an issue on Tesla as well (at least G92, and I believe someone else reported on a GT215 or GT218). However I haven't confirmed that it's the identical issue to what I see on Fermi with quite as much certainty as what I've checked on a GF108. (For the G92, the texture buffer object test fails in the same way it does on Fermi, but there could be

With these both patches, most of the kepler cards should be able to reclock their core clock without issues. These patches should be tested carefully among nouveau devs, so that these don't break reclocking on other cards (especially Teslas). Particularly the second one might break reclocking here and there. Karol Herbst (2): bios/volt: handle voltage table version 0x50 with 0ed header

On 2016.10.11 17:46, Samuel Pitoiset wrote: > > > On 10/11/2016 02:18 PM, Martin Vorbach wrote: >> Samuel, >> >> the HP GT630 is unfortunately the GK107. Given we find the other GT630 >> model I will check it and come back to you. >> >> Are you interested in any of the other two cards? > > I'm (just) interested by Kepler cards actually. :-)

Hi Ilia. It looks like there is a hardware bug on Fermi and Kepler where TLD unconditionally uses the sampler from slot 0. This is supposedly fixed in Maxwell. What I could find internally suggests the bug wasn't present on Tesla, but let me know if your observations contradict that. The only work around is to have a sampler defined and bound. Further, be careful to have reasonable state

This is needed for using Nouveaus PMU image after performing secboot. This will be helpfull for Maxwell2 reclocking on boards without externally controlled fans like on most laptops or fanless boards. Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/nvkm/subdev/secboot/acr_r352.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git

Hello poma, The chipset didn't disappear and is still displayed: it is the G98 you get on the "[ 2.483843] nouveau 0000:02:00.0: NVIDIA G98 (098200a2)" line. The "NV98" was the "Nouveau" chipset, but the switch was made to use the same naming as NVIDIA. So rather than displaying both the Nouveau version of the chipset and the NVIDIA one, it make sense to only

Hello, first of all, I'm new to this list, so please beer with me. On the other hand, I'm a graduate computer systems engineer with experience in Linux kernel code, so I can hopefully provide useful input/assistance on this topic. I'm replying because I tried your patches on my setup in the hope they'd fix my lockups. Unfortunately they didn't, so I'm offering debug

On 03/10/2016 05:03 PM, Pierre Moreau wrote: > On 04:27 PM - Mar 10 2016, Samuel Pitoiset wrote: >> >> >> On 03/10/2016 04:23 PM, Ilia Mirkin wrote: >>> On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: >>>> Add support for clover / OpenCL kernel input parameters. >>>> >>>> Signed-off-by: Hans de

On 17/12/15 19:18, Martin Peres wrote: > > > On 29/11/15 16:10, Martin Peres wrote: >> This is an oversight that made use of the trip-point-based fan >> managenent on >> cards that never expose those. This led the fan to stay at fan_min. >> >> Fortunately, the emergency code would kick when the temperature would >> reach >> 90°C. >>

On 11:43 AM - Feb 23 2016, Hans de Goede wrote: > Hi, > [snip] > > >You may have to add LOAD64/STORE64 for 64-bit > >addresses though. Or we could decree that all addressing on global > >memory shall be 64-bit (and thus read the .xy components of the > >address source). > > I would prefer to keep LOAD / STORE semantics the same as with > other LOAD /